Shellshocked: A Primer on the Bash Shell Vunlerability

A critical vulnerability exists in over half of the server grade computers running on UNIX, Linux, Apple Mac operating systems. In terms of damage and spread it could only be compared to Ebola virus epidemic.

I was UNIX system administrator since early 90’s. Those days we had to do everything on green screen terminals. The command interpreter or shell (called Bourne shell) that operating system provided by default was cumbersome for repeated typing. Sometime during middle of that decade GNU Bash (Bourne Again Shell) was becoming the shell of choice on UNIX systems. It was such a powerful shell, compatible with standard shell but at the same time combined best features of other shells with cool tricks such as auto command completion. It became my preferred shell ever since.

Like the other Open Source software and utilities, Bash source code must have passed through several contact lenses, glasses and ultimately – developer’s, quality assurance, and hacker’s eyeballs countless number of times. This is why it’s shocking to hear about a critical vulnerability in bash shell to those of us in security community. How could such a vulnerability remain hidden in plain sight? And no one was able to do so in the last twenty years?

There is a belief system in Open Source community that because the open source software has many eyes looking at it is more secure than proprietary software. Did that belief come down crashing ever since the discovery of the bash vulnerability? Easy to think that way but on the contrary the very belief may have helped its obscurity. It remained undiscovered because open source was presumed (rightly) to be more secure. It almost became like a form of security by obscurity.

So what is Shellshock vulnerability all about?

Shellshock gained sudden notoriety once high profile sites such as Yahoo, WinZip and Lycos were rumored to have been attacked by a group of Romanian hackers exploiting shellshock vulnerability. Although Yahoo has confirmed that some of their servers were exploited; but denies that the hackers used shellshock vulnerability to gain access. Some security experts believe that the Romanian attackers were using these servers to further gain access into Yahoo’s gaming servers and target private data of gamers. However Yahoo confirmed that no customer data was breached.

Shellshock was first discovered in the middle of September by a Linux expert from UK. It was not announced to the world until Sept 24. Since then about 6 different bugs similar to Shellshock were discovered.

This vulnerability is classified by as “High impact” and “Low complexity” by security industry standard. It takes little skill to exploit and that’s what make it so dangerous in the hands of hardcore hackers and script kiddies equally. Unix including Linux/MacOS/Solaris etc is a predominant operating system for servers. Majority of Worlds Web sites run on Unix servers. With this kind of threat profile and its widespread prevalence means that shellshock has so much potential to cause unprecedented level of damage.

How does it work?

Its mechanism is as simple as setting a bash environmental variable. This is a simple enough step which people use countless number of times while working on a Unix machine. A typical example would be setting a Path variable. But while setting this variable you could execute a shell command which would bypass other restrictions enforced on it even if they were enforced at the shell prompt. Attacker will maliciously execute a piece of arbitrary code.

To illustrate this further let us take the example commonly provided to check Shellshock vulnerability.

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

In the code above the “env” command will try to create a variable called x which is basically a function. This is a valid usage of the “env” command. Within the curly bracket we have a colon and a semicolon that is the executable statements for the function x. Here “:” means do nothing and “;” is the end of statement. So far this is perfectly legal. In ideal world the shell should stop parsing after the semicolon that is next to “}”.

But for reasons to perhaps make Bash more powerful as a scripting language developer of the parser got too greedy for their own good. So the “echo vulnerable” part of the crafted command is what is wrong. If patches addressing the shellshock vulnerability have been applied on your system then you will If patched you would see warning messages at shell prompt and the message “this is a test”; however if no patches have been installed your shell prompt will say “vulnerable” followed by “this is a test”.

Typically we see attackers are constantly scanning ports, guessing passwords, and running known attacks such such as cross site scripting, or even running denial of services attacks. Many of these kind of attacks are scripted by malware programs running on network of bots. Once an attacker gains access to a system using Shellshock vulnerability, possibilities are endless. Typical action would be to use this server as a stepping stone and a bot to gain deeper access into the customers network as well as launch attacks on other sites.

Further, there is a malicious program called Mayhem, being unleashed on Linux and Unix servers using the recently discovered Shellshock Bash vulnerability. Mayhem started in April used to run PHP script to infect servers and now in its latest form runs perl script which uses shellshock

So what could be done about it?

Fortunately patches are available from all major vendors of Unix, Linux and other unix like operating systems that features GNU bash shell. Second piece of good news is that this exploit does not elevate the privilege, that means if a non super user account with limited privileges get exploited, it would not be able to run any arbitrary programs at superuser or “root” level.

Possible attack vectors through which a hacker could be able to exploit this vulnerability include features of OpenSSH (Secure shell program implementation), CGI (Common Gateway Interface) modules on popular Apache web server; and certain DHCP clients which allow scripts. If you have systems that running any of the above you have increased risk and these systems must be handled at extremely high severity at the most critical level.

Even after the patches have been applied, there could be potentially several hosts acting as bots which were hacked prior to patching. So a security administrator needs to carefully examine logs from security monitoring systems for any signs of malware running on these systems. Only then the impact from Shellshock would be reduced and threat eliminated.

In the long run one thing for sure, there will be an increased focus on security of the source code. Even the old tried and trusted source codes will be reviewed by Open source and hacker. Stressful, yet interesting times ahead.