Plesk 0-Day Targets Web Servers

A 0-day vulnerability has been publicly posted which affects older versions of Parallels Plesk software. The author of the exploit included an informational text file which appears indicate public servers have already been exploited. This vulnerability does not affect the latest major version of the software, nevertheless we expect to see widespread exploitation, due to the age of the affected versions — sites still running these versions of Plesk, which should enter End of Life of June 9, are unlikely to be regularly maintained.

 The script exploits the vulnerable versions of the Plesk control panel by injecting malicious PHP code, allowing successful attackers to execute arbitrary commands with the privileges of the Apache server userid. I found it interesting that the author went the extra mile to include an SSL-capable variant of this exploit. This is likely intended to bypass possible content inspection security devices as well as attack servers that only offer web services via SSL. You’ll notice in the exploit output above chunked encoding is also being used which further obfuscates the payload just a bit. The exploit is URL encoded by default; below is both the encoded and decoded request.

In the decoded post request, we can see a number of interesting arguments. The exploit is turning off possible hardening that is in place on the server. The “allow_url_include=on” argument allows the attacker to include arbitrary PHP script. The impact of that is described here.  Next safe_mode is turned off. As a final step Suhosin, a PHP hardening patch, is put into simulation mode. This mode is designed for application testing, and effectively turns off the extra protection (as well as protections against processing PHP script via the php:// URI handler).

Above you can see the command injection attempt contained in the post body. In this proof of concept the command being executed by the exploit is a fairly benign system call, but this could easily be modified to do something more nefarious. In fact, in my previous blog we saw attackers making use of a very similar vulnerability to form an IRC-based botnet. As always, affected servers should disable the vulnerable panel or upgrade to the latest version which is not vulnerable. Those unable to disable the vulnerable version of Plesk or upgrade to more recent, unaffected code should consider additional hardening outside of PHP, such as running their Apache instance within a chroot environment or restricting access to the Plesk control panel, e.g. via IP ACLs or HTTP authentication.