[Bro] CVE-2014-6271/ detection script

Liam Randall liam.randall at gmail.com
Thu Sep 25 11:50:01 PDT 2014


Here's another advanced detector from @Broala_:

https://github.com/broala/bro-shellshock

Nice work Seth.


Liam

On Thu, Sep 25, 2014 at 1:45 PM, anthony kasza <anthony.kasza at gmail.com>
wrote:

> 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
> On Sep 25, 2014 10:21 AM, "Jason Batchelor" <jxbatchelor at gmail.com> wrote:
>
>> 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
>>
>> On Thu, Sep 25, 2014 at 10:06 AM, Nicholas Weaver <
>> nweaver at icsi.berkeley.edu> wrote:
>>
>>>
>>> On Sep 24, 2014, at 8:18 PM, Gary Faulkner <gfaulkner.nsm at gmail.com>
>>> wrote:
>>>
>>> > Critical Stack has a version as well:
>>> >
>>> https://github.com/CriticalStack/bro-scripts/tree/cve-2014-6271/bash-cve-2014-6271
>>>
>>> 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?
>>>
>>> --
>>> Nicholas Weaver                  it is a tale, told by an idiot,
>>> nweaver at icsi.berkeley.edu                full of sound and fury,
>>> 510-666-2903                                 .signifying nothing
>>> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
>>>
>>>
>>> _______________________________________________
>>> Bro mailing list
>>> bro at bro-ids.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>
>>
>>
>> _______________________________________________
>> Bro mailing list
>> bro at bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20140925/23e39696/attachment.html 


More information about the Bro mailing list