Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Plesk Apache Zeroday Remote Exploit
From: Kingcope <isowarez.isowarez.isowarez () googlemail com>
Date: Thu, 6 Jun 2013 04:21:40 +0200

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 () 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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault