Plesk Vulnerability – In the Wild for Months Before Disclosure

A few days ago we published a post about the Plesk 0-day vulnerability that we started to see being probed in the wild. It uses an incorrect configuration in Plesk 9.0-9.2 that allows anyone to access the PHP binary from inside phppath (phppath/php) and execute remote commands on the server.

However, it looks like this vulnerability has been known for a while in the underground and being used by attackers to compromise Plesk-based servers.

Timeline of a 0-day

This is the original timeline we have since the release of the vulnerability:

  1. 2013/Jun/05 – Kingcope disclosed the vulnerability on full disclosure.
  2. 2013/Jun/06 – Parallels (the company behind Plesk) issued a patch.
  3. 2013/Jun/10 – We released a post with initial data that we started to see with the big influx of attackers scanning for this vulnerability on the wild. The first hit we saw was on June 8th and it grew on June 9th, and is still going.

That’s a very normal timeline for 0-days. Parallels responded very fast (within 1 day) and issued a patch. After a few days, the attackers modified their bots to start looking for this vulnerability and compromising servers.

Real probes for this vulnerability started earlier

However, that timeline is not fully accurate. As we went back to our logs and previous data, we noticed a few hits for “/phppath/php” in May of 2013. As we searched further back, we found scans as far back as April:

/var/ossec/logs/alerts/2013/May/ossec-alerts-18.log.gz:82.195.x.x – - [18/May/2013:22:11:38 -0400] “GET /phppath/php HTTP/1.0″ 404 209 “-” “-”
/var/ossec/logs/alerts/2013/Apr/ossec-alerts-21.log.gz:91.224.x.x – - [21/Apr/2013:01:58:33 -0400] “POST /phppath/php?-d+allow_url_include..

All the scans were looking for that specific file (/phppath/php) that would allow them to exploit this vulnerability. Here is an error we found in an Apache error_log:

[Mon Feb 18 23:53:41 2013] [error] [client 85.114.x.x] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /phppath/php
[Sun Feb 17 04:17:50 2013] [error] [client 69.84.x.x] File does not exist: /home/clientsite/public_html/phppath/php

So we can see it being probed since February, months before it was released. We are still investigating, but if you have a server, try to search for “/phppath/php” in the logs. We are looking for more data to see when it really became known and started to be probed.

Plesk 0-day Remote Vulnerability in the Wild

Just last week another 0-day vulnerability on Plesk was released. It affects Plesk 9.2, 9.3 and 9.5.4 versions. If you have not yet, we recommend that you update Plesk immediately.

Note: In our latest analysis of servers with the Apache binaries or modules compromised (DarkLeech or Cdorked.A), Plesk is often one of the entry points.

Technical Analysis

The exploit was released last week by Kingcope with a sample exploit to “test” if a server is vulnerable. The vulnerability comes from this Plesk configuration:

scriptAlias /phppath/ “/usr/bin/”

This allows any one to execute the PHP interpreter. Upon calling the PHP binary, they can pass commands very similarly to the CVE-2012-1823 (PHP CGI bug):


Read More

Fan of Twilight? Be Very Careful If You’re Looking Online For It

If you like the Twilight series, be careful if you plan to do any “research” on it, or if you plan to visit the site of the series author (Stephenie Meyer). Her site is currently hacked, blacklisted, and redirecting users to the Blackhole Exploit Kit.

You can see the results on the sitecheck:

Read More

Plesk Vulnerability Leading to Malware

Our friends over at Unmask Parasites posted two very good reports about a mix of Plesk vulnerabilities being used to mass-compromise websites, and redirecting them to the Blackhole Exploit Kit.

The first issue is that old versions of Plesk store passwords in clear text (yes, clear text in 2012). The second is a remote SQL vulnerability that has been found in old versions of Plesk allowing attackers to exploit those passwords.

clear text password + database dump = Mass password leaks

This has possibly allowed attackers to gain access to a large number of passwords and hosts/sites. We recommend reading those two posts to understand the issue:

Read More