Plesk 0-day: Real or not?
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, 222.187.222.122 ) 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/"
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
hardbox
Jun 7th 2013
1 decade ago
scriptAlias /phppath/ "/var/www/cgi-bin/cgi_wrapper/"
Steven Chamberlain
Jun 7th 2013
1 decade ago
82.195.239.50 - - [07/Jun/2013:20:34:26 +0100] "GET /phppath/php HTTP/1.0" 404
Steven Chamberlain
Jun 7th 2013
1 decade ago
178.79.161.86 - - [07/Jun/2013:07:27:19 +0100] "GET /phppath/php HTTP/1.0" 404 209
178.79.161.86 - - [07/Jun/2013:07:27:19 +0100] "GET /phppath/php HTTP/1.0" 404 209
78.46.64.21 - - [07/Jun/2013:10:15:21 +0000] "GET /phppath/php HTTP/1.0" 404
Steven Chamberlain
Jun 7th 2013
1 decade ago
My Apache server got the following POST this morning:
70.86.135.250 - - [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 ThePlanet.com, in Dallas.)
whurlitzer
Jun 8th 2013
1 decade ago
/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?)
jullrich@sans.edu
Jun 9th 2013
1 decade ago
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.)
whurlitzer
Jun 11th 2013
1 decade ago