The Latest Online Security Issue: What Are Shellshock and Bash?

As more and more of our daily lives takes place online, online security is an issue that is constantly on everyone’s mind, especially when it comes to personal and financial information being compromised. It seems like a new breach or vulnerability is found on a weekly basis, so it’s important to stay up to date on these issues and understand how to make sure you are safe, especially from the perspective of a website owner or administrator.

The latest issue that has come to light is the “Shellshock” vulnerability that affects the UNIX Bash shell. Since so many web servers, services, and web-connected devices use Linux, this is a huge issue that affects a large portion of websites and web servers.

In the early hours of the Shellshock vulnerability in Bash, the joke in the tech community was that Windows Administrators could sit back and watch the Linux/UNIX admins scramble about for once (more on this later). But what exactly is the issue, and how does it affect your website?

What is Bash?

Bash is a scripting language and command-line shell program developed by the GNU Project in 1989. It essentially issues and interprets commands that allow programmers and system administrators to orchestrate commands on UNIX and Linux systems, typically by connecting over SSH or Telnet. It can also operate as a parser for CGI scripts on a web server, typically those running on Apache. If you’d like to learn more, then head over to the GNU Bash page.

Bash is present in the majority of UNIX systems and Linux distributions and also in Apple’s OS X operating system, which borrows many elements from both UNIX and Linux. Beyond that, Bash is present in a very large number of web servers and in-home appliances including, but not limited to, routers and modems, as well as any number of network attached devices and other Internet facing systems.

The Bash bug, which has been dubbed “Shellshock”, was discovered by Stephane Chazelas, a UNIX and Linux network and telecom administrator at the security firm Akamai. It allows attackers to exploit a flaw and run shell commands on a server, taking control of the server without authorization. Since Bash has been in use for years, this vulnerability has been around for some time, perhaps more than 20 years. As with the Heartbleed bug, we can only hope that Chazelas was the first person to find this issue, but we’ll probably never know for certain.

How does the Bash vulnerability affect me?

It did not take long for in-the-wild exploits targeting the Bash vulnerability to show up. These exploits would allow an attacker to remotely attach a malicious executable file to pieces of code or scripts that are executed or interpreted when Bash is called upon. In other words, after delivering a successful exploit, an attacker could gain complete control of affected systems.

Robert Graham of ErrataSec recently wrote a blog, which we highly recommend reading, titled “The shockingly obsolete code of bash”. Graham claims that “bash” is an obsolete code, but is still prevalent on the web and in site code. He does a great job of explaining how a review of your site’s code can help eliminate such vulnerabilities.

In another blog, Graham performed a very rude but simplistic scan, using a HTTP request that pings back to his own IP address. Here is the request he used:

Which, when issued against a range of vulnerable IPs, returned these results:

What actually happened in this example is that the request orchestrated a bunch of external machines to ping the specified IP, simply by issuing a carefully crafted request over the web. What’s really worrying is that this has effectively caused these machines to issue an arbitrary command (albeit a rather simple ping), and that opens up a whole world of serious possibilities.

The risk centers on the ability to arbitrarily define environment variables within a Bash shell which specifies a function definition. The trouble begins when Bash continues to process shell commands after the function definition, resulting in what we’d classify as a “code injection attack”.

The function definition is () { :; }; and the shell command is the ping statement and subsequent parameters. When this is processed within the context of a Bash shell, the arbitrary command is executed. In a web context, this would mean via a mechanism such as a CGI script and not necessarily as a request header either. It’s worth having a read through the seclists.org advisory page for this issue, which goes into more detail, including stating that the path and query string could be potential vectors for the attack.

If you want to determine whether this vulnerability affects you, you can perform a test by running this simple command line within your shell:

If this returns the message “Vulnerable”, it is time to find a patch or upgrade for this issue.

What Should I Do Next?

Of course, one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell. Some experts are indeed recommending this. In many cases, however, this would be a major change and, at the very least, one that is going to require some extensive testing to ensure that it doesn’t cause immediate problems for your website.

The HTTP proof above is a simple but effective one, albeit just one implementation over a common protocol. Once you start throwing in Telnet and SSH, the scope increases dramatically, so are we are by no means just talking about exploiting web app servers here.

Besides code changes, the next thing to do is patch your systems. Here are links to the latest versions of Bash for some of the more popular Linux distributions:

• CentOS
• Ubuntu
• RedHat
• MacOS

However, the risk may well extend beyond bash 4.3. We are already seeing reports of patches not being entirely effective, and given the speed with which they’re being rolled out, that’s not all that surprising. This is the sort of thing those impacted by it want to keep a very close eye on, not just “patch and forget”. Check your vendor’s site regularly.

About that “More on this later” statement…

System administrators who run everything on the Microsoft stack may be asking, “Are we at risk?”

The short answer for that question is “no”, but the long answer is basically “yes”. I’ll tackle the easy one first – Bash is not found natively on Windows, and although there are Bash implementations for Windows, it’s certainly not common. It’s also not clear if products like win-bash are actually vulnerable to Shellshock in the first place.

The longer answer is that just because you operate in a predominantly Microsoft environment doesn’t mean that you don’t have Bash running on machines or devices servicing other discrete purposes within your environment. Does your network have switches and firewalls? Check with your vendors; do you run Cgywin? If so, you may be vulnerable.

The effect on such vulnerabilities is that they spawn similar attacks. It appears that similar Shellshock-like remote code execution is possible on Windows systems, with Windows servers in particular at risk for RCE attacks. The Security Factory, a Belgian security company, reported discovering a command injection vulnerability for Windows command-line shells that takes advantage of environment variables in a similar fashion to Bash exploits.

On a side note, this issue is not susceptible to remote execution, only local execution. We will have to keep an eye on this; when all is said and done, organizations writing environment variables need to audit their code and ensure it is done properly.

Staying Secure

As online security becomes more and more of a relevant issue, it’s important to make sure you’ve addressed any issues your website might have and patched any flaws. Nobody wants to be the next Target or Home Depot, so you should do everything you can to fix any security issues before they become a problem. Do you have any questions for us about how to spot and fix any vulnerabilities affecting your site? Do you want to know more about these security issues? Please contact us to speak to a Solutions Engineer, or feel free to share any other questions you might have in the comments below.