Plesk 0-Day Targets Web Servers
We’re seeing reports of exploitation of this vulnerability. We can confirm Global Correlation – Network Participation telemetry is seeing multiple exploitation attempts across many customers. Customers who participate in Global Correlation – Inspection have a higher chance of this signature blocking in the default configuration since the sensor will take the reputation of an attacker into account during the risk rating evaluation. One of the reports mentioned the use of an IRC-based botnet as a payload for a large number of compromised machines. Since this report is similar to one I previously blogged about, I examined the IRC payloads in depth. Many of the variable names and functions are identical, with the new bot’s source code indicating that it is a later revision of the one we saw previously. Additional features have been added in this revision, which can allow the bots to transfer files directly to other bots via the command and control channel. Given the nature of this vulnerability and the ease of exploitation, it is very likely that unpatched machines will continue to be compromised if not remediated.
A 0-day vulnerability has been publicly posted which affects older versions of the Parallels Plesk software. The author of the exploit included an informational text file, which appears to 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 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 or to attack servers that only offer web services via SSL. You’ll notice in the exploit output shared 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 any possible hardening that is in place on the server. The allow_url_include=on argument allows the attacker to include arbitrary PHP scripting; the impact 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 any additional protection on the server (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.