Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - More heavily URL encoded PHP Exploits against Plesk "phppath" vulnerability InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

More heavily URL encoded PHP Exploits against Plesk "phppath" vulnerability

Published: 2013-07-30
Last Updated: 2013-07-31 00:44:16 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

Thanks to a reader for sending in this log entry from his Apache Server:

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
%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1

Russ quickly decoded it to:

/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 -nT

This appears to be an exploit attempt against Plesk, a popular hosting management platform. A patch for this vulnerability was released in June [1]. We covered the vulnerability before, but continue to see exploit attempts like above. The exploit takes advantage of a configuration error, creating the  script alias "phppath" that can be used to execute shell commands via php. The exploit above runs a little shell one-liner that accomplishes the following:

  • allow URL includes to include remote files
  • turn off safe mode to disable various protections
  • turn of the suhosin patch (turn it into "simulation mode" so it doesn't block anything
  • set the "disabled function" to an empty string to overwrite any such setting in your php configuration file
  • and autoprepending "php://input", which will execute any php scripts submitted as part of the body of this request

Please let us know if you are able to capture the body of the request!

Thanks to another reader for submitting a packet capture of a full request:

The Headers:

Host: <IP Address>
Content-Type: application/x-ww-forum-urlencoded
Content-Lenght: 64

<?php echo "Content-Type: text/html\r\n\r\n"; echo "___2pac\n"; ?>

This payload will just print the string ___2pac, likely to detect if the vulnerability exists. No user agent is sent, which should make it easy to block these requests using standard mod_security rules.



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

8 comment(s)
Diary Archives