Shellshock

Shellshock, discovered in 2014, is a family of significant vulnerabilities in the GNU Bash shell, affecting a wide range of systems. It enables attackers to execute arbitrary code (Arbitrary Code Execution, ACE) on vulnerable systems, exploiting environment variables in Bash. The severity of Shellshock lies in its widespread impact, targeting systems running Bash, including web servers, DHCP clients, and network services.

A Shellshock logo

Background

Bash Shell

The GNU Bourne Again Shell (Bash), introduced in 1989 by Brian Fox, is a widely used command-line interface (CLI) in Unix-like operating systems. Renowned for its flexibility and extensive feature set, Bash combines capabilities from various other shells, such as the KornShell (ksh) and the C Shell (csh) .

However, this complexity also introduced vulnerabilities, as highlighted by the Shellshock incident. Bash's integral role in numerous systems and devices across networks significantly amplified the impact of these vulnerabilities, underlining the importance of secure shell programming and system design.

Discovery

The collective discovery of Shellshock's related vulnerabilities unfolded in 2014, starting with Stéphane Chazelas, a French software developer, uncovering the initial bug, CVE-2014-6271 (Common Vulnerability and Exposures, CVE), which he originally called Bashdoor. The vulnerability was a significant flaw in the Bash shell, which had gone unnoticed for over two decades.

Upon its discovery, it was quickly recognized for the potential to allow attackers to execute arbitrary code on affected systems . The revelation of Shellshock prompted an immediate and coordinated response from the software community, leading to rapid development of patches by Bash's lead developer, Chet Ramey, and widespread updates across various operating systems and networked devices .

Furthermore, it led to the identification of six distinct CVEs, ranging from CVE-2014-6271 to CVE-2014-7187, each highlighting various vulnerabilities in Bash's handling of code parsing and execution .

Reported Vulnerabilities

CVE-2014-6271

The original Shellshock vulnerability was based on how Bash processed environment variables and allowed attackers to execute arbitrary code on vulnerable systems .

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

In this example, the function is defined using the command env x='() { :;}; echo vulnerable'. After the actual function body, marked by { :;};, additional code is added – in this case, the command echo vulnerable. If the Bash version is vulnerable, it will output "vulnerable" and "this is a test." This means that it also executes the code after the function.

It's important to note that the second output string, "this is a test," is not part of the vulnerability and can be replaced with almost any other command. What matters is that when using bash -c, a new instance of Bash is created, which assigns the value to the environment variable x. During this initialization of x, the injected code echo vulnerable is executed.

CVE-2014-7169

The second discovered vulnerability, also known as Aftershock, allowed for the execution of injected code in a similar manner, even after applying the initial patch .

env x=’() {( a ) = >\’ bash -c "echo date"; cat echo

In this case, an attempt is made to assign a function to the variable x as well. The key difference from the previous vulnerability is that the function is designed to generate a syntax error while still executing code. The use of the escape character \ cancels out the following quotation mark, preventing the function definition from being completed. The redirection operator > redirects output to a file specified afterward.

Despite the syntax error in the function definition's position of =, Bash continues to execute code and, as a result, creates a file named "echo" with the content of the date command output. Finally, this file is printed to the console using cat echo.

CVE-2014-7186

Another vulnerability, which didn't execute malicious code but was used to carry out denial-of-service (DoS) attacks by causing memory overflow and application crashes, or other unexpected behavior in Bash .

x=’() { true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF; }’; bash -c :

In the example above, a series of here documents are nested within the function body, but they are never closed with a delimiter. Each <<EOF opens a new document, which typically needs to be closed with the matching delimiter "EOF". Everything between these two points is considered the content of the document .

The security vulnerability arises from the missing closing delimiters, combined with the deep nesting, causing an out-of-bounds memory-access error.

CVE-2014-7187

A software crash and subsequent DoS can be caused by an off-by-one error due to a flaw in the read_token_word function found in the parse.y file within the Bash source code .

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) > test-script.sh
bash test-script.sh

When using a for loop, the output of echo commands is written to the target file test-script.sh, which is executed afterward. The resulting deeply nested loops can cause Bash to mishandle them, leading to an off-by-one error in memory access.

This can result in accessing memory outside the allocated range, potentially leading to application crashes.

CVE-2014-6277

Another security vulnerability, in contrast to the previous weaknesses, is related to uninitialized memory usage. This faulty memory access could lead to DoS or the execution of malicious code . A detailed explanation of this issue can be found in a personal blog post by Michał Zalewski.

x="() { y() { _; }; y() { _; } <<‘perl -e ’{print "A"x1000}’‘; }" bash -c :

In this command, after two empty functions y() { _; }, the << operator starts a here document. However, due to the missing delimiter string, the it is not fully terminated. As a result, the here_doc_eof pointer incorrectly points to an invalid string and remains uninitialized. Consequently, Bash could attempt to read from this uninitialized memory that has been manipulated by attackers.

This could result in unexpected behavior such as ACE or software crashes.

CVE-2014-6278

This more complex security vulnerability allowed attackers to bypass the previously published patches through redirection and parsing errors, ultimately enabling the execution of malicious code .

x=’() { _; } >_[$($())] { echo vulnerable; id; }’ bash -c :

The expression >_[$($())] uses redirection and array syntax in a way that the Bash parser does not understand. As a result, it falls into a state that it cannot correctly reset after interpreting the nested command substitution $().

Because of this, the following code block { echo vulnerable; id; } is executed without further checks.

Impact and Attack Scenarios

Attack Vectors

