Tell me more ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.
up vote 2 down vote favorite
1

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

share|improve this question
Preventing a .php extension, while a good idea, will not stop php files from being uploaded with other extensions. – beth Jan 15 at 18:07
Are you on shared hosting or VPS / dedicated hosting? – MPD♦ Jan 15 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. – MPD♦ Jan 15 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)? – MPD♦ Jan 15 at 20:35
You shouldn't leave anything 777 on a production server: drupal.org/node/244924 – sarahjean Jan 18 at 1:38

1 Answer

up vote 6 down vote accepted

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

share|improve this answer
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. – MPD♦ Jan 17 at 14:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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