[Bro] working with MS15-034

[Josh Liburdi]

I agree, I think double's are the way to go ... but the behavior is
odd: http://try.bro.org/#/trybro/saved/3780

It doesn't recognize the numbers as being equal.

Josh

On Thu, Apr 16, 2015 at 9:43 AM, Vlad Grigorescu <vlad at grigorescu.org> wrote:
> You can use to_double:
>
>> $ bro -e 'print to_double("987654321123456789");'
>> 9.876543e+17
>
>   --Vlad
>
> On Thu, Apr 16, 2015 at 11:19 AM, Aaron Gee-Clough <lists at g-clef.net> wrote:
>>
>>
>> True, but I was hoping to do more than just detect the magic number. I
>> was hoping to be able to say something along the lines of:
>>
>>         if (name == "RANGE" && value > 2^64 )
>>
>> My thinking here is that I don't want to play whack-a-mole with magic
>> numbers. I would like to flag any request for an offset that big as a
>> potential problem.
>>
>> aaron
>>
>> On 04/16/2015 12:11 PM, Josh Liburdi wrote:
>> >
>> > The Range header value in Bro should be a string-- if you're looking
>> > to detect a specific magic number in this value, then instead of
>> > converting the values to counts, you could match it like this by
>> > leaving that magic number as a string:
>> >
>> > if ( name == "RANGE" && "string" in value )
>> >
>> > Josh
>> >
>> > On Thu, Apr 16, 2015 at 4:33 AM, Aaron Gee-Clough <lists at g-clef.net>
>> > wrote:
>> >>
>> >> All,
>> >>
>> >> I'm working on a bro script to detect attempts for the
>> >> recently-announced IIS attack. I've hit an interesting issue: There's a
>> >> magic number that gets sent in the HTTP "RANGE" header to trigger the
>> >> vulnerability, and that number is 2^64. This is right at the edge of
>> >> what a "count" variable can hold, and it wraps around a regular "int"
>> >> variable.
>> >>
>> >> I'd like to be able to detect anyone sending any number >= 2^64 in a
>> >> RANGE header, but I don't see how to do that with count variables in
>> >> bro. Does anyone have any ideas of how I can do this? Right now I'm
>> >> looking at doing something truly nasty, like comparing the length of
>> >> the
>> >> strings holding the Range values. I'm *really* not happy with that,
>> >> though...it feels like a really ugly hack.
>> >>
>> >> aaron
>> >> _______________________________________________
>> >> 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
>
>