PHP-CGI Vulnerability Exploited in the Wild(blog.sucuri.net)
blog.sucuri.net
PHP-CGI Vulnerability Exploited in the Wild
http://blog.sucuri.net/2012/05/php-cgi-vulnerability-exploited-in-the-wild.html
25 comments
fastcgi setups are explicitly not vulnerable to this attack (http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/)
Edit: Are you proxying to an Apache server that runs PHP-CGI?
Edit: Are you proxying to an Apache server that runs PHP-CGI?
My nginx + fcgi-php servers are not showing the vulnerability.
"FB playing with the vulnerability" - https://facebook.com/?-s
They really do have a sense of humour...
They really do have a sense of humour...
Reminds me of reddit's http headers, which are something like this:
Server: '; DROP TABLE servertypes; --Not just reddit :)
http://www.shodanhq.com/search?q=DROP+TABLE+servertypes
And other companies offer job offers in their headers as well:
http://www.shodanhq.com/search?q=X-Hacker+jobs
http://www.shodanhq.com/search?q=DROP+TABLE+servertypes
And other companies offer job offers in their headers as well:
http://www.shodanhq.com/search?q=X-Hacker+jobs
Did anyone find any interesting sites with this vulnerability? I found a Chinese exchange program and an 'ask Army' *.mil site that has since been patched.
I found that army site too, though I didn't find anything interesting there. I found a Sony site. Some .edu's. Most everything I found seemed to have the exact same source code.
That's strange. I forgot about the Sony site. The best one was the Exchange program. Was cool to see a connectdb.php file with 3 credentials to 3 different servers...
http://ssa-custhelp.ssa.gov/cgi-bin/ssa.cfg/php/enduser/std_...
https://help.us.army.mil/cgi-bin/akohd.cfg/php/enduser/std_a...
https://help.auctions.overstock.com/app/answers/detail/a_id/...
http://askus.columbia.edu/app/answers/list/p/0/kw/student%20...
http://help.station.sony.com/app/answers/detail/a_id/10404?-...
http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp...
http://help.linkedin.com/cgi-bin/linkedin.cfg/php/enduser/st...
http://askdrs.ct.gov/Scripts/drsrightnow.cfg/php.exe/enduser...
http://askfsis.custhelp.com/app/answers/detail/a_id/1249?-s
http://linksys.custhelp.com/cgi-bin/linksys.cfg/php/enduser/...
http://ubisoft.custhelp.com/cgi-bin/ubisoft.cfg/php/enduser/...
https://ebay.custhelp.com/cgi-bin/ebay.cfg/php/enduser/std_a...
https://help.us.army.mil/cgi-bin/akohd.cfg/php/enduser/std_a...
https://help.auctions.overstock.com/app/answers/detail/a_id/...
http://askus.columbia.edu/app/answers/list/p/0/kw/student%20...
http://help.station.sony.com/app/answers/detail/a_id/10404?-...
http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp...
http://help.linkedin.com/cgi-bin/linkedin.cfg/php/enduser/st...
http://askdrs.ct.gov/Scripts/drsrightnow.cfg/php.exe/enduser...
http://askfsis.custhelp.com/app/answers/detail/a_id/1249?-s
http://linksys.custhelp.com/cgi-bin/linksys.cfg/php/enduser/...
http://ubisoft.custhelp.com/cgi-bin/ubisoft.cfg/php/enduser/...
https://ebay.custhelp.com/cgi-bin/ebay.cfg/php/enduser/std_a...
"In the wild" in this case was just their honeypots. Actually vulnerable site should be very rare.
Also, one would assume that any website still using php-cgi has plenty of other security vulnerabilities.
Also, one would assume that any website still using php-cgi has plenty of other security vulnerabilities.
You would be surprised:
http://www.shodanhq.com/search?q=PHP-CGI
http://www.shodanhq.com/search?q=PHP-CGI
Just about all the results there appear to be abandoned cPanel placeholders and similar — very few even have domains. I couldn't look at all of them, obviously, but this seems to bear out the idea that nothing anyone cares about is run on PHP-CGI.
The headers suggest ancient, unmaintained systems running outdated, no longer supported software with multiple known vulnerabilities.
I would be surprised if these systems haven't already been p0wned a long time ago.
I would be surprised if these systems haven't already been p0wned a long time ago.
My thought exactly. Anyone who keeps their stack up to date is using the Apache2 Handler or FastCGI. Even if they're still on Apache1, mod_php isn't vulnerable.
If you're serving sites for multiple different users (eg shared hosting) you can't safely use mod_php as all of the php would end up running under the same uid.
I bet there are still tens of thousands of otherwise secure php-cgi setups out there.
I bet there are still tens of thousands of otherwise secure php-cgi setups out there.
I don't think a lot of well-maintained websites still use the CGI option. Even without this vulnerability, it's a bad idea to run that configuration (as every single request starts a complete PHP process, compiles all the script files, runs them and then shuts down again). It's just incredibly wasteful, comparative to starting and terminating e.g. a complete servlet container with every request. PHP-FPM is now being bundled inside the standard PHP distro, there is really no valid reason to use plain old CGI.
Shared hosting.
If you use mod_php, every customer's code runs as the apache user, which is bad for security. If you use PHP-FPM, you end up needing at least one long-running process per user, which wastes resources.
If you use mod_php, every customer's code runs as the apache user, which is bad for security. If you use PHP-FPM, you end up needing at least one long-running process per user, which wastes resources.
You're right, I hadn't thought of that. The only shared hosting environment I use at the moment is mediaTemple's Grid Service, and it looks to me like they are configured for FastCGI regardless.
I feel this needs to be stressed again: FastCGI implementations are NOT vulnerable to this bug.
I myself run LigHTTPD and PHP through FastCGI, and this was worrying me a lot, until someone pointed me to the Eindbazen site which stated this.
(BTW: Eindbazen is Dutch for "Final boss" in a video game context.)
I myself run LigHTTPD and PHP through FastCGI, and this was worrying me a lot, until someone pointed me to the Eindbazen site which stated this.
(BTW: Eindbazen is Dutch for "Final boss" in a video game context.)
Isn't FastCGI not really CGI?
For a while all sites that deployed "Answer Center" by RightNow (recently acquired by Oracle) were vulnerable, but it seems they've patched it.
Go make sure your hosts have this patched up.
However, I then also tried to run remote code execution and couldn't. The only differences to my stack is that it's running Nginx and hops accross a few proxies (nginx -> varnish -> nginx (for SSL and SSI)) in between. I'm not sure why I can't run -d or -n, but any other options seems to always return the source.
Anyone else running nginx in fastcgi noticing similar? It seems like it's vulernable to the source download, however not remote execution. I'm about to work on a rewrite rule now just in case.
(Not sure why it's vulnerable to the source download, as comment below says, it's set up to not be vulnerable?)
Edit: Not sure what part of my comment deserved the down vote. I trust that what you say is true, in that fastcgi is explicitly set up to negate this vulnerability, but the truth remains that I am experiencing it. If anything I'd have wanted to reach out to other nginx users...
The only way I could ever show that fastcgi under nginx is vulnerable, would be by linking to my live vulnerable server running nginx.. and the wiseman inside of me knows that to be a bad idea! Ha.