Detecting, Exploiting, and Patching the Shellshock Bug
Overview
Wednesday, CVE-2014-6271, now called “shellshock” or the “bash bug”, was published. The following description was provided:
“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka ShellShock.”
It was given a CVSS score of 10.0, the highest possible.
Detecting
Luckily, if you have access to the remote system, manual validation is very easy. Simply paste the following code into a terminal and execute.
1
| |
If the output contains the string “vulnerable” then your version of bash is affected.
To test remotely, follow the exploitation steps below, omitting the reverse shell and setting the command in the request headers to something like “curl http://mysite.com/something.txt” and watch your logs. If you see the host connect and access that file, it is vulnerable.
Exploiting
Exploiting this bug is a little bit more fun. At the time I created this method, there were no working tools to test. I had only seen someone online’s log and tried to emulate that to the best of my ability.
The first step is to hop on your VPS and create a file with a simple bash reverse shell in it and throw that in your web root.
1
| |
Once that is set up, turn on Apache and start a netcat listener on the port you specified in the reverse shell file.
1 2 | |
Now that the infrastructure is set up, find a vulnerable host. This should be a web server with a vulnerable CGI file on it. Once you’ve identified it, fire up Burp Suite.
Start the proxy and configure your browser to use it. Navigate to the site/file that you want to test, intercept the request, right click and choose “Send to Spider.” Pause the Spider and go into the Spider options tab. Scroll down to the Request Headers section, click the “User-Agent” header, and then click the Edit button. Change the user agent to the following string:
1
| |
This uses wget to download your reverse shell you put on your web server and save it to the /tmp/ directory, change the file permissions to 777, and run the reverse shell. If successful, this will call back to your netcat listener. If you can get it to call back and open the shell, you’ll have a session as the user on the remote system.
NOTE: In Burp, I chose to use the Spider as I am a fan of automating as much as possible, but Intruder or Repeater work just as well.
Remediating
Remediating the issue is pretty straightforward now that most operating systems have a patch in their repositories. For instance, I patched my Kali box with a simple “apt-get update && apt-get -y dist-upgrade.” However, if you do not have the luxury of being able to do full distro upgrades, building from source is always an option and many distros are providing tutorials.
Once you’ve updated, make sure you run through the detection command mentioned above. If it responds with the following errors, your system is patched. CVE-2014-7169 notes that the original patch was incorrect, so make sure to stay on top of updates for the next week or so.
1 2 | |