How Not to Get BASH-ed

A major vulnerability in the Bourne Shell —  called bash shell – has come to the fore. This vulnerability existed for a long time. Using the vulnerability, a client ( or equivalently a server) can insert malicious commands into the server ( or equivalent client) when the server ( equivalently client)  uses a bash script with inputs from environmental variables that are set by the client ( or equivalently server).

The implications are huge as it affects all *NIX systems — Linux —  Ubuntu, Debian, CentOs, others, Unix with all its variants such as Solaris, BSD, NetBSD, others.  Unix/Linux systems are so prevalent that they are used everywhere and the shell is one of the most common programs used in these systems.

To get into a bit more technical details, these are the details of the vulnerability. Some of this material is taken from http://seclists.org/oss-sec/2014/q3/650.  Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.  Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment.  The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition.  For example, an environment variable setting of

VAR=() { ignored; }; /bin/id

will execute /bin/id when the environment is imported into the bash process.  (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.)

The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.

Thus, for instance, when you connect your mobile or a computer system to wifi or a wired network, a DHCP client takes variables sent from a DHCP server while your system ( mobile, desktop) connects to a network. These variables are used in a shell program. A rogue DHCP server can now play havoc with your system by running malicious commands on it.

A web server such as an apache/NGINX, when it runs cgi-scripts, takes input from the client via shell variables. Here, the client can insert malicious commands.

Right from routers, to all kinds of other systems, shell scripts are used, and this vulnerability can play havoc. In fact, the bash shell is so ubiquitous that it may be impossible to know the full extent of this vulnerability. You may be vulnerable even if you are using the shell to connect to a remote system.

The way out is to upgrade your shell to the latest version. Patched bash shells are now out from various vendors.

The other workaround is to insert WAF signatures to block this vulnerability/exploit in case you are running a website. In case, you are running a program such as SSH over the network, an appropriate signature will have to be installed at layer 4 – in the IPS.

Conclusion

Indusface’s core ruleset has exhaustive protection for the “command injection” category of vulnerabilities, those core rules already protected users against most of the Bash-centric vulnerabilities. We have added a few more signatures for various customer environments to ensure the highest level of customized security for existing Indusface WAF customers.