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 <[email protected]>: > 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/
