I am running Plesk 9.5 on Ubuntu 8.04 LTS and have about 15 websites infected with some malicious code appended to the end of java files. I have installed Clamav and it has managed to pickup the infected files which have a pattern of starting with either /*km0ae9gr6m*/ or /*gootkitstart*/ and ending with /*qhk6sa6g1c*/ or /*gootkitend*/
My Plesk panel is up to date and security patches were installed. How can I isolate the security vulnerability on the server?
First, if there's a rootkit, you're probably fighting a neverending fight. Take the server offline and reinstall and restore backups that are pre-infection. That's the "best" method of fixing.
Second, were you up to date on patches and such before the infection or did you patch after?
Third, what custom code is running on the server outside Plesk? How do you know that was even the infection vector?
Without auditing and sandboxing, you're going to have a hard time telling what happened. If there's a database running on it, someone could have faulty code on the system. If someone else has access to the server, maybe they did something to infect it. Are the websites running with different file permissions to silo possible damage? Or are the sites pretty much sharing all the resources? Are other users involved and able to run scripts? Do they have different widgets and whatnots installed? Were the files timestamped, so you could go back into the logs to try to glean what happened?
If the logs are on the same server that was compromised, the logs could have been altered as well.
In the end, the best thing to do is take the server offline and fix it by reinstalling from backups. Otherwise you can't fully trust it. And if you have any "personal" data (user passwords?) they need to be informed that their information may have been stolen. Then start setting up some kind of auditing on the system, and send logfiles to a secondary server over a safe channel of communication so logs can't be erased by an intruder. And run some kind of file checking utility like Stealth on another server to monitor your file integrity and warn you of changes.
Without knowing what else your server runs, there's little other people can do to tell you how it was compromised.
There is no generic approach - it's all hands-on. You typically would need to have configured extensive logging, preferably not only from the system you are inspecting but also from an independent IDS, which you are periodically archiving. Also, a good bunch of experience with computer security and forensics is required, otherwise you don't stand a chance.
But as Malware today typically is doing mass-infections, chances are good that the work has already be done for you:
http://www.m86security.com/labs/i/GootKit--Automated-Website-Infection,trace.1368~.asp
Obviously, attackers do not infect hundreds of web pages by hand, they use a script or a botnet to do the work for them. [...] One other such bot is known as GootKit. [...] We are unsure exactly how the control server obtained all of the FTP credentials, but most often these are stolen via keyloggers and information stealing malware installed on a website administrators PC.
We have seen this on plesk 9.5 servers despite having Parallel's security patches installed from February.
Basically they are POSTing to the login page and getting in without auth, then going straight for the WYSIWYG file manager and appending the code to js files. Plesk are refusing to acknowledge this and the only option is to firewall plesk off and allow to specific IPs.
You will find the POSTs in the httpsd_access log in plesks admin/log directory.
A global sed will remove the code as fortunately they all start with the same string.
After a couple of horror weeks loosing clients and being re-infected we received this reply from technical support at Parallels:
Please note that all of the vulnerability issues reported over the Internet or our forums actually trace back to an old vulnerability in Plesk, which is fully described in the following KB article:
http://kb.parallels.com/113321
Article #114379 also mentions this information. Please thoroughly check article #113321 and the related articles in order to verify the issue's presence, install all the necessary microupdates and ensure that the server is protected via mass password reset:
http://kb.parallels.com/en/113424 http://kb.parallels.com/en/9294 http://kb.parallels.com/en/113391
What's rather interesting though with reference to the first statement is that on the 15th of July Parallels brought another "security" patch.
I manage a Plesk 9.5.4 server which was infected with the /km0ae9gr6m/ malware. FYI - on my server, the malicious code was added to Javascript, PHP, and HTML/HTM files. I'm posting to let the community know that I was using Plesk's IP address restriction feature at the time of the infection. To be clear - within the Plesk control panel, I had denied Plesk login access to all but two IP addresses (my own studio, and the office IP address of one of my clients). Despite this restriction, log files show logins for the admin user from IP addresses that should not have been allowed by the Plesk firewall. I have since implemented identical address restrictions on port 8443 with IP tables, and to date (approximately 48 hours) have had no further issues. Based on my experience, I say do not trust your security to Plesk's IP address restrictions. If anyone is interested, I would be happy to share my log files.
If you need to get a list of affected files, and have SSH access, you can use the following: grep -rl km0ae9gr6m /var/www/vhosts/
This will pull a list of all files in your vhosts directory containing the malware signature. I found it easiest to edit the affected files with Plesk file manager. In my case, all malicious code was appended to the bottom of the infected files.
Hopefully more info will come to light on how this attack was able to circumvent both the Plesk login and IP address restrictions.
