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

Ongoing ITG05 operations leverage evolving malware arsenal in global campaigns

13 min read - Summary As of March 2024, X-Force is tracking multiple ongoing ITG05 phishing campaigns featuring lure documents crafted to imitate authentic documents of government and non-governmental organizations (NGOs) in Europe, the South Caucasus, Central Asia, and North and South America. The uncovered lures include a mixture of internal and publicly available documents, as well as possible actor-generated documents associated with finance, critical infrastructure, executive engagements, cyber security, maritime security, healthcare, business, and defense industrial production. Beginning in November 2023, X-Force observed…

Why federal agencies need a mission-centered cyber response

4 min read - Cybersecurity continues to be a top focus for government agencies with new cybersecurity requirements. Threats in recent years have crossed from the digital world to the physical and even involved critical infrastructure, such as the cyberattack on SolarWinds and the Colonial Pipeline ransomware attack. According to the IBM Cost of a Data Breach 2023 Report, a breach in the public sector, which includes government agencies, is up to $2.6 million from $2.07 million in 2022. Government agencies need to move…

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…

Topic updates

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