I spent the evening fighting an infection on a client’s web server hosted by a third party. It was a bloody nightmare. I’m posting here to help any other wayward travelers who run into this issue as I think this is going to be the next big security storm. I also want to point you to the Unmask Parasites blog, which has become the de facto rallying point for folks trying to eliminate this scourge.
The Symptoms
Visitors to your site are either warned by their anti-virus program that a trojan is attempting to install (it will indicate it’s either “JSRedir-R” or “Gumblar.cn”) or, if they’re poorly protected, they’ll simply become infected with one of a number of pieces of malware, which will slow down their machines and potentially search for and send login information – specifically FTP login information – back to some master site. Some folks have reported seeing a lot of traffic to a site domain called “gumblar.cn” when doing a “netstat” on the command line.
Your visitors are infected because of some nasty bits of JavaScript and PHP that are embedded throughout files on your site. In my client’s case, I found more than 130 files that had been infected, which included PHP class files, PHP include files, index*.php files (i.e. index.php, index2.php, index-old.php) most static HTML files and all .js files.
For PHP files, you’ll typically find one long line of code at the very top of the file next to the opening PHP statement. It will resemble something like “<?php if(!function_exists(‘tmp_lkojfghx’))…”. Kill that line and that file should then be clean.
For HTML files, the code injects itself between the closing <HEAD> tag and the opening <BODY> tag, so it will resemble something like:
</head>
<script language=javascript><!–
(function(GxC){var tRUO=’%’[...](/~/g);
–></script><BODY…
Remove the entire script block and it should be clean.
For JavaScript files, look at the very bottom fo the file for a line similar to this:
<!–
(function(GxC){var tRUO=’%’[...](/~/g);
–>
Remove the entire block and you should be clean.
The last thing to look for are image.php files located in all directories named “/image/”. These will contain a single line of code that is not at all like the others and may be the way this thing tries to re-infect machines. I opened each of these, removed the line of code and saved the file as an empty file. I then changed the permissions on it to read-only. This will, hopefully, prevent them from being accessed again if the server gets reinfected. And, from the sound of things, reinfection is common.
The Cure
Simply remove the lines of code I mentioned above and you should be clean. To identify exactly which files were infected, I used a PHP script written by “rad-one” – a poster on the Unmask Parasites comments – and modified it slightly so that it ran better from the command line. You can download it in a ZIP format by clicking here. I took the “FOUND” lines, printed it out and then, one by one, opened each file and removed the offending line of code. I’m not sure there’s a reliable way to automate this process – especially if you’re running a rather complexly coded PHP site – as it relies on finding function calls that may actually be legitimate. The trojan modifies the variable and function names per infection, so there’s really no reliable way to know the code this script finds is good or bad. You’ll just have to hand-verify.
As for how you got infected in the first place, this seems to be a bit of a mystery still, though there are a lot of clues indicating that the infection can stem from a compromised computer that contains FTP usernames and passwords like those stored in Filezilla or other FTP programs. Run a solid anti-virus program on your machine (I like Avast – it caught the attempted infection the second I loaded the website) as well as one or more anti-malware programs (I like MalwareBytes and Spybot Search and Destroy). Dot his for every computer that accesses your web site via FTP. You may also want to change your FTP password and switch to SFTP if feasible. Or, better yet, set up a scheme using scp or rsync, perhaps in conjunction with svn to maintain a history of your files so that, in case of another infection, it’s a fairly minor piece of work to replace the infected site with a known clean version.
I’d love to hear if you have any other information about this. Please feel free to leave comments below.
