41

Someone has, for the second time, appended a chunk of javascript to a site I help run. This javascript hijacks Google adsense, inserting their own account number, and sticking ads all over.

The code is always appended, always in one specific directory (one used by a third party ad program), affects a number of files in a number of directories inside this one ad dir (20 or so) and is inserted at roughly the same overnight time. The adsense account belongs to a Chinese website (located in a town not an hour from where I will be in China next month. Maybe I should go bust heads... kidding, sort of), btw... here is the info on the site: http://serversiders.com/fhr.com.cn

So, how could they append text to these files? Is it related to the permissions set on the files (ranging from 755 to 644)? To the webserver user (it's on MediaTemple so it should be secure, yes?)? I mean, if you have a file that has permissions set to 777 I still can't just add code to it at will... how might they be doing this?

Here is a sample of the actual code for your viewing pleasure (and as you can see... not much to it. The real trick is how they got it in there):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Since a number of folks have mentioned it, here is what I have checked (and by checked I mean I looked around the time the files were modified for any weirdness and I grepped the files for POST statements and directory traversals:

  • access_log (nothing around the time except normal (i.e. excessive) msn bot traffic)
  • error_log (nothing but the usual file does not exist errors for innocuous looking files)
  • ssl_log (nothing but the usual)
  • messages_log (no FTP access in here except for me)

*UPDATE:** OK, solved it. Hackers from China had physically placed a file in our site that allows them to do all manner of administrative things (database access, delete and create files and dirs, you name it, they had access). We were lucky they didn't do something more destructive. There was nothing in the normal apache log files but I found a different set of log files in a web server log analyzer and the evidence was in there. They were accessing this file with their own admin username and password and then editing whatever they needed right there on the server. Their file has "apache" set as the user while all other files on our site have a different user name. Now I need to figure out how they physically got this file onto our system. I suspect blame for this will eventually rest with our web host (Media Temple), unless they actually had our FTP login... not sure how I will determine that, however, as this file has probably been there for a while.

7
  • 6
    I don't know, did you give someone your password?
    – WhirlWind
    May 6, 2010 at 3:18
  • 4
    If you know when exactly this happens, search your access_log for everything unusual around this time. Especially take a note of all POST requests: where do they go, what they did.
    – sanmai
    May 6, 2010 at 3:18
  • 2
    Actually if you know them, why not paste their address details on a anti-spamming site. Let the net "speak" to them and give them a taste of their own medacine. :-)
    – Derek Clarkson
    May 6, 2010 at 3:47
  • 4
    @gaoshan88 — more helpful then you might think. One attack vector is a Trojan that sniffs passwords from developers' ftp clients.
    – Quentin
    May 6, 2010 at 5:26
  • 1
    There is a chance that this problem is one of programming, but I going with belongs on Server Fault none-the-less because I think it more likely that it is a configuration and operation problem. May 6, 2010 at 16:05

11 Answers 11

9

First of all chmod 744 its NOT what you want. The point of chmod is to revoke access to other accounts on the system. Chmod 700 is far more secure than chmod 744. However Apache only needs the execute bit to run your php application.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data is commonly used as Apache's account which is used to execute the php. You could also run this command to see the user account:

`<?php
print system("whoami");
?>`

FTP is horribly insecure and it's very likely that you were hacked from this method. Using FTP you can make files writable, and then infect them again. Make sure you run an anti-virus on all machines with FTP access. There are viruses that sniff the local traffic for FTP user-names and passwords and then login and infect the files. If you care about security you'll use SFTP, which encrypts everything. Sending source code and passwords over the wire in clear text is total madness.

Another possibility is that you are using an old library or application. Visit the software vendor's site and make sure you are running the latest version.

4
  • 6
    +1, avoid FTP like plague. A password sniffer trojan can infect your computer and use your credentials to change files. Or it can infect your router. Or the computer of your neighbor at the netcafe with the unsecured wifi network. Sending out the password in clearext is a bad, bad idea.
    – Tgr
    May 6, 2010 at 11:15
  • 1
    FTP does come with SSL, you know. May 6, 2010 at 19:42
  • 1
    @grawity most people don't use "ftps", but that will keep you from getting hacked. sftp is more popular.
    – Rook
    May 6, 2010 at 20:44
  • 2
    The www-data should NOT own files in your web directory. Anything that www-data can be updated by a poorly written script on the server.
    – Zoredache
    Jun 25, 2010 at 4:46
9

My Media Temple Grid Server accounts have been "hacked" like this a number of times. Their security is very poor...started with PLAIN TEXT PASSWORDS last year and continues to this day (you could call tech support and they say "what's your password?"). I know because I get monthly emails about how they've changed all my account passwords and they actually go in and change database passwords for you every time they get hacked. That company looks glossy as hell on the surface, but the grid server is a mess. I recommend switching immediately.

Please see this post from last year about the original fiasco (warning, it will piss you off). It's gone downhill from there. I spent thanksgiving last year away from my family and removing porn links from my websites. Lovely.

Keep track of the fun on their status page: It'll tell you all about the latest exploits (and, yes indeed, there's a "possible exploit" up there right now).

