Absolutely, 100% by accident, I managed to discover that my server had fallen victim to an interesting SQL/PHP injection attack. I began to notice some odd search traffic that resulted in one or two hits to both of the sites on this server and decided to Google the hostnames to see what the results were. Lo, and behold, my site and content descriptions had changed from carefully crafted statements and a handful of appropriate keywords to a laundry list of figures from the French Revolution, random pharmaceuticals and reviews of the latest japanese sports cars.
Well, I’ve learned my lesson about being lazy and allowing WordPress to upgrade itself. (I should have known better, given my professional background and am pretty embarrassed to admit my issue.)
Using Chris Pearson’s blog, specifically, his post, “How to Diagnose and Remove the WordPress Pharma Hack,” Ottopress’ “How to Cope with a Hacked Site,” (and “How to find a backdoor in a hacked WordPress“), Donncha‘s “Did your WordPress site get hacked?” and WordPress’ own “FAQ My site was hacked,” I was able to find the files affected and mitigate the damage (to the sites, not my ego).
There was only one suspicious database modification (I checked against the last 45 days of backups), three new php function files that were added into non-core directories, an odd change or two to my info.php, wp-config, expired WP-SuperCaches and Google site verification files and a ham-fisted, half-hearted attempt at building an RBC bank phishing site, similar to this example. It appears that they attempted to create a user, but weren’t able to do so, thanks to a couple of tweaks I had made. All in all, it only really appears to have affected my google rankings and meta descriptions (via an off-site redirect), which is why I didn’t even notice the modifications for two weeks.
It was, however, sophisticated enough to hide the injected keywords from Googlebot user-agents that didn’t actually originate from the Mountain View mothership, which is why it took me a little time to figure out, once I’d noticed yesterday evening. The other sneaky part was that they stuck some includes into the first lines of a couple of files, with enough tabs/spaces to push them past the first 180 or so columns, so they weren’t visible in a normal terminal window or BBedit. Too bad, for them, that MacOS X’s quicklook auto-wraps long lines.
The code resembled this backdoor; reinstalling the core WordPress, the theme files, plus all active plugins (and removing the inactive), crawling through my uploads directories and non-core WordPress directories, changing every shell password, wiping out my salt keys, plus a couple of complex BBedit queries. (Here are some additional WordPress hardening techniques.)