Shellshock: Another Day, Another Vulnerability Bashing Our Networks

Opening email, reading your favorite blog or turning on the news each day seems to bring a new round of disclosures and warnings about security threats and vulnerabilities. And the past 36 hours have revealed yet another potential security concern after the new Shellshock vulnerability was announced.

At first glance, the recent announcement of a new vulnerability (classified on the National Vulnerability Database as CVE 2014-6271) in the Bash shell might not seem like a big deal. The vulnerability, nicknamed “Shellshock,” is remotely exploitable under the right conditions and affects the Bash shell versions 1.14 through 4.3, which means that it has been around for more than 20 years. When we consider how prevalent UNIX and Linux systems are, how common the Bash shell is, the age of the vulnerability and the relative ease of exploitation, it becomes clear why security professionals are taking notice. And while it’s still being determined if Shellshock is as damaging as Heartbleed, it’s certainly as serious.

The crux of the vulnerability is centered on how the Bash shell processes environment variables. The vulnerability allows for remote execution of arbitrary code placed into an environment variable. When a function is assigned to a variable, the Bash shell executes any commands following the function definition.

Several websites have published a simple mechanism that can be used to help determine whether a system is vulnerable. From a command line, enter the following:

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

If the system is vulnerable, the output should be:

vulnerable

this is a test

What is happening is that the “env” command (used to set and display environment variables) defines “x” as a shell function (the commands between the tick [‘] marks). Notice that the syntax dictates that the definition of function starts with the opening Poisson bracket ‘{‘ and ends at the closing right Poisson bracket ‘}.’ When the command “bash” is executed, a new bash shell is created that processes all the shell variables and function definitions defined in the parent shell, including the definition of function ‘x.’ This is done so that the new shell can inherit the definition of all the environment variables and functions. The problem is that it sees the definition of ‘x’ ending at “}” and then goes ahead to process the rest of the string “echo vulnerable” as a shell command and executes it. This behavior is what is at the heart of the vulnerability.

If the system is not vulnerable, the result will be an error message followed by “this is a test.” That is because on a system that is not vulnerable, the string appended after the definition of the function “x” (i.e., after the closing Poisson bracket “}”) generates an error message.

For most organizations, fixing this requires a vendor patch. In extreme circumstances, it is technically possible to download the fixed Bash source code and compile your own binary, though that route is not recommended for most and should only be considered as a last resort after careful planning.

The best course of action for organizations at this point is to do the following:

• Work with your vendors and identify all systems that will need patching, such as UNIX, Linux, OSX and potentially even Windows, if you are using Cygwin. Also, check your embedded devices and network devices.
• Best practice indicates starting with Internet-facing systems to harden your exterior.
• Pay close attention to logs and network traffic in the upcoming weeks and months to quickly identify compromised systems.

Protection Against Shellshock Exploits

While vendor patches are a first line of defense, IBM can help protect customers from the exploit of this vulnerability with the IBM Security Network Intrusion Prevention product offerings. In fact, IBM has been helping to protect customers from this and similar attacks since 2007, thanks to Protocol Analysis.

IBM is able to identify and help protect from Shellshock using a signature named Shell_Command_Injection, which was released in 2007. So, the IBM Security IPS offerings have been able to identify and protect from this vulnerability for the past seven years. This signature identifies shell commands (operating system commands) traversing the network inside protocols where they do not normally belong — for instance, inside of the HTTP header field of traffic destined to a Web server.

How Bash Shellshock Exploits Could’ve Been Avoided Years Ago and What You Can Do to Avoid it Today!

IBM’s approach to protecting clients is fundamentally different. Instead of trying to detect the latest exploit attempt, requiring constant additions and/or modification of signatures, IBM focuses on identifying and then shielding the vulnerability from an attempted exploit. In the case of Shellshock, IBM has been able to identify and protect against exploits of this nature since June 2007.