6

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?

Joe Mastey
  • 26,809
  • 13
  • 80
  • 104
Jeriko
  • 6,547
  • 4
  • 28
  • 40

7 Answers7

7

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
  • 148,955
  • 89
  • 346
  • 502
3

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.

Joe Mastey
  • 26,809
  • 13
  • 80
  • 104
  • 3
    The other common option is that a computer running an ftp client has been compromised and the credentials sniffed. – Quentin May 25 '10 at 14:07
  • 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 May 25 '10 at 14:13
3

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
  • 15,733
  • 5
  • 59
  • 112
1

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

Laplace
  • 491
  • 1
  • 3
  • 9
  • 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 May 25 '10 at 14:12
  • 1
    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 May 25 '10 at 14:14
  • 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 May 25 '10 at 14:21
1

Here is how I see it. Using an FTP program? Your ftp log files storing passwords, paths ect.. gets grabbed. The passwords get decoded.

Try not to store FTP passwords in the FTP client. Or do like above, use SFTP. We had a similar issue and seems to have come from one computer with a set of FTP logins. Also as this computer had many previous odd issues with it. Javascript would not work right, odd session timeouts or simply removed. Which to me indicates this computer had something on it.

Neotropic
  • 11
  • 1
0

Do make sure to find and remove any suspicious files in your website. If they had access to FTP, most likely they left a backdoor script somewhere which would enable them to upload/modify files on your website via a specific URL even after you change your FTP password or switch to using SFTP.

Try running the script found here if you're using PHP.

TrialAndMoreError
  • 21
  • 1
0

To detect a existing malicious code, I recommend that you use a good anti-malware scan engine on the server to detect malicious code on the website´s files. Many times, the server isn't vulnerable, but the website is! To prevent this, use a Web Application Firewall that can take a look on every request to detect and block a attack attempt.

user2538743
  • 93
  • 2
  • 5