views:

83

answers:

4

We recently got a call from one of our clients, complaining that their site has some "strange looking code" at the bottom of the page. We checked out the source code, and discovered that about 800 bytes of malicious javascript code had been appended to the templates/master file, after the </html> tag. I won't post said code because it looked particularly nasty.

As far as I can tell, there would be no way for this file to be edited in any way, unless someone had direct access to the server and/or FTP login details. The actual file itself has been modified, so that rules out any kind of SQL attack. Besides a person physically gaining credentials and hand-modifying this file, would there be any other logical explaination for what happened? Has anyone else had experience with something like this happening?

+2  A: 

If the attacker doesn't have other file access, it's likely that there is an exploit in the code somewhere that allows the user to execute arbitrary code. Use of passthru(), exec() and eval() are common problems here. If there is FTP running on the same machine, that's typically a strong attack vector as well.

I'm not sure that I would categorically rule out a SQL attack (especially a reflected one combined with the above exploits), but it's not clear that it would be one, either.


To your question, it could be either automated or personally targeted, it's hard to say with the level of detail given. As others have said, switch out as many passwords as you can, restrict access to the server, and then start inspecting logs to see where things went wrong. That will be more successful than ripping apart the app itself.

Joseph Mastey
The other common option is that a computer running an ftp client has been compromised and the credentials sniffed.
David Dorward
The reason I say no SQL is because the physical file was modified. It would require the attacker to guess the location of our template files (granted, not particularly obscure). Could this be some kind of automated attack, or would it most likely be personally targeted?
Jeriko
+1  A: 

Almost certainly compromised credentials allowing someone to alter the code remotely. Is the server located on site?

Laplace
No, it's geographically about 50km from us. This happened on two of the three subdomains for this client's domain. I guess my main concern is whether to change FTP passwords, or absolutely rip the site apart testing it..
Jeriko
Why not do both? Change passwords and otherwise restrict access as far as you can, then get to work figuring out what happened.
David Wolever
If ftp's been owned once then more than likely changing passwords won't cause your hacker anything more than an inconvenience. See my answer, remove FTP and use SFTP
Cruachan
+3  A: 

The places I'd check are:

  • File modification times (to see when it happened)
  • HTTP server logs for signs of funny-looking GET params (eg, ?foo=exec('...'))
  • FTP server logs
  • SSH logs (something similar happened to me once, and it was because someone gave out their password)

Also, I'd immediately restrict write access to all the site's files, just to be safe from the same attack (of course, the vector is still open, but it's better than nothing).

David Wolever
+2  A: 

You don't specify, but if you are you shouldn't be using FTP on a production server anyway because it's inherently unsafe (among other things it transmits credentials in plaintext, making you easily prey to a sniffing attack). Always use SFTP.

If you are using plain FTP this is most likely the attack vector, particularly as modifying the files is all that as happened. If your machine has been completely penetrated I'd have expected to see more than that.

Cruachan