Stealth Spam, Timthumb and WordPress

This post is about: Tech
This post mentions: , , , , , , , , , , , , , |

WordPress is how I pay my bills and keep my fridge full of Woodchuck Hard Cider. I’m fairly clever with it, but I’d know nothing were it not for the countless folks out there sharing their collective wisdom freely. I tell people WordPress can do anything – you just have to Google the right words. That’s the magic of open source software.

The danger of open source software is that lots of people tend to use it, but only a few people stay on top of the latest news, updates and security threats. The biggest example I’ve seen of this is the TimThumb vulnerability. TimThumb is a popular script for handling images on WordPress. It allows dynamic cropping, resizing and other fancy tricks and was all the rage with premium theme and plugin builders prior to WordPress adding Featured Image functionality. Some still prefer it to WordPress’s core image handling. Bottom line is – a lot of themes and plugins use it, and sometimes it isn’t obvious.

A few months back, it also became a massive security hole. As it turns out, the script as written made uploading malicious code onto a site from outside fairly easy. The WordPress community moved fast, a safe version of TimThumb was created, and anyone who keeps up with WordPress news quickly knew what to do.

The problem is, how many people really keep up with WordPress news? A lot of sites run on it, and by default several blogs appear on the Dashboard when you log in, but few people pay them any attention. Some even hide them. And as I’ve learned the hard way when working with clients that don’t want to pay me to build a custom theme but would rather have me customize a free or cheap one, a great number of theme makers – even expensive “premium” sites – don’t contact customers about security issues.

Case in point: The other day a client contacted me about a site I worked on early this year. It looked fine, until you Googled it. In the Google description, this tiny Southern newspaper was apparently selling Canadian erectile dysfunction meds. That’s… not good SEO.

No where on the site was any of this mentioned. What in the hell was happening? Where was Google getting this stuff?

Then I remembered the TimThumb issue. Yep, the theme used TimThumb and no, it hadn’t been updated to the secure version. Now I knew how the critter got in. I just needed to find where it was nesting.

Obviously, someone used TimThumb to place spam on the site. But the spam wasn’t visible to Firefox or any of the other browsers – only Google could see it. More specifically, only GoogleBot could, the bit of code that scours the web and updates Google according to what it sees. There’s a lot of ways to see through GoogleBot’s eyes: I use a Firefox extension called User Agent Switcher (a must for designing mobile-friendly sites). The newspaper’s site, seen as a faux GoogleBot, had more spam than a Monty Python fan site.

Here’s what happened: Some little fuckwit used the TimThumb vulnerability to slide a bit of conditional code into a WordPress core file. The code said that, if a browser is looking, act normal. But a search engine comes around, open your coat and flash these naughty links. It’s sneaky stuff, because you’ll only notice it if you vanity-search your own site. It’s also vile, because it can cause Google to blacklist the site, which is devastating these days.

The fix in this case was a clean reinstall of WordPress, which is simple. But I’ve heard of similar hacks being done in the theme itself – sometimes by adding a file in a tucked-away corner. That’s harder to catch, especially if you don’t know what your folders and code SHOULD look like. I imagine it could also be added to a plugin, which is even worse.

If you find your WordPress site the victim of a conditional hack, or any hack really, the first step is figuring out how they got in. Go get the TimThumb Vulnerability Scanner plugin. It’ll check your whole installation for the script, and give you the option to update it. Hell, do this even if you haven’t been hacked.

Once you’ve found the hole, change all passwords. WordPress, FTP, all of it. Make them good. No work that appears in the dictionary should be in your password and it should consist of of at least three of the following four things: Uppercase letters, lowercase letters, numbers, and symbols.

(Here’s a good trick to make it easier to remember – think of a sentence that means something to you, take the first letter from each word, type only those letters. It should be at least 6 characters. Capitalize them as if it were a headline: “Dance with the Devil in the Pale Moon Light” becomes “DwtDitPML.” Now think of an important date to you, and put each digit between each second letter. Say you were married on 8-14-87. The password is now “Dw8tD1it4PM8L7.” That would take years for a brute-force attack to crack. Still, if you want to make it decades, toss some “@” and “*” symbols in.)

If WordPress isn’t up-to-date, update it. If it is, re-install it. The one-button reinstall should do the trick, in the Update panel. Update any out of date plugins. If the hack is still there, it wasn’t in your core files. Deactivate all your plugins, and see if the hack is still showing up. If it isn’t, turn them on one at a time, checking for the hack each time, until it reappears. Delete and reinstall that plugin.

If the hack didn’t go away when you turned off the plugins, it’s likely in the theme. If you’ve made no modifications, or did so via a child theme, you can delete and reinstall the theme. If that doesn’t work, or if you modded the theme itself (or wrote it yourself and don’t have a backup), you’ll need to either check the child theme or parent (main) theme for malicious code. Using the Agent Switcher plugin, look at posts, pages, and other areas of the site besides home. If the hack is on them all, it must be in a file they all use: Header.php, Footer.php, Sidebar.php and Functions.php are likely culprits, as are any scripts they link to. If the hack’s only on a certain page, likely the home page, you can start with the appropriate template file – home.php or index.php for home, single.php for posts, etc. But – it could still be in one of the files I first mentioned, and set to only show on that page.

Look for long strings of gibberish that start with something like “base64.” A hacker will usually encrypt malicious code that way. Try deleting it and seeing what happens – hopefully it won’t break the site. If it does, use a tool like this to decode that string and see what’s really going on inside it. It may contain the end or start of legitimate code you need, which you can paste back into your file easily enough. It may even be something your theme builder put there… which is unethical on their part but not a part of the problem right now. Keep looking.

This isn’t exhaustive, but it covers the most likely possibilities that I’ve encountered. WordPress is wonderful, but it’s kind of like a car – you can’t expect to do no maintenance and expect it will run fine forever. Read those little headlines in the dashboard, and keep things up-to-date.

 

 

Share
Bookmark the permalink. Follow any comments here with the RSS feed for this post. Trackbacks are closed, but you can post a comment.