Date: Wed, 5 Jun 2013 18:37:10 -0400
From: David H <ispcolohost@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Plesk Apache Zeroday Remote Exploit

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

Content of type "text/html" skipped

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

Powered by blists - more mailing lists