Make Shellshock pattern more generic. Detect ShellShock attacks on all HTTP status code responses.

[iasdeoupxe]

The text pattern could be everything like e.g.:

192.168.2.100 - - [02/Nov/2015:01:35:55 +0100] "GET /cgi-bin/test.sh HTTP/1.1" 200 292 "-" "() { something:; };/usr/bin/perl ..."

or:

192.168.2.100 - - [02/Nov/2015:01:35:55 +0100] "GET /cgi-bin/test.sh HTTP/1.1" 200 292 "-" "() { something; };/usr/bin/perl ..."

This change should catch more of these variants.

[iasdeoupxe]

In 17972c6 i have also updated the expected status code as a page might also redirect all requests to e.g. a login page or similar. This is covered already by rule 31108 so only the comment had to be updated.

[iasdeoupxe]

6b28982 updated the rules to detect the ShellShock attacks on 50x status codes (e.g. 503 Service Unavailable) as well. A service might be currently unavailable (e.g. maintenance works) and alert should be thrown in this case.

[iasdeoupxe]

I'm also wondering if we shouldn't just use <if_sid>31100</if_sid> like in all other web vuln alters because the ShellShock attack is always happening independent from the returned HTTP status code.

Edit: Did this in 7b7e0ca

[Lopuiz]

Hello @iasdeoupxe

Thank you so much for your contribution.
This PR will stay in the 3.11 project because of 3.10 project is just closed.
we will review it as soon as possible.

Regards,
Eva

[iasdeoupxe]

@Lopuiz Any updates on a review? Three months for such a minor change is a quite long time frame 😢

[chemamartinez]

Hi @iasdeoupxe,

Sorry for the late reviews of your contributions. They are really appreciated as always.

We always try to attend the opened issues and pull requests from the users as soon as possible, but, unfortunately our resources are limited. We are working hard to decrease our response timeframe as well.

I hope you understand it, and thank you again. Don't hesitate to ping us whether this situation happens again.

Best regards,
Chema.

[k3an3]

Is this really necessary? Seeing a shellshock attempt log event says nothing about whether it was successful. I have Wazuh running on public-facing servers, and naturally there are several attempts by bots every day, and the email notifications are now going crazy. In my case, the response codes seem to be 301s (which a commit here added recently).

I realize that I can turn this off iln my instance, but I am wondering if an exploit attempt should really be worthy of a level 15 alert when there is no indication of success. Else, it's going to create a lot of false positives on production machines.

[Lopuiz]

Hello @k3an3

We are solving it.
Apologies the inconvenient it caused.

Best regards,
Eva