Re: [Full-disclosure] Plesk Apache Zeroday Remote Exploit

[Kingcope <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx>]

Hey Dave !
World was pwned already :>
Check your perimeter!
King "the engineer" Cope's Legacy 

Am 06.06.2013 um 00:37 schrieb David H <ispcolohost@xxxxxxxxx>:

> Sorry for improper reply; was not a member of the list until today so I 
> didn't have the original email to reply to.
> 
> As best I can tell, this exploit only works on very specific configurations 
> that may or may not actually be related to Plesk; I'm not able to tell 
> because I have not found a version of Plesk that the vulnerability worked on 
> to be able to determine why.  I was only able to reproduce this issue on one 
> server and it turns out there was a very weird reason why it worked.
> 
> The server in question was Plesk 8.6 on CentOS 5.  On that particular server, 
> the exploit only worked on IP addresses that were set to 'shared' in Plesk, 
> it did not work on any IP set to exclusive that had a default website 
> configured to be served.
> 
> Additionally, there was no reference to phppath in any of the apache config 
> files on the system in /etc/httpd/conf/, /etc/httpd/conf.d/, or 
> /var/www/vhosts/*/conf/ where all the included domain config files are so I 
> was really struggling to figure out why that was working.
> 
> Turns out on this specific server the server owner had an issue where some of 
> his hosted domain owners liked to type in https:// in front of their domain 
> even if they did not use SSL and were on the shared IP address.  Normally, by 
> default for Plesk, if a site on a shared IP does not have SSL enabled, you'll 
> get the Plesk banner page instead of the website you typed in, which is 
> served from /var/www/vhosts/default/htdocs/.  This customer had some 
> complaints from those users, so he put a copy of /usr/bin/php-cgi in 
> /var/www/vhosts/default/cgi-bin/, used a .htaccess to enable php for those 
> default requests, then rewrote all requests coming in over https:// to 
> index.php where a redirect was done in php to the non-secure equivalent of 
> the domain requested.  (Just using rewrite rules would have worked too but 
> whatever...)
> 
> It appears this was set up a couple years ago and since this was CentOS 5, 
> the copy of /usr/bin/php-cgi taken at the time was vulnerable to the 
> cve-2012-1823 issue.  Copying /usr/bin/php-cgi over top of 
> /var/www/vhosts/default/cgi-bin/php-cgi resolved the issue.  If this was not 
> related to cve-2012-1823 I would not have expected that solution to work, 
> since the only change was copying the latest CentOS 5 php-cgi over top of a 
> several year old version of the same file.  Additionally, prior to doing 
> that, I modified the exploit script to execute 'ls' and got the contents of 
> the /var/www/vhosts/default/htdocs/ directory.  Based on the description of 
> the exploit and the expectation that it is running by using a direct 
> execution of /usr/bin/php, I would have expected to get the contents of 
> /usr/bin/ instead?
> 
> Now, keep in mind that Plesk 8 did not allow you to select to select to run 
> php as a fastcgi or cgi, only php on or php off.  I'm only familiar with 
> Plesk on CentOS but this means that without a custom config, there is no way 
> to run a website on an install of Plesk 8 on CentOS with php set to run as a 
> cgi, only apache module, and the exploit doesn't seem to work in that case.  
> 
> Plesk 9 did add the option to run php as fastcgi or cgi.  After some 
> searching around online, I did find reference to the 'phppath' alias in some 
> Plesk forum posts but they were for platforms other than CentOS and not Plesk 
> 8, so unless I'm missing it, I don't think the ScriptAlias /phppath/ is used 
> on Plesk 8 or 9 on CentOS with the CentOS-provided php.
> 
> I know my situation was very weird, so I'm just theorizing now, but I'm kind 
> of thinking at this point that perhaps the exploit only works in the 
> following specific situations:
> 
> 1) If the server in question runs an OS where php executes as a cgi by 
> default instead of as an apache module, AND either the OS vendor has not 
> released a patched php-cgi for cve-2012-1823 or the server owner is not up to 
> date on their patches.  My example of just copying the OS php-cgi over top of 
> the one that had been in use on the single instance resolved it, so that's 
> what lead me to that conclusion.  I do not know which Plesk-supported OS's 
> run php as a cgi by default.
> 
> 2) If the server in question runs Plesk 9, AND the server admin or site owner 
> has set php to run as a cgi, AND the php-cgi has not been patched for 
> cve-2012-1823.
> 
> In CentOS/RHEL, if you install httpd and mod_php, the default config is to 
> run it as an apache module and this exploit did not work in those situations; 
> same with Plesk 9.  I also attempted to set php to run as a cgi on a few 
> sites on Plesk 9 on CentOS 5 and the exploit did not work, but all of the 
> CentOS 5 servers I have access to have their php rpm up to date which means 
> it is patched for cve-2012-1823.  CentOS 4 was never php 5 so it was not 
> vulnerable to cve-2012-1823 to begin with and Plesk 8 and Plesk 9 on that 
> platform don't seem to be vulnerable.  
> 
> If someone has an out of date copy of CentOS 5 running Plesk 9, it would be 
> interesting to set a site to run php as a cgi and then hit it with the script 
> to see if the exploit works.  If it does, then it's the cve-2012-1823 issue 
> and just unpatched servers causing the problem, but only when the exploit 
> hits a website that has php set to run as a cgi, or the OS runs it as a cgi 
> by default (don't know which ones do that).
> 
> Dave
> 
> 
> 
> From: king cope <isowarez.isowarez.isowarez () googlemail com>
> Date: Wed, 5 Jun 2013 18:37:38 +0200
> Please keep headers intact.
> 
> Engineered by Kingcope
> 
> Copyright (C)2013 Kingcope
> Attachment: pleskwwwzeroday.rar
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/