1
2

Based on the lack of activity in access logs etc. and the fact that is happening at roughly the same time it would seem that they have compromised the server and have a shell script of some sort running to execute the appending.

Have you checked crontab for anything strange?

Have you tried to rename the directory and the references to it (this may break the shell script)?

1
  • renaming is a good idea. I'll try that once I see what effects it will have on the site. Crontab had one slightly strange thing, there is an entry for about the time the files were changed but it is the Plesk backup manager... a compiled application. If that is compromised then Media Temple has a big problem on their hands. May 6, 2010 at 4:58
1

Yes, it could most definitely be related to the file permissions. By having files that are writable by the web process, you're open to any security vulnerability in the web applications you're running. Lock everything down so the web process can't read or write anything more than it needs to.

The other component is tracking down exactly how they're modifying your files. Checking the web server's access logs is a good place to start. Check last login times for various users. You could also set up a script that monitors the files for modification, and notifies you so you can try and catch the criminals red handed!

1

This sounds awfully familiar to the Wordpress hacks that hit a slew of Network Solutions sites lately. Since you are on Media Temple, it's possible that you left some files visible to others users sharing your machine. That would explain the lack of POST or eery Apache log traces. If that's the case it would be deadly simple to inject code on the command line.

3
  • The logs show traffic around the time that these files were modified but it is innocuous stuff like: 207.46.13.43 - - [05/May/2010:01:42:26 -0700] "GET /oped/bpr.php?edid=211&page=4 HTTP/1.1" 404 257 "-" "msnbot/2.0b (+search.msn.com/msnbot.htm)" May 6, 2010 at 3:56
  • Do you know how that Wordpress hack worked? Might tell me how to fix my own problem. May 6, 2010 at 4:25
  • 2
    Yes, it was bad permissions on shared boxes, possibly caused by bad default configurations on the part of Network Solutions. Recommended fix was to lock down permissions as 755 on folders and 644 on files.
    – Anonymous
    May 6, 2010 at 14:53
1

The code is always appended, always in one specific directory

Is it related to the permissions set on the files (ranging from 755 to 644)? To the webserver user

Are you on a shared server? If so (or even if not), someone may have brute forced an FTP password and uploaded a script that appended any files it could get its hands on.

one used by a third party ad program

Or perhaps this program has an exploit.

6
  • I'm assuming it may be that the third party code has an exploit. It is on a shared server but I would have found any uploaded scripts (unless they uploaded it, used it and then deleted it but even then I would have found something in the log files showing their ftp connection) May 6, 2010 at 4:24
  • 1
    If your files are writeable by the webserver, it's possible they could have uploaded the script to any website on the server and overwrote your files. But I would also look closely at that 3rd party app.
    – Anonymous
    May 6, 2010 at 4:27
  • The third party code... is it an executable script or just a JavaScript snippet? JavaScript cannot modify files on server.
    – Salman A
    May 6, 2010 at 7:06
  • @Salman A - it is a collection of PHP scripts that manage advertising. May 6, 2010 at 12:29
  • OK, then I hope you have investigated that code.
    – Salman A
    May 6, 2010 at 14:05
1

If you have appropriate access (and kernel support), you could try to whip up a monitoring daemon based on inotify or dnotify to watch for changes to your files, then (quickly) use "lsof" to see what process has the file open with write access. You might also be able to use strace for monitoring. That should provide a clue as to what executable is being exploited.

1

FTP inspecting logs is the first place to start. The log should contain most if not all activity along with timestamps so if you know what time your files were modified you can determine if your FTP account is compromised or not.

Next, it could be a script on your webserver that is injecting that code. In a shared hosting scenario, I think its possible to do a cat /web/malicious.com/script.js >> /web/innocent.com/index.php. This might work under certain conditions, such as the command being executed by httpd user and index.php file is also owned/writable by that user. In that case you should have your hosting provider to trace the account being used to inject the scripts.

1

Most site files need to readable by the web server. On a read only site, only the logs need to be writeable by the web server. set the owner to someone other than the used by the web server. Set protection 640 on all files except scripts. Set scripts and directories 750. For files or directories that need to be written by the websever you can change the owner to the web server or set the chmod g+2 the relevant files or directories.

1
  • Non-CGI scripts can often have mode 600 or 640 (depending on the file owner & group and what user the web server runs as), since many scripts are passed to an interpreter.
    – outis
    May 14, 2010 at 11:37
0

There are a zillion possible ways to crack a site. They could have used a vulnerability in your script, stolen your password, used a vulnerability of a co-hosted site (if you are at a cheap host), used a vulnerability of some non-web-related service on the server machine...

As a first step, check the file modifiaction date, and check the access, error and ftp logs for any suspicious activity at that time.

0

The same thing happened to me a while back. Wordpress was the only software that would have caused something like this as far as I know.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .