I see a peculiar IPS event for "Bash Remote Code Injection (Shellshock) HTTP CGI (headers)". Although I have configured on my FireEye NX box to block this event, this alert has been bothering me for a while now. How do I ensure that my systems are protected and not affected by this vulnerability? I have made sure the systems OS are upto date and we are updated with regards to Shellshock.

  • 3
    It's unclear what you are asking. If the bash package is at an appropriate version, your systems are protected and not vulnerable to shellshock. You've also stated that the FireEye appliance is configured to block this vulnerability. What's the concern at this point? – Jesse K Feb 27 '17 at 21:02
  • I do agree Jesse, but just wanted to be sure before i treat this as false positive. – Vaibhav Feb 27 '17 at 21:58

My guess would be that this alert ist triggered by some attacker running an automated script that tries to get code execution via CGI-Application with unpatched bash.

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

As you can see from this curl snippet the User-Agent string is changed to something like this () { :; }; /bin/eject in order to trigger this vulnerability. Because the http-request contains this User-Agent string your IPS reports it as possible attack. But this does not mean that the attacker was successful with this attack,so this might just be a false-positive as well.

In order to check if your systems are vulnerable run this code in a terminal x='() { :; }; echo VULNERABLE' bash -c :

| improve this answer | |
  • I too believe that it should be a false positive, but before I confirm on anything, I wanted to be sure. I shall run the above code. Should have striked me at first. Thanks a lot Enigma. – Vaibhav Feb 27 '17 at 21:57
  • @Vaibhav False positive may not be the right phrase in this context. An IPS is intended to block attempted attacks. This is likely a real, albeit unsuccessful one (almost certainly if your OS is mainstream, supported and up to date) - so not a false positive as such.. A false positive makes it sound like youre considering disabling the alert but its always handy to have an audit trail of where expected attacks are coming from, even if they are relatively low threat automated scans – user2867314 Feb 27 '17 at 22:56

There is something else you can do: make the shell for any user used by web services something other than bash.

For most service accounts (e.g. www-run, nginx, or whatever your server runs as), you can set the shell to /sbin/nologin.

For accounts that do need an actual shell, zsh, csh, or ksh are reasonable choices (I would tend to go with zsh, but YMMV).

This was actually a situation that saltstack used to highlight their product and capabilities (see https://saltstack.com/some-salt-for-that-shellshock/).

This is of course something most, if not all, other config management tools can do

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.