Web Site Hacked
Web Hack Analysis Part 2
Web Hack Analysis Part 3

It’s Monday morning, and the BMOW web site has been hacked. In fact all six of my web sites at my shared hosting service have been hacked. Yuck! I think I’ve cleaned up the mess successfully, but I wasn’t able to determine how the hack originally occurred, so I’m not sure it won’t happen again.

 
Google Site Verification

I discovered the hack this morning, when I received an email notifying me that some email address I’d never heard of had been added as an owner of the Google Search Console account for http://bigmessowires.com/. Google Search Console is a developer tool that enables the owner of a web site to see how Google’s web crawler views it, and learn about potential problems with the site. At first I thought this might be a clever phishing scam – click the link in the email to be directed to a web site with some kind of drive-by download attack – but after closer inspection the email looked legitimate.

I logged in to the Google Search Console (by navigating there directly, instead of the email’s link), and sure enough some.evil.dude@gmail.com (not the real address) had been added as an owner about 4 hours before. That shouldn’t be possible – to add yourself as the owner of a web site, Google Search Console requires you to prove your ownership by placing a specially-named file on the site. In this case, the hacker was required to place a file called google1a74e5bf969ded17.html on the site, with the contents “google-site-verification: googlea174e5bf969ded17.html” Google would then attempt to access the file and check its contents to verify the new owner. So I logged in to my server with ssh and checked the directory contents, and there was no file named google1a74e5bf969ded17.html. But when I pointed my web browser to /google1a74e5bf969ded17.html, the expected contents somehow magically appeared!

How can a request for a non-existent file on the web server return a seemingly valid file with the expected contents? Lots of ways. After doing a bit of experimenting, I discovered that any request for /googleNNNNNNNN.html would return a fake file with the contents “google-site-verification: googleNNNNNNNN.html” Something was procedurally generating valid-looking site verifications for any token ID, enabling anyone who wanted to to add themselves as an owner of my site with Google Search Console.

When you visit http://www.bigmessowires.com, a file on the server named index.php gets executed, and it generates the HTML content that’s ultimately displayed in your web browser. This index.php file is part of WordPress, the software I use to maintain the site. But when I opened index.php in an editor, I discovered that some new and evil-looking PHP code had been inserted at the top, in front of the regular WordPress code:

Welcome to code obfuscation city. I don’t know what all that code does, but I’m betting part of it is to recognize any Google site verification requests, and auto-generate a valid-looking response. And that check for “undermomocontrol” doesn’t look good.

After deleting the evil code at the top of index.php, I was able to remove the hacker’s email from the list of Google Search Console owners. It’s not clear to me why he bothered to add himself as an owner there, since I don’t think there’s anything you can actually change about the site or its search settings through that interface. Maybe he somehow redirected all BMOW search traffic to a site about Gucci handbags? I hope there wasn’t some hidden damage performed through the search console that I overlooked.

Incidentally, while I was poking around the Google Search Console site, I discovered that Google had sent me an email on May 8 about suspected hacking activity on my site. But my email client identified it as junk and sent it to the trash. 🙁

 
Examining the Hack

By checking the modification times on the files in each web directory, I was able to determine which files had been compromised. Here’s another of my web sites, that formerly contained only a static index.html file and a few zip files:

The hacker added new files named your.php, book.php, and clsssica.php. These contained more obfuscated PHP code. He also renamed my former index.html to index.php, and inserted the same evil header code as seen on the BMOW web site. And lastly, he added a .htaccess file, which controls how the Apache web server handles requests:

I’m not an Apache guru, but I think the two RewriteConds and the final RewriteRule are what’s important here. If Apache receives a request where the requested filename is neither a real file nor a real directory on the server, then the request will be remapped to index.php. This enables the evil code to run that auto-generates Google site verification responses.

The pattern of hacking was identical in all six web sites that I checked, all of which are subdirectories owned by my same Linux user account on the shared hosting server. In every case, the three files your.php, book.php, and clsssica.php were added. If index.php already existed, evil code was added to it. If only an index.html previously existed, it was renamed to index.php and the evil code was added. Then the .htaccess file was modified with the new rewrite rules, or the file was created if no .htaccess existed before.

I did some searching to see if these filenames and pattern of hacking are part of any known PHP or WordPress vulnerability, but I found nothing. As far as I can tell, this is a new hack.

 
Cleanup and Prevention

I deleted all the evil files from all the web directories, and removed the evil code from index.php, and the unwanted rewrite rules from .htaccess. Then I removed write permissions from index.php, .htaccess, and the root directory of each web site, to make them more difficult to reinfect. I also changed the admin password for each WordPress installation, and made sure each was upgraded to the latest version of WordPress. And I changed my password for the shared hosting account.

Steps to Take When your PHP Site has been Hacked contained a lot of useful suggestions for finding and cleaning up parts of the infection. Using the methods described there, I recursively checked all the subdirectories on each web site for potentially infected files, including PHP code hidden inside of image uploads and other sneaky things. I didn’t find anything – as far as I can tell, the files I mentioned previously were the only ones modified on each site.

So how did this happen? It appears that the original infection occurred on May 2, which is when your.php, book.php, and clsssica.php appeared on each site. But activity continued for some time after that. Index.php was modified just a couple of days ago. My web host only maintains a single week’s worth of server logs, so I don’t have any way of seeing what happened on May 2.

Did the infection occur through a WordPress vulnerability? Possibly, but only two of the six infected web sites were running WordPress. Given the way the sites are configured on the shared hosting server, though, it might be possible for an evil PHP script running as part of one web site to modify files in my other web sites. All six web sites exist as subdirectories in the home directory of my Linux user account on the server. If a PHP script that was launched due to a request for http://www.bigmessowires.com can do

<?php fopen("../www.stevechamberlin.com/clsssica.php", "w"); ?>

then the infection can easily spread from one site to another. I don’t know if PHP is configured this way by my hosting provider, but I suspect it is. There was a seventh defunct web site in my account, which was also infected. This was a subdirectory that contained all the files for a web site, but there was no hosting provided for that web site, and no way to access it through the web server. The fact that it got infected anyway means that the infection didn’t come from a direct web attack on that site. Hmmm.

It’s also possible that someone guessed my password for the shared hosting account, or sniffed it with a keylogger or some other tool. Or maybe the shared hosting server itself was compromised, through some vector exposed by another customer on that server, or a vulnerability in the server itself as configured by my hosting provider. It seems unlikely that I’ll ever know the true answer.