The discovery of the Shellshock vulnerabilities has revealed significant implications for the security of information systems. By exploiting the previously mentioned flaws, attackers gain numerous points of attack. Any service or system implementing a vulnerable version of Bash could potentially be compromised.

The following sections describe the most common attack surfaces of this vulnerability and illuminate the specific threats posed to computer systems.

Hypertext Transfer Protocol (HTTP) - via CGI scripts

The exploitation of Shellshock through HTTP via Common Gateway Interface (CGI) scripts was particularly alarming due to the prevalence of CGI in web server configurations .

Attackers could send malicious HTTP requests with environment variables containing the modified payload. Common methods for this include, for example, the Referer, Cookie, or User-Agent headers. Since CGI scripts often invoke Bash, these payloads were executed, potentially leading to remote code execution (RCE) . This simple method required no authentication, allowing unmitigated access to the server.

For this reason, web applications that use an outdated Bash version may be vulnerable to Shellshock exploits.

Secure Shell (SSH)

Systems that use SSH mechanisms like ForceCommand or AuthorizedKeysCommand posed another way to exploit the security flaw.

Attackers could make use of it by embedding malicious payload within the SSH command. When the SSH server processed the command, it invoked the Bash shell, leading to the execution of the code.

This form of attack was particularly concerning for systems where SSH is used for secure remote management, as it could bypass standard security measures and grant attackers unauthorized access.

Dynamic Host Configuration Protocol (DHCP)

Exploiting Shellshock through DHCP involved attackers setting up rogue DHCP servers. When a vulnerable system (client), using Bash to process DHCP responses, connected to this server, it would receive maliciously crafted DHCP responses. These responses included environment variables typically designed to perform ACE.

Since DHCP is used for automatically configuring network settings, this attack vector could be employed in any network environment, making it particularly dangerous in public or unsecured Wi-Fi networks.

Network Services and Daemon Scripts

Network services that process email headers, such as Mail Transfer Agents (MTAs), or other services that pass environment variables to Bash scripts, are also potential targets for Shellshock attacks. This could affect any service that handles external data within a Bash environment.

Examples of Attacks

Shellshock was exploited in various notable attacks.

Voting Server in Georgia

A security expert found evidence suggesting a hacker attack on a Georgia voting server before the 2016 and 2018 elections. This incident, potentially exploiting the Shellshock vulnerability from 2014, might have allowed attackers to gain extensive control, alter data, or install malware. The server's vulnerability was not immediately patched, and there's evidence suggesting attackers concealed their activities and erased log data, complicating the investigation.

QNAP NAS Devices

Researchers discovered a computer worm exploiting the Shellshock vulnerability to plant backdoors on network-attached storage (NAS) devices by QNAP. These backdoors bypass security mechanisms, allowing remote access. The worm spread by exploiting a CGI script in QNAP's login process, establishing backdoors, including setting up an SSH server and adding administrative users. Although QNAP released updates, many systems remained vulnerable due to patching difficulties. Similar to the Georgia voting server case, the malware self-patched the Shellshock vulnerability on infected devices to prevent further exploits.

Yahoo! Server

Cybersecurity expert Jonathan Hall discovered that romanian hackers exploited the Shellshock vulnerability to breach Yahoo! servers. They specifically targeted access points to the Yahoo! Games network, which has millions of users. The servers were vulnerable due to using an outdated version of Bash. Yahoo confirmed the incidents, stating they responded with patches and isolated some affected servers. However, at that time, there was no evidence of compromised user data.

DDoS Attacks

Within a day of Shellshock's disclosure, attackers exploited the Bash vulnerability to create a botnet named wopbot. This botnet targeted vulnerable servers, launching distributed DoS (DDoS) attacks against Akamai's content delivery network (CDN) servers and attempting to compromise the U.S. Defense Department's network, which includes about 16.7 million IP addresses. While Tiger Security experts partially shut down the botnet's control systems, the botmaster server of wopbot remains operational, continuing to spread malware.

Other Attacks

According to a report by Solutionary’s Security Engineering Research Team (SERT), the Shellshock vulnerability was still being exploited ten months after its disclosure. Despite available protections, many systems remained vulnerable. Nearly 600,000 Shellshock-related events originated from over 25,000 unique IP addresses, mostly trying to identify susceptible systems. The USA, China, Korea, the UK, Germany, and Japan were the top sources of these attacks, with educational institutions being primary targets. Most successful attacks involved downloading and executing Bash scripts, with various attackers, including known botnets, continuing to exploit the vulnerability.

Defense and Mitigation Strategies

Patches and Updates

In the course of the six vulnerabilities' discoveries, Chet Ramey released three patches named bash43-025, bash43-026, and bash43-027, primarily addressing the issues in CVE-2014-6271, CVE-2014-7169, and CVE-2014-7186, with the last one also addressing all remaining ones . The patching process itself varies depending on the operating system but typically includes the following basic steps :

• Updating repository information: To ensure that the package manager being used is up to date and includes the latest updates and security patches, an update command is executed.
  For Debian-based systems: apt-get update
  For Red Hat-based systems: yum update

• Updating Bash: To update the Bash package, the appropriate command provided for the system is used.
  For Debian-based systems: apt-get install --only-upgrade bash
  For Red Hat-based systems: yum update bash

• Verification of installation: To verify the functionality of the patch, it's essential to test the system for the security vulnerability. Depending on the specific variant of the vulnerability (see section Attack Vectors), this can be done, for example, by entering the following command:
  

  env x=’() { :;}; echo vulnerable’ bash -c "echo test"
  

  A non-vulnerable system should prevent the execution of code after a function definition and instead provide an error message.