Introduction
A critical vulnerability in the Bourne Again SHell (BASH) was recently discovered and has been getting a great deal of coverage in the technical press. BASH is an important UNIX/Linux/BSD software component that provides the operating system shell for most common distributions of Linux as well as Apple’s UNIX-based OS X operating system for its desktop and laptop computers. The vulnerability is being called either the BASH bug or Shellshock.
The shell was created for the GNU Project and has been around for a long time – since 1989. The vulnerability has been around for a long time, too, but security researcher Stephane Chazelas, who works for Akamai Technologies, only recently came across it. Once the word got out, security experts jumped on the story and network admins started worrying about whether the Linux and UNIX-based systems on their networks are vulnerable and what they need to do about it.
The open source security myth
Coming so closely on the heels of Heartbleed (the vulnerability in the OpenSSL cryptographic library that affected so many Apache web servers and some Linux systems), BASH is another reminder that despite the popular belief in some circles that *NIX-based clients and servers are secure and only Windows machines are open to attacks and malware, the reality is something different.
This month (September 2014), Apple released an update for OS X Mountain Lion and Mavericks that patched more than 40 security vulnerabilities in the OS, including critical ones that can be exploited by attackers to carry out remote code execution and completely take over a system. Every month, Ubuntu releases anywhere from 20 to 50 security patches and other Linux vendors put out a comparable number of updates.
The basic premise that open source is inherently secure is based on the idea that because there are thousands of eyes on the code (that is, any and everyone can view and revise the OS source code), there will be fewer programming bugs – and those that do creep in will be discovered much more quickly and will be immediately fixed because there’s no need to wait for a proprietary company to build a patch. It sounds good, and sometimes it even works that way.
But sometimes it doesn’t. Experts estimated that Heartbleed had been lurking in Open SSL for years, and that BASH has been around even longer. The simple truth is that all operating systems, all web browsers, all applications – in short, all computer software – has vulnerabilities and many times those bugs are not obvious and lie dormant for a very long time before someone (a security researcher if we’re lucky, a hacker/attacker if we’re not) stumbles across it. When the good guys get there first, they privately report it to the software vendor to give the company time to address it and/or they develop a fix for it themselves. When the bad guys find it, they use it to create attacks that can be carried out before systems can be protected against it.
While open source means some of the red tape involved in developing and then testing a security fix can sometimes be bypassed, it also means less accountability and therefore in some cases less incentive to create a patch or, conversely, a chaotic situation as multiple sources scramble to develop patches and may sometimes rush those patches out before determining that they’re fully effective.
Red Hat, Fedora and Ubuntu came out with updates to address the BASH vulnerability within a few days after its discovery. However, US-CERT later put out a bulletin that said those updates that were initially released didn’t completely fix the problem and that attackers could still exploit the bug even on systems that had been patched. Meanwhile, Apple didn’t respond for days to queries about the effect of BASH on their systems. Then they released a statement saying Macs were “unlikely” to be affected by BASH. Then a few days after that, they released an update for OS X to patch the vulnerability.
How the BASH exploit works
Here’s how an exploit of this vulnerability works, in a nutshell: the attacker sends a request to a computer that’s running an unpatched version of BASH, which has data that’s stored in an environmental variable. This data is crafted to be a malicious command, which the operating system runs, “thinking” it’s a legitimate script. This means the attacker can run whatever code he wants, using the same access privileges as the system that launches the shell. This allows him to take over the system completely and run other programs, access and manipulate files, change settings, etc.
Why BASH matters
This web site is called WindowsNetworking.com for a reason; it’s targeted at administrators of Windows-based networks. If that’s what you are, you might be wondering whether and why you should be concerned about BASH at all. After all, this is just a *NIX problem, right?
Yes and no. BASH isn’t part of any version of Windows server and client operating systems. The Windows command shell, cmd.exe, is used to perform the types of functions that BASH is used for. However, there is an open source tool for Windows called Cygwin that is a sort of “BASH for Windows” and according to reports, it is subject to the same vulnerability.
Okay, but there’s a good chance that you don’t use Cygwin; only a small percentage of Windows admins and users do. That doesn’t mean you can go happily about your business and not worry about it. First, many primarily Windows shops have a few servers stashed away in a corner that are running Linux, often as a cost-saving measure. You might have set up a Linux web server to avoid paying for a Windows Server license, or you might be using a Linux server for some dedicated task, such as monitoring the company’s surveillance cameras or managing a computerized climate control or lighting system.
Still doesn’t apply to you? You’re absolutely certain that your server room or datacenter is *NIX-free? Okay, next consider whether any of your users are running Linux or, more likely, Mac OS X laptops on your network. With BYOD programs proliferating, there’s a strong possibility that even if your company doesn’t own any non-Windows machines, a few of those personally-owned computers are Macs.
However, that isn’t the biggest threat. The other problem is all of those computers completely outside of your organization, to which your computers connect over the Internet. Literally millions of servers on the Internet are running on Linux, UNIX or BSD: web servers, mail servers, databases and so forth. If your users exchange any kind of sensitive company or personal information with those machines and they suffer from this vulnerability, they could be compromised – and that means all of that data could be compromised.
Remember, too, that it isn’t only traditional client and server computers that are at risk from BASH. Everything that runs on *NIX is potentially in danger. The latest IT buzz phrase is “the Internet of Things” (also known as IoT). A large percentage of those “things” – appliances and dedicated devices that can connect to and be controlled over the Internet – are running on Linux based software. Your company might have alarm systems, vending machines, smart thermostats, company cars and fleet management systems, even the refrigerator in the break room, that have Linux inside.
If an attacker is able to exploit the BASH bug, the ramifications can be serious. The attacker can completely take over the affected system. And it’s not just theory; there have been reports that just days after the IT world found out about it, BASH was already being exploited in the wild, used to take control of a number of Linux-based web servers and make them part of a botnet. The bad news is that this flaw is relatively easy to exploit, and once it became widely known, attacks and attempted attacks have proliferated.
Given the huge scope of computers and devices that can potentially be affected by BASH, combined with the severity of the consequences of an exploit, it’s no wonder some experts are calling this a bigger deal than Heartbleed and one of the most significant vulnerabilities to come along in an while.
How to address the BASH threat
What, then, can you do to protect your organization from BASH? The first step is to patch any *NIX-based computers under your control as soon as possible. Most major *NIX vendors have released patches at this point and an unofficial patch has been developed. All past and current unpatched releases of BASH (i.e. versions 1.x through 4.x) are vulnerable.
Even if you installed a patch last week when BASH was initially discovered, you may need to patch again. Additional attack vectors have been discovered since that, and new patches have been issued.
You can find out whether your *NIX-based computers are vulnerable by (ironically) running BASH and entering the following command:
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
If your version of BASH is in fact vulnerable, this will output a line containing only the word “vulnerable.”
If you’re using a commercial version of Linux/UNIX/BSD, your vendor may also provide automated tools for checking for the BASH vulnerability. For example, Red Hat provides a script for their customers (you have to have registered your software and sign in with your registered account).
There are a number of online testing tools available for testing remote web sites for the vulnerability, as well. Most of these have been created by individuals in the open source community, so there is an issue of trust involved in running them.
It appears this particular vulnerability (or more accurately, set of vulnerabilities) might be an ongoing issue for a while, since new ways to exploit BASH are being discovered, so be sure to stay abreast of the latest developments.
