Checkmarx Launches Infrastructure as Code Scanning Solution to Secure Cloud-Native Applications: KICS

All You Need to Know About Shellshock & What You Can Do About It

So, what happens when a core component of Mac, Linux and other Unix-based operating systems is found to be highly vulnerable and easily exploitable? 

Last week, we found out: On September 24th, the world was first introduced to a family of bugs in the Bash shell, being referred to both as ‘Shellshock’ and ‘Bashdoor’.

Here’s a breakdown of what the Bash bug is, how it can be exploited, and how you can protect yourself.

Background on Bash & the Bash Bug Being Called Shellshock

Bash (short for Bourne Again Shell) is a command-line shell used to type and execute commands. It is prevalent in Mac OS X, Linux, and other versions of UNIX operating systems. It’s also a mainstay on servers running Apache, accounting for about 51% of the world’s servers.


pic 1

Even if you don’t personally use the shell, Bash is being called and used by different programs and apps in ways you don’t see firsthand. Your wireless router, your phones, your IoT devices – could all be using Bash.

The issue, Michael Zalewski of Google wrote, is that “the internal parser invoked by Bash …continued parsing the code past the end of the function definition itself – and at that point, flat out executed whatever instructions it came across.”

Basically, if Bash is the default command line program on a system, it’s open to executable remote attacks. An attacker could attach malicious code in the OS’ environment variables that could gain control of the environment, with limitless options once control is taken over.

Stephane Chazelas, a British UNIX/Linux specialist, first discovered the bug on September 12, but kept it undisclosed until September 24, when preliminary patches began distribution. Unfortunately, as those patches were unleashed, a new round of similar bugs was discovered as well, deeming the first patches irrelevant. To date, a total of six vulnerabilities are affiliated with the Shellshock family of bugs.

So, How Bad Is It? Is it really worse that Heartbleed?

The Bash bug is being called ‘Bigger than Heartbleed’ for a few reasons. The NIST has given Shellshock a ‘perfect’ rating of 10.0 out of 10.0 for both Impact and Exploitability, meaning the bug is both easily exploitable and has the capacity to impact a huge number of systems.

Even worse than how ubiquitous it is is the fact that Bash is embedded and accessed in so many various ways that it’s impossible to know all the different use-cases in order to secure them. Not every vulnerable system is vulnerable to remote exploit, it’s important to note, but the danger is there for many.

The Bash bugs also allow attackers more power than they had with the OpenSSL bug. A malicious actor could take complete control of a system, without even the need for user credentials.

How Can Attackers Use This Vulnerability?

“Getting shell,” as Troy Hunt writes, is a huge score for hackers because it allows them near-limitless control of the environment they’re targeting. In the best-case scenario of a Shellshock attack one a single computer, the hacker could install a keylogger, read and send emails, steal credentials, and pretty much own your computer.

An attacker could also write new files on the system, a ‘no-brainer’ way to spread self-replicating malware, AKA a worm. Because it’s so early on in the discovery and patching process, many servers and computers not used on a daily basis aren’t going to be patched for a while, meaning malware could go undetected for a long time on many systems.

In these early days, however, we’re seeing less severe attacks so far. Brandon Potter, who set up a Shellshock test tool, analyzed the first few days after releasing the tool to the public, with some interesting results on where attackers were focusing on:

pic 2


CloudFlare is also monitoring the Shellshock action coming at their servers. They found that the most popular attack thus far is one of ‘reconnaissance,’ basically a process to see which machines are vulnerable. Once vulnerable systems are found, they’re in for whatever the attacker has in store.

Reconnaissance looks like this:

 pic 3


How to Check if Your System is Vulnerable:

First, you should run the following command in your computer’s Terminal to see whether or not you’re vulnerable:

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

If your system is vulnerable to the Bash bug, you’ll see the following:


     this is a test

If your system has already been patched or is protected already, you should see:

     $ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

Patches are available for most of the well-known systems. Python, PHP, C++ applications are at risk as well, so if you’re If you’re a Mac owner, you can download the newly available patch Apple released, though it’s since been found to be incomplete, keeping users open to Denial-of-Service attacks. Still, one patch is better than no patch. This is yet another reminder why it is so vital to upgrade and patch your systems.

What Does It Mean for the Future of Software Security?

The fact that the Bash bug was sitting dormant for over 20 years is not a beacon of light on the security of our infrastructure and open-source code, but it does offer us a great chance to take a second look at our belief, proven wrong yet again, that many eyes makes all bugs shallow.

Robert Graham of Errata Security wrote that if you’re writing for the eyes of a security reviewer, you’re likely producing clearer code for others, too. Maty Siman, Checkmarx CTO and founder, stressed that the Bash bug is “just further proof of the need for developers to be better educated in security awareness while writing code.” The fact that the vulnerable code was part of an open-source project, written 25 years ago and most likely reviewed by dozens of people, further indicates how difficult it is to write secure code.

There is a silver-lining to all this. The disruption caused by Shellshock offers a perfect opportunity for organizations to amplify our security awareness efforts, especially for our developers. Who knows what the internet will look like in another 20 years, but wouldn’t it be great if we could change its’ security for the better by proactively building secure programs?

Read more about getting developers more engaged with security here.

Jump to Category