Tag Archives: Bash Injection Vulnerability

ShellShock – Hands-On

In my previous post I gave an overview about the key events that happened during the week that GNU Bash vulnerability – Shellshock – got disclosed. In this post would like to demonstrate a hand’s on scenario that will allow one to have a better practical understanding on how someone could exploit the Shellshock vulnerability using HTTP requests to CGI scripts.

In order to better understand how this vulnerability can be exploited trough CGI scripts, below a short summary about what is CGI. CGI stands for Common Gateway Interface as formally defined in the RFC 3875. It is a gateway between the Web server and CGI scripts. You can write CGI programs in almost any programming language. The process of viewing a document on the Web starts when a Web browser sends a request to a Web server. The Web browser sends details about itself and the file it is requesting to the Web server in HTTP request headers. The Web server receives and reviews the HTTP request headers for any relevant information, such as the name of the file being requested and sends back the file with HTTP response headers. When a Web browser requests a CGI script in the cgi-bin directory from a Web server, the server knows is it is a CGI script and it executes. All the relevant data sent to the Web server from the Web browser, such as form input, plus the HTTP request headers are sent from the server to the CGI script in either environment variables or by standard input (stdin). This means the Web server makes available  all the HTTP request headers received from the Web browser to the CGI script using environment variables all of which have the HTTP_ prefix. At this states the CGI script takes over, it parses and processes all the information.  When the CGI script completes the execution, it sends the results back fo the Web server. The Web server formats the HTTP response header and returns the data to the Web browser.


Lets create a short example of a CGI script based on Perl that will pass back to the web browser the HTTP headers that were received trough the usage of CGI envronment variables. This was made on a CentOS machine running Apache has HTTP deamon.


The same example can be done in Shell scripting using BASH.


Now that we have a CGI bash script we can try out Shellshock!

The vulnerability can be easily exploited by introducing malformed HTTP headers in the request that will be processed by the CGI script as being code.  In the following scenario I have Kali Linux box and a Web Server running CentOS with Apache with mod_cgi enable.  This will be a manual attack in order to have a better practical understanding, however all this can be automated.

First we make a HTTP request to the Web Server CGI script bash.cgi using NetCat. The server answered with a HTTP 200 OK response and is respective results that were produced by the script. Next, the second HTTP request is much more interesting. As you can see we make a HTTP request to the same CGI script but now in the User-Agent field we crafted a string that will allow code execution. Because bash does not separate code from data this string will be part of environment variables. The code will be execute with the user permissions of the web server which in this case is the apache user account. In this case we just run the /usr/bin/id and as you can see the Web Server answered with the output of the id command.


So what can an attacker do?

This remote code execution attack vector is pretty serious because it allows to execute commands on the operating system, change configuration files and many other nasty stuff. The following picture demonstrate a scenario where an attacker via this attack vector can fully compromise a system.  The attacker opens 2 shell commands (attacker shell 1 and 2).


  1. Evil starts a HTTP deamon that will serve Evil stuff. It compiles a local escalation privilege exploit for Linux machines. Using Metasploit it creates a reverse shell that will connect back to the attacker on port 8080. Then it will put a NetCat listener accepting request on TCP port 8080.
  2. Then, Evil starts creating the malicious HTTP requests to the CGI script using the User-Agent field as payload for the commands. It start by downloading the local privilege escalation exploit camouflaged as JPG file to the /tmp folder which is writable by the user apache.
  3. Next it downloads the reverse shell binary.
  4. It assigns execution permissions to the reverse shell binary.
  5. It executes the reverse shell.
  6. On the NetCat listener the attacker will receive the reverse shell and will have a command line open to the system. Now he can execute the local privilge escalation exploit.
  7. Evil got root access to the system!

As you could see this was pretty easy to execute and Evil got root access into the system. Following that, Evil could retrieve the passwd and shadow file and crack the credentials accounts or he could find a way to maintain persistence and cover his tracks.

How could one increase its protection against this?

Three key recommendations : Patching , Egress traffic filtering and Hardening. By not using the latest patches and security recommendations you are exposed to this kind of scenarios. Patching is one of the most effective recommendations that someone should take. Egress filtering is extremely important nowadays, not filtering outgoing traffic to the Internet allows your internal systems to communicate with any IP address from the Internet which significantly increases the risk of downloading malicious code and be compromised. Finally, fortify your systems using the security best practices and vendor recommendations e.g. SELinux in this case would not allow Evil to initiate a socket using the apache account limiting Evil ability to download its malicious code.

The tools and tactics used are not new. However, they are relevant and used in today’s Shellshock attacks. With this kind of scenarios one can learn, practice and look behind the scenes to better know them and the impact they have.

Tagged , , , , , , ,

ShellShock – Highlights

shellshock-tweetWednesday, 24 of September, Florian Weimer from Red Hat security team publicly announced on Open Source Security Maillng list  a vulnerability in GNU Bash discovered by Stephane Chazelas. 1 hour later he released a patch  and the technical details about the vulnerability – “an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation“. Essentially a command injection vulnerability that allows remote code execution. Meanwhile some news sites were already publishing details. This situation was not altogether confortable when it was known that details were disclosed before the embargo that was putted together in order to give vendors to patch it before it went public. This vulnerability got CVE-2014-6271 with a CVSS score of 10 and low score on complexity which means its easy to exploit. It affected all Bash versions prior to 4.3. The vectors of attack as described by the US-CERT include:

  • Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn GNU Bash subshells, or on any system where the /bin/sh interface is implemented using GNU Bash.
  • Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities. This data path is vulnerable on systems where the /bin/sh interface is implemented using GNU Bash.
  • Allow arbitrary commands to run on a DHCP client machine.

From the previous described attack vectors the HTTP requests to CGI scripts were identified as the major concern.  While the news were still spreading, on the 25th of September when people were rushing to patch, Tavis Ormady proved that the patch was incomplete and the vulnerability was still exploitable. This got identified as CVE-2014-7169 with a CVSS score of 10. This got patched on Friday the 26th. Meanwhile another two vulnerabilities were discovered by Todd Sabin. Harder to pull off but still critical. They got CVE-2014-7186 and CVE-2014-7187. in the meantime Michal Zaleski who is another brilliant security researcher and works with Tavis on Google security team found two additional vulnerabilites. He gave the details privatelly in order to give time to patch. On 1st of October, Michal disclosed the details. These last two vvulnerabilities got CVE-2014-6277 and CVE-2014-6278.  The last patchs from the vendors mitigate all the 6 vulnerabilities. Below is a timeline of the key dates during this rush week.


During the rush hours of the disclosure, Robert Graham from Errata Security started to massivelly scan the internet looking for vulnerable hosts.  The results were impressive. Troy Hunt also wrote a nice summary about it. While security researchers, vendors and corporations were working together to assess and mitigate the risk of this vulnerability Evil started to show is fingers. Attacks started attempting to exploit the vulnerability. Rapid7 weaponized the exploit into Metasploit.  Due to the wide amount of attacks seen SANS raised its INFOCON level to Yellow on the 26th. Johannes Ulrich wrote a great summary about it. Among the exploitation techniques seen were automated click fraud, reverse shell attempts, all kinds of recon activity, PERL bots and others. Trend Micro released a comprehensive.technical report. FireEye wrote a great summary on the exploit techniques seen in the wild.

Tagged , , , , , , , , , , ,