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.

release_overflow

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.

useradd_demo

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.

chown_demo

authorized_keys_demo

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

no_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:

command_authorized

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.

Access_denied_ssh

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.

etc-passwd-ss

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!

rev_shell_sent

Leads to:

nc-shell

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!

-Maleus

6 thoughts on “Shellshock demo set-up and POC

Leave a Reply

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

The opinions and thoughts on this blog are those of Overflow Security members, and do not reflect those of our members employers.