Plesk 8 and 9

Starting yesterday a dedicated server customer of mine began telling me of entire servers with individual web sites that have been reported to Google as hacked. Upon reviewing the HTML code we could sometimes find jquery.js code that was hacked (appended on to good code) while other times we find nothing.

Now a second server has been identified.

What's going on? How are they even getting in? I sit behind a hardware firewall and it is as if they just walk through the front door.

The steps to correct it are to restore the server from backup, which takes ours and the server has to be down. Unless there is a witch for vzrestore I haven't learned tat will restore a live server.

Could these systems have been compromised by that Plesk vulnerability, with the bad guys only now getting round to doing something with the passwords they stole? (or maybe it is only now coming to light?)

Just a possibility/suggestions. If so, use the script that Parallels published to change all the passwords in one go.

I'd check the FTP logs for a site that's been compromised and see if an unknown IP connected at any point. If they did then you know it was done via FTP and nothing worse.

It could also have been done using file manager in Plesk itself, however, and I don't know if there are logs for that.

A clamd/rkhunter scan should find anything nasty on the box/Container itself.

RKhunter was negative. I am looking for the Plesk Vulnerability patch now. I am not sure if my partner did the patch while I was in the hospital with my daughter. But I am not aware of a FTP log per site.

Honestly hardware firewalls & firewalls in general have no impact on your security posture for a hosting environment, so dont put much stock into that. Its just a yes/no condition, those devices make no determination on the content of what is allowed through.

Ok that being said, we see this attack all the time. Its usually via FTP uploads, or the file manager. The FTP logs are kept under:
/var/www/vhosts/DOMAINNAME/statistics/logs/xferlog*

and the plesk file manager logs are:
/usr/local/psa/admin/logs

Responses on your part, send us the malware you're seeing on these systems and try scanning those with clamav to see if we already have a rule for it. You may also be able to redact it using the redactor module in ASL, we'll be able to help you determine the path for that based on the malware when we see it.

Thank you Scott and others. We did run the patch but some users returned their PWD's back to what they previously were.

I had 2 sites effected too so I blocked all traffic going to port 8443 (Plesk), apart from my IP, whilst I turned off all client control panel access and attempt to solve the issue.

After applying the patch I changed control panel passwords for those who actually use the Plesk CP, and for others I left it off including the email control panel access. I then changed the FTP passwords site by site, as not all of my clients actually have websites or even used there hosting. As a rule I don't allow clients to change FTP passwords or have SSH access as, for want of a better phrase, clients tend to be stupid when it comes to passwords and security, or at least mine are.

It doesn't however solve the email account password issues, as these would've been compromised too in the hack, but I've changed my Plesk admin passwords, and of course change all passwords associated with my domains, email accounts, and FTP.

I also monitor my clients sites in Google Web Master Tools, so will be notified when there is an issue.

Don't forget the Plesk interface is also served on port 8880 (HTTP instead of HTTPS) by default.

I didn't know that.

Faris talked about running a clamd/rkhunter scan. How do you do that?

If you have clamd running you can use the clamdscan command. See man clamdscan for the options. There is also clamscan for when you don't/can't run clamd.

The rkhunter scan runs daily via cron by default, or you can trigger it manually by running the rkhunter command. See man rkhunter for more information.

thanks breun. I'm running a scan now using the command:



That should scan everything in the www directory using multi-thread as I have 2 processors.

Thanks in part to breun's tip, and the clamd scan, I found 2 js files also infected on the server. Funny thing is, yet again these js files belonged to the same client that had there other site infected, so I suspected it was all done at the same time. These 2 js files where located on another subdomain, part of an over all service he hosts on my server.

I've already changed his FTP settings, so all I need to do is removed the infected files, replacing them with the non-infected versions on my local storage.

Only other files coming up as infected are usage stats stored in webstat, and those are HTML files which I'll clean anyway, even though they're not a threat.

Oh and I found this online, which is an interesting read:

http://blog.unmaskparasites.com/2012/07/26/runforestrun-now-encrypts-legitimate-js-files/#more-891