I just posted a quick policy file which should look at header fields
and examine the data section for the telltale formatting of a bash
function.
I have *not* tested this extensively, so please test before deploying.
Happy to update with better regex etc...
https://github.com/set-element/misc-scripts/blob/master/header-test.bro
cheers,
scott
Hey Scott,
Playing around with it, I couldn’t get it to work via http headers with out starting with: "() { "
I unsuccessfully tried URI encoding a few other things as well, so for now I put up:
\x28\x29\x20\x7b\x20
Here’s my crack at it:
https://github.com/CriticalStack/bro-scripts/tree/master/bash-cve-2014-6271
There are going to be a lot of other exploit vectors for this- dhcp, cups maybe? I’m going to try and update mine as new POCs emerge.
Would love feedback or examples to update the regex.
Liam
Critical Stack has a version as well: https://github.com/CriticalStack/bro-scripts/tree/cve-2014-6271/bash-cve-2014-6271
Oops, somehow I missed your email when I replied. Good work guys.
The constraints based on experimenting that I just did to independently validate Liam's script:
The regexp its keying in on:
/\x28\x29\x20\x7b\x20/
"() { "
Is correct: adding/changing whitespace or other characters between the () or ) {, and removing the space after the { cause this to fail (but {\t MIGHT work, but my limited shell fu is not able to check that case).
However, does anyone know if any web servers will urldecode headers?
I took the version from Critical Stack and added the ability to whitelist certain ranges. It may be valuable if, for example, you have an external auditing service like White Hat Security conducting scans that you don’t deem actionable.
Perhaps a more broader discussion, but would it be a good idea to have a global ‘ip_whitelist’ variable in Bro (assuming it doesn’t have one)? Something that is present, and must always be defined by the end user. Just a thought, it might encourage future script writers to provision for things like this. Of course, there is an even broader philisophical discussion on whitelisting IP ranges, which is why I would suggest leaving the variable as something that needs to be defined by the end user.
FWIW,
Jason
bash-cve-2014-6271.bro (1.76 KB)
Hey Jason,
I added support for ignoring subnets of subnets. Pulls accepted- I am kind of surprised there aren’t POCs floating around for DHCP yet and other vectors… or maybe they are 
!
Liam
I know not all exploits of this vulnerability need to include a reverse shell, but it may be useful to monitor for outbound connections to an IP which previously made HTTP requests with headers matching this pattern.
-AK
Here’s another advanced detector from @Broala_:
https://github.com/broala/bro-shellshock
Nice work Seth.
Liam
Anybody have a pcap (they're willing to share) to verify these scripts on?
Thanks!
@Broala_ has one posted in their repo.
DHCP POC is out:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Add it to the list.
Liam
We used to do just that on one of our clusters. Sadly, it did not bear the fruit we hoped… coupled with an attempt at this exploit, it would certainly yield better results. I think you’ll find that most attackers working on this are just trying to build a set of vulnerable servers for “phase 2…” 95% of the attempts we’ve seen so far are tying to use icmp as a callback…
Chris
Awesome, thanks!
Nice, Seth 
Chris
i've got that working under Linux at least, it doesnt' work on my mac, but it may be I'm not doing quite the right thing in the DHCP server.