Hacker publishes alleged zero-day remote code execution exploit for older Plesk versions

The exploit targets a vulnerability that only affects unsupported Plesk versions, the software's creator said

A hacker released what he claims is a zero-day exploit for older versions of the Parallels Plesk Panel, a popular Web hosting administration software package, that could allow attackers to inject arbitrary PHP code and execute rogue commands on Web servers.

The hacker uses the alias "Kingcope" and has published exploits for unpatched vulnerabilities before. He released the new Plesk exploit code Wednesday on the Full Disclosure mailing list.

[ The Web browser is your portal to the world -- and the gateway for security threats. InfoWorld's expert contributors show you how to secure your Web browsers. Download the free PDF today! | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

The hacker claims the exploit was successfully tested against Plesk 9.5.4, Plesk 9.3, Plesk 9.2, Plesk 9.0, and Plesk 8.6 used in combination with the Apache Web server software on 32-bit and 64-bit Linux distributions including Red Hat, CentOS, and Fedora. However, Parallels, the Seattle-based company that develops Plesk Panel, claims that Plesk 9.5 and later versions are not affected by the exploit.

"This vulnerability is a variation of the long known CVE-2012-1823 vulnerability related to the CGI mode of PHP only in older Plesk [versions]," a Parallels representative said Thursday via email. "All currently supported versions of Parallels Plesk Panel 9.5, 10.x and 11.x, as well Parallels Plesk Automation, are not vulnerable."

According to a page on the company's website, version 8 of the product has not been supported since September 2012 and Plesk version 9 will reach end of life Sunday.

Even if the latest versions of the software are not affected, widespread exploitation of this vulnerability is still likely to happen because servers running the old and affected versions of Plesk are unlikely to be regularly maintained, said Craig Williams, a threat researcher at Cisco, Wednesday in a blog post.

Williams analyzed the attack code released by Kingcope and said that "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."

A command executed by the exploit contains several arguments that are intended to disable security mechanisms that might exist on the server, he said. These include the "allow_url_include=on" argument which allows the attacker to include arbitrary PHP code and the "safe_mode=off" argument. "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."

If a customer is using a legacy and no longer supported version of Parallels Plesk Panel, they should upgrade to the latest version, the Parallels representative said. The company already provided a workaround for the CVE-2012-1823 vulnerability for legacy versions of Plesk, the representative said.

"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 [access control lists] or HTTP authentication," Williams said.

"Successful exploitation requires a ScriptAlias [configuration] for the php path using Apache's mod_alias," vulnerability management firm Secunia said Thursday in an advisory that rates the vulnerability as highly critical. That specific configuration is scriptAlias /phppath/ "/usr/bin/", according to Kingcope's exploit notes.

However, it's not clear how commonly this configuration is found in real world Plesk deployments. Two users who posted responses to Kingcope's email to the Full Disclosure mailing list said that they couldn't get the exploit to work because they couldn't find the phppath-related setting on Plesk installations they tried it on.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies