Shellshock demo set-up and POC

I’m not sure if everyone has been made aware of this, but a BASH vulnerability has been discovered… /sarcasm

OK, seriously, as everyone has heard by now, “Shellshock” is the new hot topic right now. Since I am one who learns by doing, I decided to give it a go, and see exactly how it works. My first instinct was to see how it works against the SSH protocol (CGI write up is coming soon). Now that I see what it actually is, I see that it would take an extraordinary set of circumstances for it to be a viable method of gaining entry (at least through SSH), but should those circumstances be present in your environment, it could be devastating (So make sure you patch everything up!).

Obviously this is a controlled environment that I set up in my home lab to see what it would take from start to finish.

So first things first, the set up. I am using an Ubuntu server VM, 12.04 LTS that has not been patched. This was a vanilla install with only SSH and (traditional) NC installed. This gave me a vulnerable version of BASH to begin my testing with.


Next step, is to make a user that has basically no privileges on the machine, but still accessible through SSH. Now, this could be set up for a variety of reasons. The administrator may want a certain user to only have access to a single command, or perhaps its a back-up server to where, as a security measure, the user can only ssh in to ensure their files are backed up, but requires the administrator to actually log in and retrieve them.

So we create a user (called demo) and set a home directory for this user.


Next we create an .ssh folder in the demo home directory and create an “authorized_keys” file to it, as well as chown the directory to the demo user. Next, add your Kali public key to the authorized_keys file.



Now we test to ensure the key works, and does not prompt for a password.


Finally, we add the finishing touch, that makes this an exploit, and not just another stolen key. We make it to where the demo user does not have log-in capabilities when using this key. This is done by adding “command=”whatever command you want” in the key file. For this example, it will simply say “Access Denied” through an echo command. Simply open the “authorized_keys” file with your text editor of choice and add the syntax as shown:


Now, when an SSH connection is made to this machine using that key, login is not allowed, and the user simply gets an access denied message, even if other commands are put into the ssh connection.


Here is where the Shellshock bug finally comes into play. As was demonstrated, other commands were not allowed when using this user name/key combination. But when we add the following syntax to the ssh command:

'() { :;}; your_command'

The command gets executed.


As you can imagine, this could lead to a complete server compromise, should this key be stolen from a user.

As an example it would viable for an attacker to use this method to gain a reverse shell, therefore making a seemingly harmless user on a server become a point of entry, giving them full shell access!


Leads to:


So, although the circumstances would need to be a perfect storm, should that perfect storm exist on your network, you have a major vulnerability on your hands!

Patch your machines people!


6 thoughts on “Shellshock demo set-up and POC

Leave a Reply

Your email address will not be published. Required fields are marked *