WordPress footer follies

I was all prepared to post a backlog of interesting stuff today when it came to my attention, thanks to alerts from Reinhard Handwerker and Vikram Thakur of Symantec, that some strange spammy stuff was happening on this site. I ended up spending the day rooting out bot droppings from my WordPress installation.

Yes, it’s true, I’d been lax about upgrading to the latest version. I was only a little behind, but perhaps that was enough. In any case, here are some details, which might be useful to others who find themselves victim to what I think of as the “wordpress footer exploit.” (I’ve already gotten email from a couple of other users who are battling the same problem. Al Gore, apparently, went through something similar.)

Skip the rest of this unless you’re a WordPress user in trouble looking for help!

Here were the gory details in my case. No doubt others will differ. I don’t have a clear sense of the starting point for the exploit — no doubt some little chink in the WordPress armor that I can only hope is no longer open in the current version.

My HTML source revealed a long list of spammy links in the WordPress footer — hidden from view but presumably accessible to the Googlebot. The first step in defeating them was to remove the php call to the wp_footer function from the footer template. (If you need that function for other plugins or users, you can add it back in once your code is cleaned up.)

That alone isn’t enough, alas. I also found 2-3 lines of code inserted into the main index.php file at the top level of the blog. The code that kept reinserting the spammy links into the footer even after they’d been deleted was located in a few lines added to the default-filters file in the wp-includes directory. Then I found two more completely new files had been added to wp-includes: one called “class-mail” and the other, deceptively simply named “apache.php,” which was a motherlode of mischief. (Thank you, though, oh hackers, for labeling your crud with ASCII art of a spider — it’s really helpful when one is scanning dozens of files to know that when you stumble on the malicious code, it comes with its very own Dark Mark.) “Classes.php” looked like it had been touched, too, based on the mod date; I replaced it with a clean version.

I killed all this crud and succeeded in removing the spammy links, but I still had a problem: there were a bunch of files that seemed to be being served from my domain that were just pages advertising, you know, those drugs that spammers like to advertise. They weren’t my content, of course, but they’d somehow made their way into my WordPress — and they were being linked to from other compromised WordPress sites. The ways of the botnets are devious indeed! I couldn’t figure out exactly where this infection’s root lay, but — having removed all the malicious code I could find and then changed all my passwords — I overwrote my WordPress installation with a clean download of the WordPress code, and that appeared to do the trick.

If you suspect your site is compromised, I recommend proceeding in the following order: First, root out the bad code; then change your passwords. If you change your passwords while your site is still compromised, you risk having your new passwords exposed via exactly the same route your old ones were, if in fact they were (I don’t know if mine were or not, but hey, when you start finding bad code in your directories, it’s time to change your passwords).

May you never need this information! But if you do need it, may this be of some use to you.
[tags]wordpress, spam, bots, exploits[/tags]