First Heartbleed, now Shellshock?
Half a year has passed since the discovery of the dreaded Heardbleed bug, and the shock of that incident, which many have dubbed the most serious security flaw in years, has finally begun to wear off. Then the security community has been shocked again last week, when details of a new critical vulnerability in another widely used piece of software have been made public after the initial embargo.
Apparently, Bash, arguably the most popular Unix shell software used on hundreds of millions of servers, personal computers, and network devices, contains a critical bug in the way it’s processing environment variables, which causes unintentional execution of system commands stored in those variables (you can find a lot of articles explaining the details, ranging from pretty simple to deeply technical). Needless to say, this provides an ample opportunity for hackers to run malicious commands on affected machines, whether they are connected to the network or not. What’s worse, the bug has remained unnoticed for over twenty years, which means that huge numbers of legacy systems are affected as well (as opposed to Heartbleed, which was caused by a bug in a recent version of OpenSSL).
Given the huge number of affected devices, many security researchers have already called Shellshock “bigger than Heartbleed”. In my opinion, however, comparing these two problems directly isn’t that simple. The biggest problem with the Heartbleed bug was that it has affected even those companies that have been consistently following security best practices, simply because the most important security tool itself was flawed. Even worse, those who failed to patch their systems regularly and were still using an old OpenSSL version were not affected.
Shellshock bug, however, is different, since Bash itself, being simply a command-line tool for system administrators, is usually not directly exposed to the Internet, and the vulnerability can only be exploited through other services. In fact, if your IT staff has been following reasonably basic security guidelines, the impact on your network will already be minimal, and with a few additional steps can be prevented completely.
The major attack vector for this vulnerability are naturally CGI scripts. Although CGI is a long outdated technology, which, quite frankly, has no place on a modern web server, it’s still found on a lot of public web servers. For example, the popular Apache web server has a CGI module enabled by default, which means that hackers can use Shellshock bug as a new means to deploy botnet clients on web servers, steal system passwords and so on. There have already been numerous reports about attacks exploiting Shellshock bug in the wild. Researchers also report that weaknesses in DHCP clients or SSH servers can potentially be exploited as well, however this requires special conditions to be met and can be easily prevented by administrators.
So, what are our recommendations on dealing with Shellshock bug?
For consumers:
First of all, you should check whether your computers or network devices are affected by the bug at all. Vulnerable are computers running different Unix flavors, most importantly many Linux distributions and OS X. Obviously, Windows machines are not affected unless they have Cygwin software installed. Most embedded network devices, such as modems and routers, although Linux-based, use a different shell, BusyBox, which doesn’t have the bug. As for mobile devices, stock iOS and Android do not contain Bash shell, but jailbroken iOS devices and custom Android firmwares may have it installed as well.
A simple test for checking whether your shell is vulnerable is this command:
env X="() { :;} ; echo vulnerable" /bin/sh -c "echo hello"
If you see “vulnerable” after running it, you know you are and you should immediately look for a security update. Many vendors have already issued patches for their OS distributions (although Apple is still working on an official patch, there are instructions available for fixing the problem DIY-style).
For network administrators:
Obviously, you should install security updates as well, but to stop there would not be a good idea. Although a series of patches for currently described Bash vulnerability has already been issued, researchers warn that Bash has never been designed for security and that new vulnerabilities can be discovered in it later. A reasonable, if somewhat drastic consideration would be to replace Bash on your servers with a different shell, since just about every other shell does not interpret commands in environment variables and is therefore inherently invulnerable to this exploit.
Another important measure would be to check all network services that can interact with Bash and harden their configurations appropriately. This includes, for example, the ForceCommand feature in OpenSSH.
Last but not the least, you should make sure that your network security tools are updated to recognize the new attack. Security vendors are already working on adding new tests to their software.
For web application developers:
Do not use CGI. Period.
If you are stuck with a legacy application you still have to maintain, you should at least put it behind some kind of a “sanitizing proxy” service that would filter out requests containing malicious environment variables. Many vendors offer specialized solutions for web application security, however, budget solutions using open source tools like nginx are possible as well.
So, if Shellshock bug can be fixed so easily, why are security researchers so worried about it? The main reason is a sheer number of legacy devices that will never be patched and will remain exposed to the exploit for years. Another burning question for IT departments is: how long hackers (or worse, NSA) have been aware of the bug and for how long they could have been secretly exploiting it? Remember, the upper limit for this guess is 22 years!
And of course, in even longer perspective, the problem raises a lot of new questions regarding the latest IT fad: the Internet of Things. Now that we already have smart fridges and smart cars and will soon have smart locks and smart thermostats installed everywhere, how can we make sure that all these devices remain secure in the long term? Vendors predict that in 10 years there will be over 50 billion “things” connected to a global network. Can you imagine patching 50 billion Bash installations? Can you afford not patching your door lock? Will you be able to install an antivirus on your car? Looks like we need to have a serious talk with IoT vendors. How about next year at our European Identity and Cloud Conference?
Originally published at Alexei Balaganski.