Security Alert: WordPress Timthumb Hacker on the Prowl

As most WordPress bloggers and site owners and administrators will already be aware, the TimThumb script that is popularly used for resizing images to create thumbnails for WordPress themes and plugins has a security vulnerability that allows hackers an easy ride into websites.

The vulnerability was made public at the beginning of August and was patched almost as soon as it was announced. However, I’ve noticed a increasing number of crawls of sites I manage by scripts looking for themes and plugins that use timthumb.php. These crawls produce 404 error reports in both the plugins SEO Ultimate and Redirection because the files the bot’s hunting for do not exist on my servers. In every case, the crawler scanned the directory /wp-content/themes/ and /wp-content/plugins.

10th Nov. 2011: Please see Bootnote for the best solution.

Scanned Themes and Directories

It looks like the bots are aimlessly scanning for any theme or plugin that might contain timthumb.php (or its alias, thumb.php).

The first scans hit the following directories:

IP’s To Block

Place the following Apache directive into the .htaccess file in your server’s root directory. It tells your server to deny requests emanating from the stated IP addresses (updated 20th Oct. 2011):

The following IP addresses have been removed from the above list in response to host and webmaster replies to my alerting them that their servers have been hacked.

Security Recommendations

Delete any themes and plugins that you no longer use and keep WordPress, all installed themes and all installed plugins up-to-date.

There is a plugin available to scan your WordPress wp-content directory for unpatched versions of TimThumb. Grab it from wordpress.org.

Block public access to timthumb.php (and thumb.php) with an .htaccess FilesMatch directive. Copy and paste this line into your topmost .htaccess file:

The caret, ^, tells Apache to look for requests to view files that “start with…”, the parentheses, (), tell Apache to expect a list of files in the directive, the backslash before every full-stop tells Apache to treat the full-stop as a literal character (as opposed to a representation of any character), and the pipe, |, is used to separate list items with an “OR” preposition.

The above instruction tells Apache to block any request to view wp-config.php, install.php, php.ini, readme.html,bb-config.php, .htaccess, readme.txt, timthumb.php, thumb.php, error_log and error.log.

Using the above snippet in .htaccess  will prevent anyone but Apache (and anyone running as the Apache user/usergroup) from viewing any of the stated files. This means bots can’t view them, surfers can’t use them and you may only view them while logged into your server and using its own file browser or an FTP program.

Once added, you will notice that most attempts to find timthumb.php will cease after the first occurrence because of the “You do not have permission to view this file” or “Forbidden” message that Apache displays.

Bootnote

I found a better solution to blocking IP addresses and bad hosts.

.htaccess rewrite rules can be used to block many RFI, XSS and SQL Injection attacks.

Read WordPress Security Hardening Tips here.

What Next?

When possible, I contact website owners and their hosts (if the site owner fails to respond) to alert them to malicious scripts on their servers. Maybe you could do similar to help free the Net of malicious bots.

Suggestions for removing and updating TimThumb are given at WP Service Masters.

If do think you’ve been hacked then you should backup and download your wp-content directory, any files and directories you’ve created, and your database before deleting everything and re-installing WordPress. A good guide to this is found at WP Service Masters.

Win the battle. Social Warfare Dynamik Website Builder Author Pro

Leave a Reply

14 Comments on "Security Alert: WordPress Timthumb Hacker on the Prowl"

Notify of
Sort by:   newest | oldest | most voted

Thanks a ton! A client just notified me that their WP site had been hacked.

The first thing I did was add the blocked IP addresses and access to timthumb within htaccess.

And…instantly the malicious links that were showing within their site DISAPPEARED!

I’ll keep investigating to see if I really need to reinstall WP or do some other damage control, but this post has already really helped me.

Thanks!
Jeff

As well as installing files on hacked servers, the hackers have been adding code to timthumb.php, wp-config.php, .htaccess, other WordPress core files, the index.php file of different themes… hence my recommendation to reinstall WordPress or, at minimum, its core files (via an update), all themes and all plugins.

