September 26, 2014 By Michael Hamelin 4 min read

Shellshock: Another Day, Another Vulnerability Bashing Our Networks

Opening email, reading your favorite blog or turning on the news each day seems to bring a new round of disclosures and warnings about security threats and vulnerabilities. And the past 36 hours have revealed yet another potential security concern after the new Shellshock vulnerability was announced.

At first glance, the recent announcement of a new vulnerability (classified on the National Vulnerability Database as CVE 2014-6271) in the Bash shell might not seem like a big deal. The vulnerability, nicknamed “Shellshock,” is remotely exploitable under the right conditions and affects the Bash shell versions 1.14 through 4.3, which means that it has been around for more than 20 years. When we consider how prevalent UNIX and Linux systems are, how common the Bash shell is, the age of the vulnerability and the relative ease of exploitation, it becomes clear why security professionals are taking notice. And while it’s still being determined if Shellshock is as damaging as Heartbleed, it’s certainly as serious.

The crux of the vulnerability is centered on how the Bash shell processes environment variables. The vulnerability allows for remote execution of arbitrary code placed into an environment variable. When a function is assigned to a variable, the Bash shell executes any commands following the function definition.

Several websites have published a simple mechanism that can be used to help determine whether a system is vulnerable. From a command line, enter the following:

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

If the system is vulnerable, the output should be:

vulnerable

this is a test

What is happening is that the “env” command (used to set and display environment variables) defines “x” as a shell function (the commands between the tick [‘] marks). Notice that the syntax dictates that the definition of function starts with the opening Poisson bracket ‘{‘ and ends at the closing right Poisson bracket ‘}.’ When the command “bash” is executed, a new bash shell is created that processes all the shell variables and function definitions defined in the parent shell, including the definition of function ‘x.’ This is done so that the new shell can inherit the definition of all the environment variables and functions. The problem is that it sees the definition of ‘x’ ending at “}” and then goes ahead to process the rest of the string “echo vulnerable” as a shell command and executes it. This behavior is what is at the heart of the vulnerability.

If the system is not vulnerable, the result will be an error message followed by “this is a test.” That is because on a system that is not vulnerable, the string appended after the definition of the function “x” (i.e., after the closing Poisson bracket “}”) generates an error message.

For most organizations, fixing this requires a vendor patch. In extreme circumstances, it is technically possible to download the fixed Bash source code and compile your own binary, though that route is not recommended for most and should only be considered as a last resort after careful planning.

The best course of action for organizations at this point is to do the following:

  • Work with your vendors and identify all systems that will need patching, such as UNIX, Linux, OSX and potentially even Windows, if you are using Cygwin. Also, check your embedded devices and network devices.
  • Best practice indicates starting with Internet-facing systems to harden your exterior.
  • Pay close attention to logs and network traffic in the upcoming weeks and months to quickly identify compromised systems.

Protection Against Shellshock Exploits

While vendor patches are a first line of defense, IBM can help protect customers from the exploit of this vulnerability with the IBM Security Network Intrusion Prevention product offerings. In fact, IBM has been helping to protect customers from this and similar attacks since 2007, thanks to Protocol Analysis.

IBM is able to identify and help protect from Shellshock using a signature named Shell_Command_Injection, which was released in 2007. So, the IBM Security IPS offerings have been able to identify and protect from this vulnerability for the past seven years. This signature identifies shell commands (operating system commands) traversing the network inside protocols where they do not normally belong — for instance, inside of the HTTP header field of traffic destined to a Web server.

How Bash Shellshock Exploits Could’ve Been Avoided Years Ago and What You Can Do to Avoid it Today!

IBM’s approach to protecting clients is fundamentally different. Instead of trying to detect the latest exploit attempt, requiring constant additions and/or modification of signatures, IBM focuses on identifying and then shielding the vulnerability from an attempted exploit. In the case of Shellshock, IBM has been able to identify and protect against exploits of this nature since June 2007.

Preparedness Is Key

For a longer-term prospective, the 3Q-2014 X-Force Threat Intelligence Quarterly discussed lessons learned in the wake of Heartbleed. The following takeaways apply here as well:

  • Keep up with threat intelligence
  • Maintain a current and accurate asset inventory
  • Have a patching solution that covers your entire infrastructure
  • Implement mitigating controls
  • Instrument your environment with effective detection
  • Create and practice a broad incident response plan

It should be noted that in addition to CVE 2014-6271, CVE-2014-7169 was disclosed on Sept. 25. This vulnerability is associated with the initial fix released to address the vulnerability.

More from X-Force

CVE-2023-20078 technical analysis: Identifying and triggering a command injection vulnerability in Cisco IP phones

7 min read - CVE-2023-20078 catalogs an unauthenticated command injection vulnerability in the web-based management interface of Cisco 6800, 7800, and 8800 Series IP Phones with Multiplatform Firmware installed; however, limited technical analysis is publicly available. This article presents my findings while researching this vulnerability. In the end, the reader should be equipped with the information necessary to understand and trigger this vulnerability.Vulnerability detailsThe following Cisco Security Advisory (Cisco IP Phone 6800, 7800, and 8800 Series Web UI Vulnerabilities - Cisco) details CVE-2023-20078 and…

X-Force data reveals top spam trends, campaigns and senior superlatives in 2023

10 min read - The 2024 IBM X-Force Threat Intelligence Index revealed attackers continued to pivot to evade detection to deliver their malware in 2023. The good news? Security improvements, such as Microsoft blocking macro execution by default starting in 2022 and OneNote embedded files with potentially dangerous extensions by mid-2023, have changed the threat landscape for the better. Improved endpoint detection also likely forced attackers to shift away from other techniques prominent in 2022, such as using disk image files (e.g. ISO) and…

Widespread exploitation of recently disclosed Ivanti vulnerabilities

6 min read - IBM X-Force has assisted several organizations in responding to successful compromises involving the Ivanti appliance vulnerabilities disclosed in January 2024. Analysis of these incidents has identified several Ivanti file modifications that align with current public reporting. Additionally, IBM researchers have observed specific attack techniques involving the theft of authentication token data not readily noted in current public sources. The blog details the results of this research to assist organizations in protecting against these threats. Key Findings: IBM research teams have…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today