Re: Plesk Apache Zeroday Remote Exploit

[Kingcope <isowarez.isowarez.isowarez () googlemail com>]

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 () googlemail com>:

> 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 () gmail com>:
>
> > 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/