One of the websites that I was responsible for running was the target of a hack that turned its search results in the major search engines to something like “Adobe Cs3 180% discount software off”. This is obviously not a good state of affairs because:
- It looks stupid in Google
- You have an open security hole on your website that can be used for god knows what else
- It looks really stupid in Google
I wrote this post in the hopes that if you encounter the same hack, you’ll be able to solve it quicker.
First steps
The very first thing you want to do when confronting any sort of hack is making a back-up of your entire site, and copying it to another host. If you have access to a shell, you can do this with the tar utility:
tar -cvjf backup.tar.bz2 folders-to-back-up/
This will let you examine files offline and if need be, purge entire sections of your site and restore them later.
Next, you need to take a step back and think to yourself, “what are the symptoms of this hack?” In my case, spammy search results and the inability to view the website whenever clicking a link from Google. The site worked fine otherwise, so something was redirecting all http requests. The website is run off Apache on Dreamhost shared hosting, so either the host is compromised somehow (unlikely, since Dreamhost would notice) or Apache is redirecting all http requests.
The only way I knew you could get Apache to modify requests like that was through the use of .htaccess files. Lo and behold, the .htaccess file in the root directory had the following code:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|aol|slurp|bing) [OR]
RewriteCond %{HTTP_REFERER} (google|aol|yahoo|search|bing)
RewriteCond %{REQUEST_URI} /$ [OR]
RewriteCond %{REQUEST_FILENAME} (html|htm|php)$ [NC]
RewriteCond %{REQUEST_FILENAME} !sitemap.php
RewriteCond sitemap.php -f
RewriteRule ^.*$ /sitemap.php [L]
</IfModule>
mod_rewrite is an Apache module that allows the seamless (to the client) redirection of files. This particular mod_rewrite script redirects all of the search engines crawler bots, and any links referred by them to be handled by sitemap.php. This sounds a normal part of a website, but what was odd about it was that it used a ton of eval() and base64decode() functions. This should be a big warning for you; even the worst PHP code doesn’t use 100′s of calls to these functions. When eval() and base64decode() are used together it’s only to obfuscate code.
So I deleted all those bad .htaccess files and the sitemap.php, and declared myself victorious. Too early because 24 hours later, the spam was back on Google.
Actually fixing the problem
So we could go back and forth with the hacker uploading these .htaccess files, but that would never solve the problem, only the symptoms. The first and most obvious step was to update WordPress to version 3.1.4; it was running 2.7, which likely had exploits that the hacker was using to upload files. As a precaution, I also changed passwords on all of the accounts. But the hacker was still able to upload files!
While I was getting ready to nuke the entire site from orbit, I decided to run a WordPress plugin called Exploit Scanner. It scans all of the files in your WordPress install, verifies them with md5sum, and scans the rest of suspicious code. In my case, it found one file with a huge number of eval() calls. And it also turned out to be how the hacker uploaded files to the site! You can see the interface here. And you can see the code for it here.
48 hours and the spam hasn’t come back, so mission accomplished. The last thing to do is secure the site so it can’t get exploited again.
Closing the stable door after the horse has bolted
The best source for this info is WordPress themselves. You’ll want to follow every single step in that guide. Especially the part about keeping it up to date.