Cleaning Up the TimThumb Hack

By Devin
Tim Thumb Hacker

Several of my websites were hacked this week using the TimThumb exploit. The issue has been known for a couple weeks now.

Although I had updated the majority of sites and had notified former clients, I still hadn’t gotten to some of the smaller sites yet- like my girlfriend’s food blog.

And word to the wise, your girlfriend’s food blog should always be top priority.

Hackers are using a variety of techniques to hijack WordPress sites right now, but this is how I cleaned up the ones on my server.

Make Backup of Everything

Common sense, but worth mentioning again. You never know when you might accidentally delete a directory you need or wipe part of the database. Most cPanels wills let you easily export a copy of the database. And it’s a lot easier to download a second copy or your files then rebuild them all from scratch.

Get Shell Access to Your Host

If you only have one site, this may not be necessary. But I have over twenty WordPress installs running on my server and I wanted to find all the files that were compromised and fix them quickly. Most hosts offer shell access. With BlueHost, I just had to go into my control panel and enable it.

Here’s BlueHost’s instructions for setting up shell access and for logging in via shell.

Fix TimThumb Vulnerability

You can download the latest version of TimThumb with the security fixes here: http://timthumb.googlecode.com/svn/trunk/timthumb.php (Just save the file out).

Replace any instances of TimThumb.php on your server with the new version. WooThemes used the name “thumb.php” for this file, so you should also look for that.

If you have shell access you can do a quick search to find all instances of timthumb with:

find *  -iname 'timthumb*' -ls

or

find *  -iname 'thumb.php' -ls (for WooTheme versions)

In many cases I found themes that were not being used and just deleted them directly:

rm -rf path/to/theme

Most theme companies have also already released fixes, so you could also get the latest version directly from them and replace your current theme.

Clean Up After the Hack

DISCLAIMER: I don’t consider myself to be a security expert, but these are the steps I took to clean up my site. If anyone else has additional recommendations, please drop them in the comments or post a link.

  1. I wiped the entire directory of the hacked site since I didn’t know which files has been added or compromised.
  2. I changed my database passwords and uploaded a new clean version of WordPress with a fresh wp-config.php file.

    3. If you’re using shell this is very quick (http://codex.wordpress.org/Installing_WordPress):

    wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
  3. I manually checked my backed-up “wp-content” to make sure no odd new files had been added. I specifically checked for files that other folks have reported as being exploited, like: 
    /wp-content/uploads/feed-file.php
/wp-content/uploads/feed-files.php
/wp-content/themes/******/cache/.htaccess

    The file in my case was:

    /wp-content/data.php

    There’s an excellent post that goes into the hacking methods in more detail and suggests other files to check at: http://redleg-redleg.blogspot.com/2011/08/malware-hosted-newportalsecom.html

  4. I also grepped the backed-up “wp-content” directory for any files with base64_decode. There are legitimate reasons to have base64_decode in a file, but if you don’t know where the file came from, or what it does, find out.

    Here’s how you grep a directory: 

    grep -r base64_decode *

    If you want to grep your entire server, try

    grep -r --exclude={wp-app.php,class-simplepie.php,class-IXR.php} base64_decode *
  5. When I was reasonably confident my backup wp-content directory was clean, I re-uploaded it.
  6. I reset my file permissions as specified by WordPress in the codex
  7. I logged back into WordPress and reset the admin passwords.
  8. I reset my permalinks to be completely sure the htaccess was overwritten.

Anything I Missed?

If anyone else has other suggestions or recommendations, please post them below.

And please update ALL sites that might have the TimThumb vulnerability. Your girlfriend will thank you.

About Devin

I am a developer based in Austin, Texas. I run a little theme shop called DevPress and help manage a WooCommerce shop with Universal Yums. Find me on twitter @devinsays.

18 Responses

  1. Ipstenu

    This is, pretty much, the advice I’ve been touting to everyone and their grandparents. The only thing I would add in is this:

    Delete everything INCLUDING your themes and plugins. Download them all fresh. People have been using the backdoor to get in and edit files in plugins, other plugins, and perhaps most importantly, they’ve been using to muck with your wp-config.php and .htaccess files.

    Ignore nothing. Even non WP files.

  2. Aharon Moshe

    Yes, I heard about this with a note from my web host. Honestly this kind of stuff is so annoying! People who know how to mess up your websites, do it, just because they can.

    The thing that makes it so annoying is you choose a format because of its simplicity, then you have to delve into coding or deleting entire files and re-installing just because someone with time on his hands has to use it in a destructive way.

    Then, if you are a slow learner of coding or other high tech tasks, the hours you could other-wise spend developing more websites, or monetizing existing ones, you now have to spend repairing something that never had a problem!

  8. Jack

    In my case I had the host overwrite the entire WordPress directory with a clean backup from earlier in the month. I then went through and weeded out any files that had a newer modified date than the backup. I’m hoping it’s clean enough. Does anyone know do they inject anything into the database?

  9. Brandon

    Devin, I think I was hit with the same attack, possibly through an unused theme in an old WP install. I found the attack files using grep to look for eval(base64_decode) in new/modified files. But just when I thought I was clear, I found a file with a 2nd layer of obfuscation, where varying numbers of # hash marks were interspersed within the eval(base64_decode) string. At first I scratched my head and thought there was no way I could grep these, but then I found the Achilles heel of their attack: At the end of the file, way at the bottom of 200k of base64 code, was a str_replace(‘#’… function to remove this simple encoding. I used egrep to sweep for other instances, and was back in business. Of course, the only way to be sure there are no remaining instances would be to go with the fresh reinstall, as you’ve suggested, but this worked in a pinch. Worth saving in the bag of tricks for next time!

  13. ovizii

    Hey guys, I’m having a similar problem and was just curious if the Timthumb vulnerability was ever used to do MYSQL injection too? If yes, any chance for me to detect it?
    I’ve got the infected site completely downloaded to locally check and I also got a SQl dump but am not sure what I could check for in there.

Leave a Reply