Home / server / Questions / 139258
Accepted
Lothar_Grimpsenbacher
Asked: 2010-05-06 19:14:56 +0800 CST

Got Hacked. Want to understand how

  • 772

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.

php security hacking

11 Answers

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

    • 9
  2. Best Answer

    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.

    • 9

  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)?

    • 2

  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!

    • 1

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

    • 1

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

    • 1

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

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

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

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