Count Upon Security

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.