Plesk 0-day: Real or not?

Published: 2013-06-07
Last Updated: 2013-06-07 01:42:47 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

Yesterday, a poster to the full disclosure mailing list described a possible new 0-day vulnerability against Plesk. Contributing to the vulnerability is a very odd configuration choice to expose "/usr/bin" via a ScriptAlias, making executables inside the directory reachable via URLs.

The big question that hasn't been answered so far is how common this configuration choice is. Appaerently, some versions of Plesk on CentOS 5 are configured this way, but not necessarily exploitable. The exploit is pretty easy to spot. It sends a heavily URL encoded POST request with a "Googlebot" user agent. Google typically doesn't send POST requests, so they are pretty easy to spot. I found a couple POSTS from "Google" (actually a "random" Chinese IP address, ) in our web logs here.

Masquearding as Google is a common trick among exploit scripts. 

Please verify that your Apache configuration does NOT include this line:


ScriptAlias /phppath/ "/usr/bin/"


Let us know if you spot it in the wild.

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

7 comment(s)


Botnet using Plesk vulnerability and takedown
On a Plesk 10.3-based CentOS 5 system, I instead see the following in /etc/httpd/conf.d/php_cgi.conf so I guess the vulnerable configuration might be an earlier version of Plesk:

scriptAlias /phppath/ "/var/www/cgi-bin/cgi_wrapper/"
This looks like an (unsuccessful) probe, it is not legitimate traffic: - - [07/Jun/2013:20:34:26 +0100] "GET /phppath/php HTTP/1.0" 404
Also seen hitting two other hosts. In each case these probes went to the 'default' HTTP virtual host: - - [07/Jun/2013:07:27:19 +0100] "GET /phppath/php HTTP/1.0" 404 209 - - [07/Jun/2013:07:27:19 +0100] "GET /phppath/php HTTP/1.0" 404 209 - - [07/Jun/2013:10:15:21 +0000] "GET /phppath/php HTTP/1.0" 404
Long-time reader, first-time submitter...

My Apache server got the following POST this morning: - - [08/Jun/2013:05:02:19 -0700] "POST /%70%68%70%70%61%74%68/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 296

The decoded URL begins with "/phppath/php", so I thought it might be an instance of this Plesk exploit. (The rest of the decoded URL is just gibberish to me; feel free to remove it if it's somehow dangerous, an unpublished PoC or whatnot.) Is it? I don't capture UserAgent so I don't know whether the client was claiming to be GoogleBot; I also don't run any scripting in Apache so the attack was moot in any case.

(The source IP seems to belong to, in Dallas.)
Indeed, this is the phpbb exploit. The full decode:

/phppath/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -n

so in short, he is trying to turn off various security settings in php, then just use stdin as a default prepend file. (that part if probably in the POST?)

Johannes, thanks for confirming that.

I don't save the requests, so I can't confirm that there was any further payload there. (I don't even run PHP, or any other Apache modules, so I'm generally pretty amused when I see messages like this in the access log.)

Diary Archives