Recently, I logged in to one of my WordPress websites to find that the unthinkable had occurred. The website had been hacked through a vulnerability in Timthumb, a script that automatically generates thumbnails from larger images. Timthumb has a list of “trusted” image hosting websites that it can generate thumbnails from, and a hacker can exploit this by hosting a malicious PHP script on a trusted website and executing it from your website. I updated Timthumb as soon as I heard about the vulnerability, but it turned out that the updated version was vulnerable as well.
After logging in to the affected website to do a little WordPress Spring cleaning, I noticed that the Timthumb Vulnerability Scanner had an update available. I found that odd, since I thought the Timthumb vulnerability was a thing of the past. I updated and ran the scanner, which presented me with a nasty surprise, “Suspicious Files.”
The name of the malicious PHP script was 2e1a01b3bbe6d83313a92d1b48f74478.php, and a hacker had used Timthumb to plant it on my server, giving him a back door that he could access through his Web browser to wreak all kinds of havok on my server. If you haven’t used the Timthumb Vulnerability Scanner, another clue that your website has been hacked is the presence of an unusual file when you enter the Appearance/Editor screen in WordPress, as shown on the right. So, a vulnerability in Timthumb — combined with my poor website maintenance — had resulted in WordPress getting hacked. This is the story of how I recovered WordPress and patched the vulnerability, and I hope that you find it useful. During the recovery process, I learned a great deal about how the Timthumb vulnerability works and how to be certain that your server isn’t still hosting a back door for hackers after you delete the suspicious file.
My first step was to use the Timthumb Vulnerability Scanner to update Timthumb. I then connected to my server via FTP, downloaded the suspicious PHP file and deleted it from the server. The file was located in the folder /wp-content/themes/(Theme Name)/Cache. Upon opening the file in Notepad++, I found that it began with the string “eval(gzinflate(base64_decode(.” Following this was a long string of random characters which I assumed must be compressed and encoded in a base 64 format. I used an online gzinflate base 64 decoder to decode the compressed content and pasted it back into Notepad++ for evaluation. Although my coding knowledge is limited, I could see that the file was a PHP login page that would give the hacker a back door into my server and direct access to the database containing my website’s content. Apparently, the most common payload of this backdoor is to redirect an entire website to a spam website in Russia, which didn’t happen in my case. So, now we know the enemy, and we’ve removed the possibility of a hacker exploiting WordPress through that same vulnerability again. However, there is still quite a bit of work ahead.
Now that you’ve removed the original vulnerability, your next step is to scan your server to see if a backdoor still exists. You can dothis automatically or manually; I suggest both.
Connect to your server with an SSH client and open a terminal prompt. Type the following command:
This command searches your server for other base 64-encoded content. The server will respond with a list of files containing this string. What you’re looking for is another very long base 64 string, which you can then plug into the gzinflate base 64 decoder to find out what it is. Remember that some of the other files on your server — particularly Timthumb itself — also have base 64-encoded strings; you’re looking for something about as long as the original malicious PHP script. If you don’t find anything, your website most likely doesn’t have a backdoor.
If you’d like to run a more thorough search, use this command:
This command searches your server for additional strings that could signify a backdoor. If you find anything on the results list that looks suspicious, download the file and examine it in Notepad++. If you don’t see anything suspicious, again, you’re most likely fine.
A manual backdoor scan can be far more time-consuming, but may be necessary if your hosting provider doesn’t allow SSH access (HostGator does allow this). Essentially, what you’ll need to do is connect to your server via FTP and dump all of the files to your computer. Examine every PSP, ASP and TXT file for suspicious code and sanitize as needed.
WordPress assigns a password to your admin user account, and you may have created other accounts on your website as well. However, the recovery of your hacked WordPress website doesn’t stop there; the wp-config.php file in your WordPress directory contains the password that WordPress uses to log in to the MySQL database containing your website’s content, and the password is not encrypted. If the hacker was able to download this file, he has that information. You’ll need to change the WordPress database password, and for good measure you should also change the passwords for all of the FTP accounts on your server as well as the master password for your Web hosting account.
If you use a premium WordPress theme, chances are that your theme provider has already fixed the Timthumb vulnerability. For example, Elegant Themes no longer uses Timthumb at all. If you use a free theme, however, support may be limited. I’d advise switching to a theme that offers support, but if that isn’t an option you can modify Timthumb to prevent it from pulling data from any website other than your own. Connect to your server via FTP and look for the file timthumb.php, usually in the same folder as your WordPress theme. Download the file and open it in Notepad++.
Find the following string at line 32 and change TRUE to false.
Next, find the following string at line 33 and confirm that it is already set to false. If it isn’t, change it.
Finally, find the following at line 124:
Remove all of the external websites, changing the code to this:
Upload the file back to your server. Timthumb should now refuse to pull any data from a website other than your own. Note that if you used Timthumb to generate thumbnails from an external image hosting site, you may need to host the images locally and create the thumbnails again.