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.

Read 10 comments and join the conversation 

What’s the perfect gift for a guy who’s obsessed with disk emulation for antique Apple computers? How about a 5 1/4 inch floppy disk signed by Steve Wozniak, inventor of the Apple II. Bonus points if you know what D5 AA 96 means!

Read 18 comments and join the conversation 

11 minutes of unrehearsed video showing off the new Apple II firmware features of Floppy Emu. And you get to see what a mess my desk is.

Read 2 comments and join the conversation 

Fancy a 2 GB mass storage solution for your Apple IIGS? Last week I released new Smartport-capable firmware for the Floppy Emu disk emulator. It can emulate up to four simultaneous Smartport hard drives, which I thought were limited to 32 MB each, but it turns out that’s not true! As Ken Buchholz of Apple2Online.com explained to me, 32 MB is the maximum size of a ProDOS volume, but the underlying Smartport protocol supports drive sizes up to 8 GB. By using a filesystem other than ProDOS that supports larger volume sizes, you can take advantage of that extra potential.

So what filesystem should you use? On the Apple IIGS, the computer must boot from a ProDOS volume, but under GS/OS 6.0.1 it can mount secondary volumes in HFS format – the same filesystem format used by vintage Macintosh computers. Of course you won’t be storing Macintosh files in that volume, but Apple II files. HFS supports volume sizes up to 2 GB, so if you combine a 32 MB primary ProDOS volume for booting with a 2 GB secondary HFS volume for all your warez, you’ll be good to go! On a IIGS with the Floppy Emu under Smartport emulation mode, this is as easy as putting two files on your SD card: a 32 MB smart0.PO containing GS/OS 6.0.1, and a larger (up to 2 GB) smart1.PO formatted as an HFS volume, containing whatever other files you want. Apple2Online has some blank HFS disk images of various sizes in their CFFA3000 area, which are perfect for Apple II usage.

The screenshot below shows a 512 MB HFS volume, with a few Apple II files stored on it. I got impatient and didn’t want to wait for a 2 GB disk image to copy to my SD card. 🙂

There’s one extra wrinkle to watch out for when using very large disk images like these. Due to the way it works, Floppy Emu requires all disk images to be contiguous on the SD card. A 500 sector image must occupy the contiguous range from sector N to sector N+499, or else Floppy Emu will display an “image not contiguous” error when it mounts the image. For smaller disk images this is rarely a problem, but for a large disk image on an SD card with some fragmentation, it’s more likely to be an issue. If necessary, you can reformat your SD card, then copy the large disk image to it first, in order to guarantee it will be contiguous.

New Apple II firmware apple-II-0.1G-F4 adds support for parsing the HFS volume name of a large disk image, so it’s displayed correctly on the Floppy Emu’s LCD. Have fun!

Read 13 comments and join the conversation