Thread

For the first time in seven years, one my Websites was hacked last week.

I imagine that there are many ways that hackers go about this, but to the extent that there might be commonalities for EE sites, thought I’d lay out how I recovered from the hack in hopes it might save some time for others.

First, I was getting downtime reports from the Pingdom and a note from the client that the site was down (clients always seem to be on their sites when they go down!). Downtime happens sometimes of course, so I dropped a ticket with the host (Rackspace Cloudsites) because I didn’t see downtime on their system status blog. I didn’t really think it was anything other than routine at this point.

The host responded back to my ticket saying that my site was compromised. They recommended I look at my cgi-bin directory and check out their support page on the issue:
http://cloudsites.rackspacecloud.com/index.php/Recovering_from_and_Dealing_with_a_Site_Compromise
(it’s a helpful page no matter what host/cms you’re using).

Sure enough, there were a bunch of evil files in my cgi-bin directory, which is normally empty. I emptied it.

I also backed up all the files on my system and my database, which is always backed up anyway, but at this point I had no way of knowing the extent of the attack.

I think emptying the cgi-bin directory essentially stopped the hackers, but my site was not coming up. I was getting white screens.

After some trial and error, I found that the index.php file had been changed to redirect users. It wasn’t apparent at first because most of the file looked the same (I missed it the first time around) on visual inspection.

I downloaded a current version of the index.php file from the EE Website (my install was at the latest version anyway) and uploaded that to my server. That solved the problem. It seems so easy now, but then it didn’t.

I changed all the passwords on my account to secure passwords (they were secure before, but go figure), including the FTP password, the database password and my account password. I use OnePassword which generates passwords using various criteria.

Takeaways: use Pingdom or some other monitoring service on all your sites so you are aware of your sites’ activity. Use super secure passwords and SFTP if possible (my host allows SFTP but I didn’t know before this incident, I know that Engine Hosting uses it too).

Now that I’m using EE2.0 more, I’m making my installs above root (not sure why I wasn’t doing this before 2.0 but it seemed like a pain then), which I think should help too.

Hope that helps someone at least save some time and headache.

As useful as some of the info is, it doesn’t really tell us the cause of the problem. It sounds to me like a simple matter of incorrect permissions that was your downfall but then again without more info it’s very hard to tell.

What version of EE were you running?

What do you mean? I’m not sure how this was my fault. I would never have changed permissions on my cgi-bin directory. Are you recommending changing permissions on files and directories beyond what ExpressionEngine recommends in the docs? Please let me know if there’s something I’m missing here.

I’ve built 70 Expression Engine sites, follow security issues and best practices and this is the first time this has happened.

I wasn’t insinuating anything was your fault!

My point is that your post doesn’t actually specifically tell us how your site was hacked / compromised. That was all.

If anything i was thinking that the cgi-bin had the permissions problem, which gave the hacker enough of an in on your server to be able to modify your index.php. I doubt you even use the cgi-bin folder, so i doubt it is your fault.

cgi-bin is below root on my server and there are no world permissions on it, so I can only imagine this was only a matter of password hacking. That was my assumption, but should have been more clear about that in my post.

For what it’s worth, EngineHosting, whom I know takes security very seriously, has cgi-bin with world permissions at root level. That would lead me to believe that that isn’t the security hole.

Fair enough.

I see what you guys are getting at audiopleb and @boyink (from twitter). I should have been more clear about this. I didn’t mean that this was an ExpressionEngine specific hacker or that there was an EE security hole.

That didn’t cross my mind because as far as I can tell this was a password hack at my host, having more to do with FTP (I wasn’t using SFTP at the time) than anything, because my password wasn’t an insecure password.

I ‘think’ this is fairly common. Have a look at Google’s Safe Browsing Diagnostic page and you’ll see lots of sites on your host have some sort of compromise.

For me, this was merely hoping to reinforce good practices with others and hopefully save somebody some time.

Coming from a Joomla background i’ve fixed more hacked sites than i’ve had hot dinners (99.9% not my own you understand!) so i was very interested in what had occurred here.

I also wanted to see if there were any common themes between the two CMS when it comes to how they might be hacked. For example, in Joomla, one of the most common reasons it gets hacked is because of insecure third party modules/components/whatevers.

I’m glad your problem is resolved and i’m glad it wasn’t an EE based problem.