
A thumb. So now you know.
Tim Thumb is a lovely bit of code designed to make PHP developers’ lives a bit easier. It’s a multipurpose image mangler, capable of resizing, cropping and filtering images from external sources to make your WordPress posts look pretty.
It’s also dangerously broken right now.
There are a lot of WordPress themes out there that use Tim Thumb – it’s free, open-source software, and it’s very lightweight. There’s a chance that your theme is using it – and if it is, the flaw means that an attacker can upload a script to do anything they want on your system as the user that PHP runs as. Which is rather undesirable.
Here’s how to check for and fix any intrusions.
Step one: see if your theme is using Tim Thumb.
Before you check for and fix any intrusion, you should get rid of the way that attackers can find their way in.
For this example, we’ll assume that all your WordPress sites are stored in
/sites/wordpress/SITE_NAME
SSH your way into your Web server, and execute the following -
grep -r '$allowedSites = array' /sites/wordpress
You may need to use sudo if you have different file ownerships for each WordPress site – in that case, execute this instead -
sudo grep -r '$allowedSites = array' /sites/wordpress
If there are any results, you’ll see output similar to this -
/sites/wordpress/testsite/tom.php: * TimThumb script
In this case, the file that contains Tim Thumb is the path before the colon, in this case
/sites/wordpress/testsite/tom.php
You’ll need to then take action. You can delete the script – this is the most secure option but might break your WordPress theme. You can also edit the script to deny all includes, which might still break things but it’ll do it more gracefully. Change
$allowedSites = array (
'flickr.com',
'picasa.com',
'img.youtube.com',
'upload.wikimedia.org',
);
into
$allowedSites = array ();
Or, of course, you can just switch themes and delete the theme that uses Tim Thumb from your server (just switching themes is not enough).
Once you’ve locked Tim Thumb down, it’s time to check whether anyone’s hit you.
Step two: check to see if you’ve been compromised.
The best way to do this is to restore from a known-good backup, but that’s usually impractical. The next best way is to dig through all your code manually, but that’s usually impractical too. If you don’t have the time to pore through things and don’t have a clean backup to blow back on, you can check for most compromises automatically.
This is by no means foolproof, but nearly every malicious script uses base64_decode() to hide itself. That gives us an easy way to check for the vast majority of attackers’ scripts.
Execute
grep -r base64_decode /sites/wordpress
Again, if you have permissions issues, use sudo -
sudo grep -r base64_decode /sites/wordpress
If your results include any huge base64 encoded strings (massive swathes of what looks like random alphanumeric characters) as arguments to base64_decode, you’ve probably been hit. Don’t worry about smaller strings, they’re usually legitimate.
If you have been hit, I’d recommend backing up your uploaded files and reinstalling WordPress and your themes from scratch. Your database contains your settings and content other than your uploaded files. Going into how to do this without losing data isn’t within the scope of this article, but if you Google you should be able to find a few decent guides.
Step three: Keep safe
Standard best practices here. Keep everything up to date in your WordPress installation – themes, plugins and WordPress itself – and follow a few security people on Twitter to keep an ear to the ground as far as critical vulnerabilities like this go.