Quick quote

close

To request a call back to discuss your project, please complete this form.

Alternatively, please call: (02) 8007 0218

Great websites, creative solutions. Call us now on (02) 8007 0218

Blog

How to clean up after a Thumbs.db wordpress and php auto_append_file exploit hack

Posted 02/June/2011 by neubreed

We recently installed a clients Wordpress website on our web server. It wasn't up to date with it's security patches and consequently it left the backdoor open on our server .. wahooo! The exploit creates a file named Thumbs.db in each document root that contains php code ready for some foul play. Naming the files as Thumbs.db is a rather sneaky tactic as it's a standard windows file and can easily go undetected as a threat. The hack also appends all the .htaccess files on the server with:  php_value auto_append_file  php_value /your/path/Thumbs.db This allows the php code inside Thumbs.db to be executed as if it were a php script! This is very very wrong indeed. Now the best way to avoid this situation is to keep all your open source applications up-to-date in the first place. But if you've managed to forget about all the sites and applications that you have on your server like we did, here's a guide on how to cleanup the mess.

Secure your server with the latest security patches

First thing is to do is find the leak and plug it up with a newer version of your open source software. You may need to refer to the documentation for upgrading your particular version. The way that I found the leak was to search the /home directory by date for the first created Thumbs.db file that contained php code. This indicated which site had been compromised. In this case it was a Wordpress website.  find /home -type f -name "Thumbs.db" -print | xargs ls -lrt > output.txt

The cleanup

Through Linux shell we first use the following command line example which will search inside all .htaccess files under the /home directory and use sed utility and a regular expression to replace the malicious code with nothing. The -i flag on the sed command edits the file in place. If you would like to test this command first, you can leave the -i flag out. In our case the extraneous code was inserted into the .htaccess file prep-ended with scores of line breaks. If an unsuspecting victim opened the file, the code would be well below the fold and be easily missed. The regular expression below removes these line breaks too.  find /home -type f -name ".htaccess" -exec sed -r -i ':a;N;$!ba;s/(\r?\n)+php_value auto_append_file.*Thumbs.db//g' {} \; Finaly we delete all the Thumbs.db files under /home using the find command again, piping the output to the rm command to remove the file.  sudo find /home -name Thumbs.db -type f -exec rm -f {} \;

EDIT: More info and help can be found here: http://www.jorgepablos.com/2011/03/watch-out-php-5-2-vulnerability-google-results-finditnow-osa-pl/

Comments

Submitted by Karen (not verified) on
Comment: 

Thank you - my WP sites were hacked too. This was very succinct and helpful.

Submitted by Fred (not verified) on
Comment: 

Thanks for this. My site got hacked and a colleague pointed me to this page. What mystifies me is that the .htaccess in my site root was hacked, and that was set to owner write only, as is the web root directory. There is a test wordpress installation on the site but that's guarded by another .htaccess which was unaffected so I can't see how the hackbot could get to that. All other .htaccess files on site were ok, it was just the one in the web root that was hacked. Does anyone have any idea how the hackbot could do this? It's very, very worrying.

Fred

Submitted by keyman (not verified) on
Comment: 

thank you for all the informations. i got hacked too, but it was an up to date os:commerce installation.. i use shared server and i dont know if there is a wordpress installation but hoster says that no other sites on the server are compromised..

Add new comment

Tags