PHP Injection Attempt Explained

Today I'll make an attempt to explain what I know about a PHP injection attempt.

The first thing you may see is something in your IIS or Web logs that is HTML encoded in a url

hxxp://www.mysite.com//%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E

If you dump that into an html decoder ( http://meyerweb.com/eric/tools/dencoder/ ) you'll see what it really is

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n

So you now see that the real url is was trying to get at is

hxxp://www.mysite.com//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n

Which after a google search appears to be related to CVE-2012-1823 ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1823 ), which says that when PHP is configured as a CGI script, then it cannot handle query strings that lack an = (equals sign) ... which sounds insanely simple ... but that apparently allows remote attackers to execute arbitrary code by placing command-line options in the query string ... many of which are typically related to skipping certain php_getopt for the 'd' case.

What you'll also see inside the body of post data is some php code such as this code I posted which does multiple things ...

1.) move to the tmp folder
2.) makes a request to a php file which perhaps logs the ip address of the victim and sets it up for the botnet?
3.) downloads a txt file (which is actually perl code) which is the payload of the attack
4.) runs the perl file just downloaded
5.) deletes the perl file just executed
6.) deletes all temporary files the perl file just created
7.) deletes everything else in the tmp folder


Inside the perl file/code downloaded you might see something like this code I posted.

It appears to contain many interesting things such as ...

1.) lots of variables declared (that start with the 'my' keyword) including an ip for the command and control server
2.) lots of functions declared (that start with the 'sub' keyword) that aren't actually getting executed now, but maybe later!
3.) code inbetween there that executes immediately and indefinitely is inside the while(1) infinite loop such as connecting to the IRC servers and listening for incoming messages. It is likely that it will use some of those functions declared with the 'sub' keyword based on which incoming messages it receives.
4.) some of those functions to be used later include things like [Port Scan an IP, NMap Scan an IP, UDP DDoS and IP, Download a file from somewhere, Open a Shell, etc.


What to do if you see this?

Check your firewall, IDS/IPS, or whatever other logs and look for outbound connections to [Any urls/IPs in the PHP wget statements, Any IPs in the Perl code]. If no, then hopefully the attacks failed. If yes, think worst case and consider resetting passwords and rebuilding the server from scratch because with that kind of access to your server you don't know what else they might've done and what other backdoors they may have created. If they really got in, also look at logs for any attempts to move further into your network and hop from this server to another one. Also don't forget to check your servers to make sure the vulnerability attempted is fixed on all servers (not just the one attacked), because you may patch this one and they just perform the same thing on the next server.

Hope this helps a bit! Good luck!

Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.