We’ve gotten a rash of calls today about WordPress weirdness. Malware redirects, login failures…slightly different in each case, but all having one thing in common: theme’s or plugins running older versions of timthumb.
Earlier this month, it was widely reported that timthumb had a security vulnerability (see Mark Maunder’s announcement or Ben Gillbanks followup) that would allow an attacker to push files into your WordPress install. subsequently, timthumb 2.0 came out and solved the issue, but alas not all theme’s or plugins updated to this version.
It appears now that attacks utilizing this vector are now bot automated (or someone has a lot of time on their hands), because the phone has been ringing today. How to deal with this and recover? The following is a general action plan you can use as a base. It’s not the end all solution; you’ll have to adapt to your specific case of infection.
NOTE: let me repeat: the following instructions are NOT the end all solution in most cases: you have to adapt them to your particular case. We offer no warrenty if you screw something up.
BACKUP NOW! if you have not done so, please backup your files and data. You should be doing this already, but do it one more time just in case.
Fire up your SSH to your server, and get ready from some command line action.
First, find if you’ve where your timthumb is installed (might be a theme, might be a plugin)
grep -ri -l "timthumb" /path/to/blog/folder
After you’ve found it (sometimes the file itself is not named timthumb.php, so make note), go get the latest version of timthumb from trunk:
wget http://timthumb.googlecode.com/svn/trunk/timthumb.php
You’ll need to sort out the particular settings that the old version used (some installs use the sidecar timthumb-config.php for that, others have it defined within their version of timthumb). Once you have that sorted, copy/move that file into place, destroying the old file:
mv timthumb.php /where/ever/old/file/located/thumb.php
Great, timthumb should feel better. Now let’s cleanup other damage.
Several of the sites we looked at today had a variation of a redirect to securesoft.ru, which was being reported by Google Chrome as containing malware. The first thing you have to do is sort out where that’s coming from. Let’s find it:
grep -ri -l "securesoft" /path/to/blog/folder
This for us returned the root level .htaccess file in the wordpress directory. Chances are, you’ll note that it the modified date was recent and that it’s larger in size than usual. If you open it, it’ll probably look like the normal version your wordpress install uses. It’s not; the file is padded with space to hide the new redirect rules. Basically, you have two options: scrub the bad rules out or simply delete the .htaccess and replace with a fresh version. Your choice.
Second, let’s look for changed files that the attacker may have uploaded.
find /path/to/blog/folder -mtime -2
That find command will look for files that have been modified within the last 2 days. You can change the days span by simply updating the “-2″ to what ever number you want. In our case, this returned two files in most cases, wp.php and script_new3.php in the theme that was compromised (this was also noted on ServerFault yesturday). Remove these two files.
At this point, you should be generally back to normal. Login into your WordPress Admin, change all your passwords for all users and update any and all plugins, themes, and WordPress files as needed.
Again, I cannot stress this enough: this is general. You should check your logs to verify if any other activity that may have taken place and evaluate if any other files changes may occurred. But hopefully this will help get you started.
