Question about critical security update MU21

[HostaHost]

Regarding http://kb.parallels.com/115014

[-] Critical security enhancement. Removal of malware which is possible to exploit without authenticating. Infected nodes might be known to and exploited by hackers. (120985)


I'm curious how malware got into a file provided with the software? Was there a security compromise at Parallels? If so, is there any possibility data was also obtained, such as information that has been provided in the support system, the support team's ssh keys, etc.?

 

[HostaHost]

And now more malware in your software?

Parallels Plesk Panel 10.4.4 MU #47 [01-Nov-2012]

[-] Critical security enhancement. Removal of malware which is possible to exploit without authenticating. Infected nodes might be known to and exploited by hackers.


Are we going to get an answer on what exactly is going on over there that's allowing your software to go out with malware in it?

 

[breun]

I don't think we're meant to interpret this as Parallels having shipped software with malware in it, but that the update removes a known piece of malware that apparently has gotten installed on some servers which allows access without authentication.

 

[sergius]

I don't think we're meant to interpret this as Parallels having shipped software with malware in it, but that the update removes a known piece of malware that apparently has gotten installed on some servers which allows access without authentication.

Exactly. Thank you, Nils.

 

[HostaHost]

I don't think we're meant to interpret this as Parallels having shipped software with malware in it, but that the update removes a known piece of malware that apparently has gotten installed on some servers which allows access without authentication.

If that were true the updates should not need to replace files that came with the software (autoreport.php). The update replaces one file, autoreport.php, and exits immediately upon completion. The same file was also replaced in the October 25 update. If it is performing some additional task, the log does not indicate that. If it's purpose is to clean known-malware off a server, customers should be told what to look for so we can perform this task ourselves as well to verify it is not present. We have hundreds of servers running a wide variety of Plesk versions; I shouldn't have to run a script manually every time Parallels finds a new vulnerability in their software, I should be told what I need to know to ensure all of my servers aren't vulnerable using automated scripts.

 

[Amin Taheri]

Plesk php files are typically encoded, you cant edit or change them; so if there is a change that is done on the files they will need to be updated. Its also likely that the update does other items that it does not log, this way it doesnt expose to others what was fixed so that they can then use that to create exploits for unpatched servers (despite an exploit being out there already).

Just conjecture though. As long as you stay up to date on your OS/Yum channel updates, plesk updates and secure your server and customer sites (like mod_sec, etc) you are probably not going to be vulnerable to these types of script kiddies. The sad part is that most people do not do this and then wonder why they get hacked, and then blame the vendor (in this case plesk) when they get hacked.

 

[HostaHost]

Plesk php files are typically encoded, you cant edit or change them; so if there is a change that is done on the files they will need to be updated. Its also likely that the update does other items that it does not log, this way it doesnt expose to others what was fixed so that they can then use that to create exploits for unpatched servers (despite an exploit being out there already).

Easily worked around by operating off of a data/signature file like the way virus scanners work; they don't have to reinstall the executable every time. It could even remote retrieve it so it's not sitting on the server. Not releasing exploit details ensures only the criminals who already know the exploit can continue to use them while the users of their software can't determine if they're vulnerable, still vulnerable or were never vulnerable.

Just conjecture though. As long as you stay up to date on your OS/Yum channel updates, plesk updates and secure your server and customer sites (like mod_sec, etc) you are probably not going to be vulnerable to these types of script kiddies. The sad part is that most people do not do this and then wonder why they get hacked, and then blame the vendor (in this case plesk) when they get hacked.

The problem with this solution is we have hundreds of Plesk 8 and 9 servers and I can't get any answer out of them as to whether replacing the autoreport.php file is sufficient or if autoinstaller has to be run so that other tasks can be executed. If they'd release the details of what it does, I can automate my own system checks, or if something else that triggers autoreport.php daily would cause it to run the checks on its own, I can simply push the new file to every relevant server, but since they'll tell us nothing about either what it does or whether I can push it out, I'm stuck having to pay staff to go run the installer on every relevant server. At least the criminals know what the vulnerability is, I'm only a customer.

 

[Amin Taheri]

You can easily automate running the installer using something like mussh or tentakel or some other parallel/serial ssh terminal program where you can run one command against hundreds of servers all at once.

Since all of the servers would take the same command to install the MUs:

/usr/local/psa/admin/sbin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base

You dont have to pay anyone, just run it and your done. You may even want to schedule this to run on a weekly or monthly basis via cron or something if running it manually will be too intensive.

 

[HostaHost]

You can easily automate running the installer using something like mussh or tentakel or some other parallel/serial ssh terminal program where you can run one command against hundreds of servers all at once.

Since all of the servers would take the same command to install the MUs:


You dont have to pay anyone, just run it and your done. You may even want to schedule this to run on a weekly or monthly basis via cron or something if running it manually will be too intensive.

We have scripts to automate deployment of files and running of commands. I could never do that with their updates though given the quality of their releases. Their updates regularly break their billing system software that we use, often times quite seriously, and even just the recent microupdate for PCI improperly changed the permissions on qmail-smtpd to non-executable, so when we pushed that update it broke at least 25% of our servers' email functionality. It took them several days to fix the microupdate to not do that. We always test their updates on a variety of configurations we have for verification, find what it's going to break, then we can run the updates along with a script to check and fix all previously known things the updates break.