PentesterLab – Shellshock

Pentesterlab is a website where you can find many vulnerable VMs in their exercises section. On the homepage it states, “Learn Web Penetration Testing: The Right Way” which I assume they mean by hands on experience. This is the best approach and this article aims to break down some of the things I learned while working on these exercises. These exercises not only provide the pre-configured ISO prepared for testing, but they also include a course to go along with it. I highly recommend reviewing the course material to get a better understanding of the topic. This particular vulnerable VM focuses on CVE-2014-6271 and its fundamental elements.

To get both the ISO and the course, click here

Even though I already knew what vulnerability existed on this VM for eductional purposes I wanted to go through the process that I would use to identify this vulnerability because not finding it on a client assessment would be quite a large oversight in my opinion.

I began my testing by running a simple nmap scan on the target with the following command:

nmap -sS -sV -O <ip address>

I find this scan to be fast and pretty informative

Nmap shellshock

I visited the website in a browser like I would on an assessment first and foremost to see if there was any usable information:

Shellshock port 80

I tend to like running Nikto on any webserver that I find running so I did that next. As you can see Nikto says pretty clearly that the web server is vulnerable to the exact CVE number that this VM is setup to be an exercise for. I did run Nessus on this machine with a Bash Shellshock test specifically but for some reason it did not find it. This is why I am an advocate of running more than one scanner on assessments to increase the chance of finding all vulnerabilities. Off course nothing is a replacement for manual testing:

Nikto Shellshock

I went in search of articles that could assist me with the exploitation of this vulnerability. I found an article that was actually written for this Pentesterlabs VM but since I may very well use it to exploit a box on an assessment I will reference it and attempt some of the techniques. This will allow me to do some manual testing and verify my findings. First thing I will do is fire up Burp Suite and navigate to the webpage:

Burpe Suite adding host to scope

One of the first things I always do is add the host to scope so that calls to other pages or outside of scope hosts will be removed. You also have to do one more step to remove any outside of scope items. Inside of Filter by request type (found by right clicking underneath Site Map) you must click Show only in-scope items:

Burpe Suite show only in-scope items

What we particularly want to focus on is the call to /cgi-bin/status which is what runs system commands and displays them back to the screen. We will send the GET request to /cgi-bin/status to repeater so we can start attempting to verify the vulnerability:

Burpe suite send to repeater

Once in in repeater we can start replacing the User-Agent with the well know shellshock string and add the commands we want to run. I used the same example from the article but further testing could be required to get the same results:

Burpe Suite cat etc-passwd

You can see that we can run the ping command and list out the /etc/passwd file. Wonderful we have verified the vulnerability!! Now I want to find a way to get shell to show the most impact. The article shows how to do this but let’s seek out other material so that we have the best understanding of the vulnerability and a few ways to demonstrate exploiting it.

After some research I found a great Github page created by Mubix with a collection of proof of concepts

From this I was able to find a Metasploit module that would enable me to consistently exploit this vulnerability:

Shellshock Metasploit

Note: When attempting to run the exploit with the default payload generic/shell_reverse_tcp the module failed. I had to change the payload to linux/x86/shell/reverse_tcp to successfully exploit the host.


In this article I was able to demonstrate how to gather information on a host , use that information to decide to run a web vulnerability scanner which identified a critical vulnerability, then manually verified that vulnerability and found a consistent way to get a reverse shell using Metasploit. From this point you could go into post exploitation or it may serve as a pivot into the network. The scope of the assessment would dictate the steps to take after successful exploitation.

Post navigation