PHP-CGI Exploitation by Example

Late last week, a vulnerability in PHP-CGI was disclosed, which allows all sorts of bad for folks running PHP-CGI.  It was met with lots of controversy and questions about how it was leaked before a patch was available.  What we'll talk about today is how the bad guys (aka: “the baddies”) could be exploiting your PHP-CGI implementation right now (it's worth noting the distinction here: PHP-CGI is a much less common way of running PHP web applications, so many PHP installations are not affected).

Below I have provided a set of Apache configuration directives that would put a server in a vulnerable state.  If you would like to implement a server yourself to follow along, this article was a helpful resource in setting up a vulnerable PHP-CGI instance.

For demonstration purposes, WordPress will be used as a test site for the examples that will follow.  However, it is important to note that the issue is not with WordPress or any particular PHP application, but an issue with the underlying PHP-CGI installation it stands on.

Here is what our test WordPress installation looks like before we start meddling with it…

Example #1 PHP-CGI Source Disclosure

A simple abuse case for this vulnerability is obtaining the source code for any PHP file on the site, which can be done with a simple "-s" query parameter:

 Example #2 PHP-CGI Remote Code Execution

A more complex but much more damaging abuse case is using the vulnerability to execute arbitrary code on the server. This can be done using a "-d" query parameter, and passing the code to be executed. Ouch.

In fact, Trustwave's MSS services are seeing a rising number of exploitation attempts similar to this example since it's release last week.

Example #3 PHP-CGI PHP Reverse Shell Shoveling

Taking that idea further, we can even use remote code execution to get a fully functional reverse shell using a slightly modified version of @pentestmonkey's php-reverse-shell.

If you'd like to see more information on the PHP-CGI vulnerability, please check out the recent blog post by Trustwave's Ryan Barnett on the active exploitation happening in the wild identified by our honey pots and additional protections to help mitigate this issue.

Comments

[Dream Cyber Infoway]

The biggest problem of these rants is that they come from people stuck in the old days of PHP. They either don't care or they don't want to admit that PHP actually evolves at a very fast pace, both at the language level but also at the community level. In fact, it evolves much faster than any other language or web platform. It has not always been the case, but the last 5 years have been an amazing journey for PHP.

[BetaPaiTManiZ]

nice info..

[S M]

hehe
All is good now.. odd but all good.

[S M]

Sure like to reproduce this, but I must be missing something. Got PHP going as a CGI and I still reproduce this.
Would like to know what I'm missing...
Nice post tho :)

[Matt Jones]

"Additionally, major sites like Facebook.com, Sony.com and many others were vulnerable up until early Friday morning."

I work on security at Facebook, and AFAIK we were never vulnerable at all. We're a bit past PHP-CGI at our current scale. If you're thinking of https://facebook.com/?-s, I'd suggest you look a little closer :-).