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

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

Ena sokaki me kratai salionikotiko.. Ela ena bradi tin iposxesi na paris .. 
prin na tin sbisi me sboungari o barbaris .. Lipi to blema sou ap tis avgis ta 
xromata!!! Lipi to oniro .. Esi ! Kai to DOKSARI!!

Am 06.06.2013 um 04:28 schrieb Kingcope 
<isowarez.isowarez.isowarez@xxxxxxxxxxxxxx>:

> Dave ,
> Again bla bla,
> Dont Lie!!! I tested and it Works proper !! Tested on Centos Red Hat Debian 
> FreeBSD !! Pure Remote in the Wild !! Better Patch Ur Servers and Check Ur 
> perimeter than Telling lies.
> 
> Me mixanaki Kai Computer Kai flogera!
> 
> Cheerio,
> 
> Kctherookie
> 
> 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/