PHP-CGI Vulnerability Exploited in the Wild

http://blog.sucuri.net/2012/05/php-cgi-vulnerability-exploited-in-the-wild.html

by sucuri2 • 14 years ago

39 25 14 years ago

blog.sucuri.net

jefe782• 14 years ago

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.

thornofmight2• 14 years ago

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.

jefe782• 14 years ago

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...

bmj12• 14 years ago

"FB playing with the vulnerability" - https://facebook.com/?-s

They really do have a sense of humour...

TazeTSchnitzel2• 14 years ago

Reminds me of reddit's http headers, which are something like this:

    Server: '; DROP TABLE servertypes; --

achillean• 14 years ago

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

rickmb2• 14 years ago

"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.

davedd• 14 years ago

You would be surprised:

http://www.shodanhq.com/search?q=PHP-CGI

chc• 14 years ago

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.

rickmb2• 14 years ago

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.

shebson• 14 years 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.

mike-cardwell• 14 years ago

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.

chrisacky• 14 years ago

I just tested the vulnerability on one of my websites and successfully managed to get the source of my index.php.

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.

nbpoole• 14 years ago

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?

Jare• 14 years ago

My nginx + fcgi-php servers are not showing the vulnerability.

thecroat• 14 years ago

Go make sure your hosts have this patched up.

bmj12• 14 years ago

If you have to contact your host to make sure they are patching vulnerabilities - you are with the wrong host.

daeken• 14 years ago

You don't have to contact them, but you absolutely should make sure that vulnerabilities are being patched. It's your responsibility to your users.

marklindhout• 14 years ago

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.)

TazeTSchnitzel2• 14 years ago

Isn't FastCGI not really CGI?

Udo2• 14 years ago

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.

devicenull• 14 years ago

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.

Udo2• 14 years ago

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.

Gigablah• 14 years ago

For a while all sites that deployed "Answer Center" by RightNow (recently acquired by Oracle) were vulnerable, but it seems they've patched it.

PHP-CGI Vulnerability Exploited in the Wild

Related Stories