Bourne Again: Helping you see the light through the Shellshock exploit

October 1, 2014  |  Garrett Gross

A recently discovered hole in the security of the Bourne-Again Shell (bash) has the majority of Unix/Linux (including OS X) admins sweating bullets. You should be, too--attackers have already developed exploits to unleash on unpatched web servers, network services and daemons that use shell scripts with environment variables (this can include network equipment, industrial devices, etc.) Jaime Blasco, AlienVault Labs Director, posted a blog detailing the exploit.

The video below gives you a quick overview of how we detect malicious traffic on your network trying to locate and exploit this vulnerability.

Basically, this vulnerability allows an attacker to execute shell commands on a server due to an issue in how bash interprets environment variables (such as “cookie”, “host”, “referrer"). Exploiting this allows an attacker to run shell commands directly. Once they have access to run shell commands, they own the server.

Wade Mealing at Red Hat said, “Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.” In other words, this is not a vulnerability restricted to an attack with an existing entry point.

Some folks are touting that this “might be bigger than Heartbleed”, and, while they could be correct it’s still too early to determine the breadth of the exploit and it is very different from Heartbleed. This exploit definitely could have greater consequences than Heartbleed since it allows remote access to a system. Heartlbleed, you may remember, was able to steal small amounts of data by causing a dump of some of the contents in a server’s memory.

However, one similarity with Heartbleed is that the bash vulnerability shows us that, although millions of systems depend on this software, very few users or vendors are conducting thorough testing. This vulnerability has been around for 20 years, but has been undetected until now.

Because of the way bash works, it supports exporting shell functions to other bash instances. The bug makes it so that an environment variable with an arbitrary name (probably undefined) can act as a carrier for a malicious function definition, essentially allowing you to inject code into a web request. If your web applications are running scripts under elevated privileges, attackers can take advantage of this and wreak havoc.

Also, many Internet of Things devices, like IP-enabled video cameras and industrial controls, will be vulnerable. These devices run on web-enabled bash scripts and are not likely to be patched by the vendor. They are also often exposed to the Internet and not secured behind a firewall that could block the exploit traffic.

While bash’s developers have patched all current versions and some of the major Linux distributions (Debian, Red Hat) are working on pushing out updates to their operating systems, it would be a good idea to take steps yourself to reduce the risk of a compromise in your environment.

What can I do?

If you’re already sanitizing inputs across your web applications to protect against SQL injection and cross-site scripting, you’re on the right track. This will give you at least a basic defense.

While CGI is still around on most sites, it is usually restricted to little bits of code that have been around for years. These bits of code have probably not updated under the rule-of-thumb “If it ain't broke, don’t fix it.”

Well – guess what? It’s broke. Fix it. It’s time to find an alternative. But, in the mean time, I would disable any CGI that calls on the shell.

I’ve seen some recommendations to use something other than bash in your applications (Dash, Fish, Zsh, Csh, etc) but I would certainly put some thought and careful planning into that instead of a knee-jerk ‘rip and replace’. Certain shells might work differently or even be missing some of the bash functionality that your applications rely on, rendering them inoperable.

The real fix is going to be patching of bash itself, either from the developers of the distribution you use, or, (if you’re savvy) via your own compiled code. Until then, the steps mentioned above are good first steps to defending yourself.

How can USM help?

Our AlienVault Labs team pushed out updates to the network signatures as well as correlation directives that help identify this type of attack last Thursday, September 25. You should update your AlienVault USM instance ASAP to be made aware if such an attack is launched against your web applications.

AlienVault USM is an all-in-one platform designed and priced to ensure that mid-market organizations can effectively defend themselves against today’s emerging threats, including the new Base vulnerability.

Unlike traditional SIEM or security point products, AlienVault USM provides:

  • Unified, Coordinated Security Monitoring
  • Simple Security Event Management and Reporting
  • Continuous Threat Intelligence
  • Fast Deployment
  • Multiple Security Functions Without Multiple Consoles

You can download a free 30-day trial of AlienVault USM now to detect this threat.

Share this with others

Tags: bash, shellcode

Get price Free trial