There is another option to reinstalling everything. Use the free site scanner provided by Sucuri. It’ll give you an idea of where any malicious scripts reside (that is my affiliate link).

Jeff, I’m glad I helped. I update the block list daily so keep watch for new IPs being added.

It would be nice if we could use add_image_size in the same fashion, but that only impacts images uploaded after the fact… with the dynamic resizing we can set the sizes at any time….

Anyone have any idea how to find out if a server is doing the actual SCANNING for this exploit?

Scan the contents of scripts on the server for known malicious code (I use Securi to monitor specific domains), reinstall applications then check modification timestamps of all files and manually read any file with an older timestamp than the freshly installed ones because older ones might not be files you put there. Also check for suspicious processes and traffic. A good list of network monitoring tools can be found at http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html#flow.

pktstat shows the contents of GET and POST requests, Wireshark will do that and much, much more. pkstat is a command line program, Wireshark is graphical.

Here’s an affiliate link to Securi.

I watched someone from one of those IPs today scanning OS commerce for Login files.

I’ve managed to block remote file insertion attempts with my .htaccess file so I’m no longer able to collect additional domains for this particular blocklist.

The rewrite rule to to your .htaccess firewall blocks all query strings containing “src=”.

Put something like this in your .htaccess file and you’ll not be far wrong (read the instructions too):
RewriteBase /
# white-list remote requests from your own host (none should be possible but...)
# change the numbers in 1.1.1.1 to those of your server's IP address
RewriteCond %{REMOTE_ADDR} !^1.1.1.1$
# Add hosts you're willing to allow to make requests containing "src=" in them, e.g Disqus
RewriteCond %{REMOTE_HOST} !.disqus.com$
# block non white-listed hosts from making requests containing "src="
RewriteCond %{QUERY_STRING} ^.*src=.*$ [NC,OR]
RewriteCond %{THE_REQUEST} ^.*src=.*$ [NC]
# Give bad request makers the finger
RewriteRule .* index.php [F,L]

Watch for side effects such as plugins not being able to update or login redirections not functioning properly. You can fix side effects by white-listing specific requests. The above will work for most sites, WordPress or not. Place the code in your site’s root .htaccess file and put it above any other rewrite rules to ensure they’re processed first.

Here’s another IP for the list:
WordPress Timthumb Exploit Activity was seen today (1/13/12 5:12 AM) from this IP 72.32.189.206
Thanks for sharing the IP list, suggested scripts and information

Thanks and you’re welcome. There’s a bigger list of  bad  IPs at https://journalxtra.com/blacklists/ip-blacklist

I don’t see many bad IPs now that I’ve renamed the wp-content directory and used .htaccess directives to lock down wp-login.php, wp-register.php and wp-signup.php. Highly recommended actions but back up first.

You can remove the 194.109.22.71 entry. It was one of our Shared Webhosting customers, and it’s cleaned up (a long time ago already).

Thank you for keeping me up to date. I’ve removed it. Please let me know if you notice any others that need to be removed.

Thanks :) Just wondering, is it necessary to be able to access timthumb.php directly? Or could we just redirect all timthumb.php requests to a 404 page? It’s kind of a unique name so it shouldn’t do much harm in that case (when disabling it server-wide).

You’re welcome. I need to update the post. The timthumb exploit no longer exists in the current version of Timthumb. If you’re worried that you are using an old version of Timthumb then just replace it with the latest version from http://code.google.com/p/timthumb/

I am available to assist if you need help replacing Timthumb.

Your best for improving security is to follow my WordPress security hardening guide at https://journalxtra.com/websiteadvice/wordpress-security-hardening-htaccess-rules-4025/

Thanks for visiting Daniel.

we had an attack from 46.163.73.20 today, add that to the list.

wpDiscuz

Free to your inbox

Join our mailing list to receive the latest news and updates from JournalXtra.

You have Successfully Subscribed!