Ack! I had a hack attack!

If you visited this site during a three day period in the middle of July you would have found it to consist of a single page supporting the liberation of Iraq. I am not a terribly political guy, especially not with foreign politics, so the single page message was not me. Hackers (or script kiddies perhaps) had managed to gain access to my CMS and defaced my blog. Why this site, one that gets two visitors on a good day, I am still unsure. When I noticed I quickly put things back right and figured the events would equate to a source of blog posting material for me.

I was so eager to rectify the problems with my site, I didn’t do a whole lot of analysis of how they entered the CMS and their exploits. I did look enough that I think I’ve closed the holes and am now being more proactive with the security of this simple little blog.

I use a well known blogging CMS, as opposed to handwritten code or home-grown blogging software, so possible exploits for the CMS were known by the attacker. Sure enough, the system had been bugging me for weeks about installing security patches to the CMS. I ignored them wanting to wait for more time to do the update and figured the delay wouldn’t matter in my case. Oops.

The attacker used an IP address originating from Egypt. The used an exploit in the CMS to change the email address on my administrator account and then reset the password. At that point they had full administrative access to this blog and another one that I run. A customized theme was installed which included additional back-door access and hacker-esque functionality to the site. On one of the two blogs within the system they changed the period of time that the cron job runs to three hours. I assume this was to have the system check-in with a command and control server to receive updates if any are available.

When I discovered the hack I had to login to the server directly and revert some changes made to an index.php file. I’m still not quite sure how they modified that file. I’m assuming their custom theme provided additional access to modifying other files. I also reset my password and the email address associated with the administrator account. As far as I can tell, the password for accessing the server directly was not compromised.

Once the original index.php file was in place I was able to regain access to the administrative functions of my CMS and yank out the custom theme that was installed. Thankfully, my browser’s cookies had me still logged in with the administrator account so that I could make these changes. If I were logged out, with the hacker having changed the password, it would not have been fun getting back in.

In the end I managed to get the site back to normal with only a mild anxiety attack. Immediately after fixing everything I ran the security updates that I had been getting nagged about. In the days since then I’ve been keeping a close eye on the access logs. I’ve seen IP addresses trying to access pages they shouldn’t be trying to access, in some cases pages that don’t exist because they are targeting the wrong CMS. When I see this happen, I block the IP address at the server level. I contemplated blocking big swaths of IP address ranges based upon a single IP address, thinking it would eliminate someone from obtaining a new address from their ISP. I declined to do so, and haven’t seen any similar addresses pop up. I do have close to a dozen IP addresses in my blocked list and life on my blog is calming down again.