When news of Shellshock first broke, the main vector of attack was any application running on an Apache server via CGI. I don’t run any Apache servers anymore, and if I did I probably wouldn’t be running them with CGI (just not my preference). However, I wanted to try this bug out and I didn’t want to do so in a malicious manner; I simply wanted to see what it did.
Without further ado, let’s hack ourselves!
First we’ll go create an EC2 instance on AWS. My preference is to use Ubuntu because I know it best and I’m able to find solutions to issues I encounter very quickly.
After our instance is up and running we’ll SSH into it and check if the default version of Bash is vulnerable.
Oh heck yeah, it totally is.
(Note: I’m using an old AWS image I made a few months ago. I believe Amazon patched bash on all their default images. If Bash is already patched on your machine, my next suggestion is to find a Vagrant image that isn’t patched yet. If you can’t, leave a comment below. I can post a tutorial on how to compile an old, vulnerable version of Bash and replace the patched one on your box; for science!)
Ok next step: Installing Apache and configuring it to use CGI.
That was easy. We need to tell Apache when to use CGI. We’ll do that by adding the following somewhere in the config of a site in our enabled virtual hosts folder (/etc/apache2/sites-enabled; in our case the exact file is /etc/apache2/sites-enabled/000-default.conf):
The complete Apache configuration file for the virtual host we’ll be using looks like this:
Add a file called poc.cgi to /usr/lib/cgi-bin with the following contents:
Note: The contents of this file can be anything, as can the filename. In our case the file just needs to exist. I chose to copy the Bash script above from https://www.invisiblethreat.ca/2014/09/cve-2014-6271/ because it’s an easy way to check that apache is configured correctly.
Additional Note: You may need to change the permissions of this file and directory. If you get a 403 error, try sudo chmod 755 -R /usr/lib/cgi-bin.
Now let’s restart Apache.
If everything went according to plan, we should be able to run this script via CGI and have the result returned to us. Let’s see if that works:
Awesome! Now that everything is set up, let’s exploit ourselves.
Great success! We were successfully able to run an arbitrary code execution exploit on a remote machine (that we own).