Shellshock is a bug in the Bash command-line interface shell that has existed for 30 years and was discovered as a significant threat in 2014. Today, Shellshock still remains a threat to enterprise.  

The threat is certainly less risky than in the year of discovery. However, in a year in which security priorities have recalibrated to keep up with the chaotic landscape, it’s a good time to look back at this threat and the underlying factors that keep these attacks alive today. 

Why is Shellshock Relevant in 2020?

Shellshock is a critical vulnerability due to the escalated privileges afforded to attackers, which allow them to compromise systems at will. Although the ShellShock vulnerability, CVE-2014-6271, was discovered in 2014, it is known to still exist on a large number of servers in the world. The vulnerability was updated (CVE-2014-7169) soon after and has been modified up until 2018. 

The main reason Shellshock is still in use is no shocker. This vulnerability is a simple and inexpensive attack bad actors can deploy against an unknowing target. Patches have been available since the CVE entry, but any organization without proper patch management systems in place may still be vulnerable.

Shellshock was still prominent in 2017. When all attackers need are some basic programming skills, a server and access to malware, it’s not surprising. Plus, the cost to carry out an attack isn’t much more than a few dollars per month. The math is in the attackers’ favor. Minimal knowledge, little effort and low cost equals one easy hacking strategy.

Despite all the extensive cybersecurity media coverage and even a Department of Homeland Security alert, some systems remain unpatched. In one example, officials at the Center for Election Systems failed to apply a patch that compromised the Georgia elections systems.

How Does Shellshock Work? 

In layman’s terms, Shellshock is a vulnerability that allows systems containing a vulnerable version of Bash to be exploited to execute commands with higher privileges. This allows attackers to potentially take over that system.

Diving deeper into the technical, Shellshock is a security bug in the Bash shell (GNU Bash up to version 4.3) that causes Bash to execute unintentional bash commands from environment variables. Threat actors exploiting the vulnerability can issue commands remotely on the target host. While Bash is not inherently Internet-facing, many internal and external services such as web servers do use environment variables to communicate with the server’s operating system. 

If those data inputs are not sanitized — the coding standard process that ensures that code is not part of the input — before execution, attackers may launch HTTP request commands executed via the Bash shell.

Vulnerability in Detail 

Web servers are not the only vulnerable network resources. E-mail servers and DNS servers that use BASH to communicate with the OS could also be affected. While BASH is normally found on Unix-based systems, organizations using Windows-based systems are not immune. Those are probably leveraging appliances or hardware that are vulnerable. Remember, BASH can be a part of home routers, many IoT devices and embedded systems.

Shellshock can even be used to launch Denial of Service (DOS) attacks. 

Here is the line of code (a Bash function declaration followed by a semicolon and the ‘sleep’ command run from three possible paths to ensure it gets executed): 

new_function() { :;}  ;  /bin/sleep 20   /sbin/sleep 20  | /usr/bin/sleep 20

This “sleep” command forces the server to wait twenty seconds before replying. In doing so, resources on the machine are essentially held hostage because the machine can do nothing else for twenty seconds.

One sleep command may be harmless, but an attacker may be able to replace this with malicious code. Then, that code can handcuff the server or resource so it is unable to handle any requests.

The risk of allowing harmful Internet users to execute commands of their choice remotely is high. By using the opening, bad actors may launch programs on the system, create outbound connections to their own systems and execute malicious software. 

Perhaps most critically, the vulnerability can be leveraged to steal confidential data and information stored on the system like credit card details, passwords and personally identifiable information (PII).

Is Shellshock Still Rampant?

Shellshock is not as prevalent as it was when it was discovered in 2014. Imagine the challenge of having to patch all of your company’s vulnerable servers (and, there were many at the time). 

That said, Shellshock remains a problem. 

For example, there is an ongoing cyber threat and vulnerability campaign called “Sea Turtle” that takes advantage of DNS records to gain access to sensitive systems. For the attacks to succeed, it requires a number of common hardware and software vulnerabilities — Shellshock being one of them. 

While not nearly as rampant as before, every company should make sure all hardware and software are patched and up to date.

How To Know if You’re Affected

Because Shellshock is six years old, plenty of vulnerability scanners are available. Some of them are free. One, bashcheck, can be downloaded using Github. 

For those technical people, typing a simple command in the Bash prompt will also do the trick:

env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed” 

env X=”() { :;} ; echo Bash is Infected” `which bash` -c “echo completed”

env VAR='() { :;}; echo Bash is Infected‘ bash -c “echo completed”

If the prompt returns a “Bash is Infected” message, it’s time to update and fix. If your output does not return “Bash is Infected,” it will respond with something like:

bash: warning: VAR: ignoring function definition attempt

bash: error importing function definition for `VAR’

Bash Test

If you’d like to test vulnerability for websites or specific CGI scripts, the following tool can help: ‘ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool. In either of the two input fields, enter the URL of the website or CGI script you’d like to test and click on the blue buttons.

What We can Learn About Cybersecurity Threats

The biggest lesson for the enterprise here — and it bears repeating — is to patch your systems.

Teams that can reduce patching times are in a better position to shift those resources to more pressing security concerns. While some companies consider patch management more of an IT responsibility than a security one, patch management must always be top of mind for security departments as it is critical to a company’s security posture. 

If your systems are still vulnerable today, there are probably some underlying operational issues that should be addressed. Shellshock is a very old vulnerability with patches available for almost any system. The best way to protect yourself against this type of vulnerability is to keep your systems up to date, applying all the fixes released for this exploit.

When patching assets, typically a straightforward process, you should embrace a strategic approach.

Patches tested thoroughly are a great way to minimize business impact — like a mission-critical server running an old OS, for example. If a system cannot be patched immediately, the potential risk of the vulnerability must be weighed against the business impact.

Shellshock is just one in a long list of vulnerabilities with which the enterprise must deal. Managing the seemingly endless stream of vulnerabilities is and always will be a critical strategy that underpins cybersecurity. 

Checklist for a Secure Organization 

For successful vulnerability management, companies must have the capability to succeed in these three areas:

• Identifying potentially impactful vulnerabilities quickly: Speed is everything here. Having everyone on the same page with a solid plan should promote quicker reaction times. 
• Determining the severity level of the vulnerability: Knowing your organization’s tolerance for risk will go a long way in determining how severe a vulnerability might be. Depending on your network infrastructure, some vulnerabilities are more harmful than others. 
• Having a plan of action that balances security urgency with potential impact on production environments: Balancing security with production and productivity is a constant hurdle, but organizations with the most well-defined plans for vulnerability management typically find the best balance.

For independent security researcher Rod Soto, the biggest lesson learned from Shellshock was that the internet is based on many vulnerable applications and always carries the potential to compromise a large portion of its segments.

“The way to manage these potential vulnerabilities in the future is to keep communication open and transparent between developers, maintainers and security professionals,” Soto says. “So if such an extensive and significant vulnerability is found, coordination between all affected parties can be used to patch or mitigate affected systems.”

Even cases in which your company is successful in mitigating risk to Shellshock or any other vulnerability, you cannot assume that your response plan is perfect. The response plan should be a living, breathing document, and should be reviewed often so that your organization can respond to threats rapidly. 

Finally, like in any post-attack scenario, there are questions you should be asking as you review each phase of the plan. 

• Which parts of the plan were successful?
• Which parts of the plan were not successful?
• What didn’t we do that we now realize we needed to do?  
• What did we learn that allows us to be more prepared for the next vulnerability that comes our way?

Shellshock may be an old attack, but for an attacker, it ticks all the boxes for exploiting victims who lack proper security hygiene.