[Bro] CVE-2014-6271/ detection script

[Jason Batchelor]

Looks like Seth put one up:

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

'exploit.pcap'

On Thu, Sep 25, 2014 at 1:52 PM, Mike Sconzo <sconzo at visiblerisk.com> wrote:

> Anybody have a pcap (they're willing to share) to verify these scripts on?
>
> Thanks!
>
> On Thu, Sep 25, 2014 at 12: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
>
>
>
> --
> cat ~/.bash_history > documentation.txt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20140925/89c93086/attachment.html