Got Hacked. Want to understand how
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.
Solution 1:
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.
Solution 2:
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).
Solution 3:
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)?
Solution 4:
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!