Determining the point of compromise on an infected web server?

Question

Recently a friend of mine has had his web server compromised - all PHP files were injected with malicious code, in particular one that looks to be called "GetMama". If I look this up, it seems that most people say it's a piece of malware which targets WordPress installations (and I can't find anything to the contrary). His site however doesn't have any WordPress installations on it. The server is shared hosting courtesy of BlueHost, with SSH/FTP access. If GetMama is meant to be an automated virus, I'd love to know how it compromised the site without any WordPress installations. After cleaning GetMama up from all infected files with some regex magic, a few days later it would be back. I searched the site for any sign of compromise but I wasn't able to find any. The access logs only seem to date back 24 hours or less (I'm not sure if this is BlueHost policy or logs getting wiped). Other symptoms included a manual compromise of the forum administrator's account, injecting malicious code into vBulletin's templates. The site owner changed the passwords, and there were no further forum compromises. After thinking the site was finally clean for a while, malicious JS was sent to users by a 301 redirect in a .htaccess file.

Basically, I'd appreciate knowing how you guys would deal with a situation like this. I can't work out how to find the point of compromise. For example, that .htaccess file popped up in the last few days, but there's no recorded data on how - only when. Same with the malicious PHP code injection, I don't see any data on what modified those files. We changed passwords, but even so, SSH doesn't report any unauthorised users logged in in the past few months (at least). What methods could I use to analyse future infections and locate their point of compromise (bearing in mind I'm on shared hosting without root privileges to work with)?

Answer 1

Ah, the joys of shared hosting. You can be 99.9% sure that in this incident, another shared hosting service on the same server, which is running WordPress, was hacked by this automated script. This would answer the first part of your question.

The underlying question is 'how did somebody else's account being compromised affect MY account?'. If this GetMama auto-attack didn't run some kind of PHP exec() command to exploit a Linux vulnerability then there's some kind of permissions issue going on that BlueHost need to address. These things can get in to other accounts by many ways, including through shared database servers with incorrect user permissions specified.

(disclaimer - this is a general answer, I didn't google 'GetMama' at all)

All in all it's a prime example of the importance of keeping your webapps up to date. Especially popular packages such as WordPress or vBulletin as their wide-spread use makes them obvious targets. Keeping things up to date helps to keep your site safer and also helps you be a good neighbour by reducing the potential of trouble for other users. Same goes for people running the servers.

Best way to protect against this is to not use shared hosting. These days a low-spec VPS can be found for the price of decent shared hosting (~$30/m).

Answer 2

• Start by changing the password to your webserver.
• Take the website offline, you don't want to infect visitors with malicious code served by your website.

Then:

• Start by checking when the first files (or their ownership/permission) changes. This can easily be done from the daily backups you make. Normally files that don't change are not in incremental backups, so if your logs all of sudden start to show .php files then you have determined the day that the files were changed. Of course log files should be in the backup too.
• Another, but less reliable method is checking the time/date stamp on various fileson the server. This method is less reliable, because timestamps can easily be changed to anything you want.
• Now you have a date, check the (apache) log files. Both error and access logs and see if you can find the attack between normal traffic.
• Check ownership and permissions on the files. Are you the only one who can write to the files and directories? Are you and the webserver (apache?) the only ones with read access to the files?

Then:

• Restore all files from backup and fix the vulnerability before going back online. If you don't find and fix the vulnerability, you'll be hacked again in a couple of days.

Answer 3

Similar thing happened to me on my MediaWiki and WordPress installations. Here is how I dealt with it.

1. As mentioned in other answers, change your passwords. I changed them all just to be safe: site admin, FTP, SSH, all the app admin passwords, the MySQL passwords, etc. This should be done periodically anyway, so right after you've been hacked is probably a really good time to get yourself back into the routine.
2. Upgraded all my application instances to the latest version. My MediaWiki install was a couple of minor versions out of date.
3. If the version of PHP you are running has the php_register_variable_ex vulnerability, change it. Mine did. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0830
4. Ran Paulo's PHP cleanup tool. http://www.php-beginners.com/solve-wordpress-malware-script-attack-fix.html#id-download. I had to run this a few times to get everything.
5. As also mentioned, check your file and directory permissions and make sure you don't have open write permission on anything you don't specifically want that on. I had some Yahoo weather widget on one of my WordPress installations that had 777 on a cache directory. Got rid of that.

After these 5 steps, I have not had a recurrence of this attack on any of my sites. They've been clean for months now.

I used this as a reference when I cleaned up my sites: http://discussion.dreamhost.com/thread-134262.html?highlight=virus.

Answer 4

Since it's a shared hosting, it's quite probable someone else's account is compromised and used to read/write files of the other accounts. It's difficult to tell how to solve it without knowing how the server is configured. If the php scripts run as your account user you could start checking the permissions of your files and directories to ensure that they don't have read/write access for everyone.