Unless you were living under the rock for the last 2 weeks or so, you probably heard about a vulnerability in Bourne Again Shell (BASH), aka “Shellshock” (who comes up with those names?!) aka “Bash bug” aka “OMG! Internet is coming to an end” aka… you get the idea :)
Working in security field, I have heard about it a lot, maybe even too much in the last couple weeks and, after it has been publicly announced, I saw lots of failed exploitation attempts hitting Internet facing servers under my jurisdiction.
I have researched the vulnerability (CVE-2014-6271 and other flavours of it) a fair bit, saw heaps of malicious traffic, but actually never seen a successful exploit (well, that’s a good thing I guess…) and never had a chance to play with it on an actual vulnerable machine.
And yet, here it comes vulnhub.com again with a tiny VM created specifically for this purpose - to get your hands dirty with this particular vulnerability. So… let’s get started, shall we?
Shock that shell
I’ll omit the recon phase and just jump straight to the essence.
We have a simple VM running a web server on port 80, the site looks like this:
Let’s look at the source. Immediatelly we see something interesting:
1 2 3 4 5 6 7 8 9 10
We have a cgi script that runs system commands and displays them on a webpage - all conditions met for our Shellshock vulnerability!
All we need to do now is to exploit the vulnerability by providing a crafted shell command in one of the HTTP headers, that then will be processed by the webserver as an environment variable and, as a result, executed on the system.
Generally, the most common HTTP headers that I saw being targeted are:
Let’s try modifying User-Agent header. I’ll be using Burp repeater as it should be the easiest to play around with and modify the request when needed.
Start up burpsuite:
And craft the HTTP request:
Note: make sure there are 2 empty lines at the end of your raw request in Burp, otherwise the request won’t work!
Hmm… no response displayed on the screen, neither in the headers (I saw some examples where echo came back in headers, I guess it’s not the case in this instance).
Let’s try some other commands:
But again, the same error message and no output displayed back. Is it even working? Let’s try to ping back our Kali.
Listening for ping:
1 2 3 4 5 6 7 8 9
Aha! So it works and we’re actually getting output displayed on the screen. How about chaining the commands then?
As expected, all works fine! As you can see, we can do quite a lot of damage here. Let’s get a shell (conviniently netcat is installed):
Waiting for reverse shell:
1 2 3 4 5 6 7 8
And we have a shell! Just like this… scary huh?
Since there was no particular goal in the challange (no flag or anything), let’s just try to get a root and do more damage (just for fun and because… I always wanted to do it :P).
1 2 3
Really? All of them? Easy, let’s spawn a root shell.
1 2 3 4 5 6
And it’s gone.
Obligatory disclaimer: DON’T TRY IT AT HOME! I take no responsibility for you wiping your (or anyone else’s) filesystem off!
Imagine if that actually happened on a production server you own, containing lots of business critical data and/or services… yeah, it was that simple (at least to get an initial shell).
Since you have seen how easy it is to compromise vulnerable servers, the next question is, how to mitigate it?
First and foremost, that’s a general advice, keep your system patched and up-to-date! As soon as a critical security patch is released, apply it! Especially on your Internet facing servers as they WILL sooner or later be scanned and heaps of exploits fired at them.
With this particular “Shellshock” vulnerability, vendors weren’t great regarding releasing a patch. It took them a while and the patch that was released actually didn’t fix the vulnerability completely (hence another 4 or so CVEs emerging shortly after the inital one).
So, what else can you do? Well, your environment set-up may come to the rescue here. Generally your Internet facing servers would be sitting behind a set of load balancers, proxies and firewalls - this may provide sufficient protection in some cases (e.g. egress firewall rules restricting outbound traffic, load balancers splitting traffic onto different servers, etc.).
If you have an IPS, deploy the rules to block malicious traffic - but as with IPSes, you may need to deal with false-positives. If you have an IDS, get a team to monitor it for alerts triggering on exploit traffic, analyse responses and potentially block abusing IP (but it’s kind of a whack-a-mole game at that point).
And of course, as a general rule of thumb, if you don’t need it - disable it! Use KSH or CSH or anything else instead (if you can).
There was (and probably still is), quite a bit of panic around this particular vulnerability, however, there must be quite a lot of conditions satisfied to successfully exploit it, therefore I don’t think it’s actually THAT easy to exploit it in the wild. Of course, there will be (and already are) instances of breaches utilising this vulnerability, but they would be quite specifically crafted for targeted environment. You probably won’t be hugely successful going around and spraying an entire Internet with the same payload and hoping for the best… Heartbleed was a lot easier in that regard, but that’s a completely different story :)