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