4

Hi one of the sites im working on just recently got comprised and a bunch of php files got upload somehow or someway into the files folder and started sending out alot of spam. I know during installation they ask for the files folder to be set at 777 permissions, but is there a way to prevent any php scripts from ever running in that directory if they were ever to get uploaded.

screenshot

Improve this question
5
  • Preventing a .php extension, while a good idea, will not stop php files from being uploaded with other extensions.
    – beth
    Jan 15, 2013 at 18:07
  • Are you on shared hosting or VPS / dedicated hosting?
    – mpdonadio ♦
    Jan 15, 2013 at 19:47
  • @beth, that is true. Normally, though, the webserver uses the file extension to determine what to do with it. There are methods for disabling .php from being served up as PHP, which would prevent direct execution. It doesn't prevent them from being included or uploaded, though, which is that I think you are alluding to.
    – mpdonadio ♦
    Jan 15, 2013 at 20:34
  • 1
    @duckx, can you edit the post to include the contents of .htaccess from sites/default/files (or whatever your files directory is)?
    – mpdonadio ♦
    Jan 15, 2013 at 20:35
  • 1
    You shouldn't leave anything 777 on a production server: drupal.org/node/244924
    – sarahjean
    Jan 18, 2013 at 1:38

1 Answer 1

Reset to default
9

Drupal file uploads (in core or modules) should use file_save_upload which itself also calls file_munge_filename. Together those two functions should ensure that even if a file contains php it is not named in a way that a typically configured webserver would execute them. They also have protection against pl|py|cgi|asp|js files which can often contain code.

Since you seem to have .php files in that directory you have to start considering other ways the files might have landed there.

  1. A vulnerability in a module that is allowing arbitrary file uploads
  2. A vulnerability in some other code running on the server (outside of Drupal)
  3. An insecure configuration (allowing users to run php) was used to download these files directly, avoiding Drupal's API.
  4. An attack that used a virus to read stored passwords (e.g. out of Filezilla) on your local computer - these are more common than you'd think, but they usually don't target the files directory.

I suggest doing a few things:

  • Check the permissions and ownership on the files, that will help you know which webserver user uploaded the files and from there you can hopefully narrow which code was used to upload them. Or if, you notice they are owned by a specific unix user other than the webserver then you should worry about that account.
  • Check when the files were created - go through backups to find when they appeared or check the file timestamps (though on most OS you can only the file last modified and not the file created timestamp)
  • Check the apache logs for all accesses to these files and see which IP is accessing them and when (especially the first date of access)
  • Check the apache logs for other accesses to your site from those IPs and on those dates

These investigation steps are meant to help narrow down how the files were uploaded. Ideally you'll find some specific event (e.g. a POST to some url on your site that you investigate and see is a way to execute php, something like the CKeditor/FCKeditor module issue, then you can know that's how your site was exploited.

If you do find out how the site was exploited, please report it as a security issue: http://drupal.org/node/101494

Improve this answer
3
  • It is also worth noting that the standard .htaccess file in that directory should prevent the webserver from executing any file b/c of the SetHandler. You need to double check that this file hasn't been altered.
    – mpdonadio ♦
    Jan 17, 2013 at 14:54
  • let drupal having the permission to created .htaccess is itself security risk. If .php files can be uploaded by hacker then it could be .htaccess too and after placing backdoor he can rollback the old .htaccess like nothing happened. In that case .htaccess should be write protected just as settings.php. Other option is to have host configuration like mentioned here drupal.org/node/244924#comment-4572986
    – kiranking
    Oct 2, 2018 at 7:32
  • Kiranking, yes that's absolutely right. The htaccess that Drupal places is a basic step for sites that allow it which provides some benefit but is not perfect. The ideal situation is add similar controls at the webserver level to prevent executing php inside the files directory in the webserver configuration which is much harder for an attacker to modify (e.g. allowoverride none in addition to preventing execution).
    – greggles
    Oct 3, 2018 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.