[Emerging-Sigs] FP on 2011031?

Weir, Jason jason.weir at nhrs.org
Thu Oct 7 16:25:02 EDT 2010


Thanks evilghost...

>On 10/07/2010 03:01 PM, Weir, Jason wrote:
>> These kinds of rules confuse me - so let me walk through it..
>> 
>> alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN 
>> HTTP GET invalid method case"; flow:established,to_server; 
>> content:"get "; depth:4; nocase; content:!"GET "; depth:4; 
>> classtype:bad-unknown; 
>> reference:url,www.w3.org/Protocols/rfc2616/rfc2616-sec9.html;
>> reference:url,doc.emergingthreats.net/2011031;
>>
reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/SCAN/SCAN_
>> Invalid_Method; sid:2011031; rev:2;)
>> 
>> So we are looking at the first 4 bytes and if it contains "get " any 
>> case but not specifically "GET " then fire.
>
>I wrote this rule (I think).  Basically, look for HTTP GET, nocase, as
the HTTP method (content:"get "; depth:4; nocase).  In doing so, ALSO
look for the negated content match of "GET ".
>
>This rule should match HTTP methods which are non-RFC compliant such as
"GeT", "get", "geT", etc.
>
>Both content matches should be depth:4 and they are not relative to
each-other.  With the new version of Snort we could use http_method for
these.

Ok - I went back and RTFM and see that content matches written this way
are not relative to each other...

>
>> Am I reading that correct? If so then why is it firing on this packet

>> or more importantly 9K times in the last 2 hours...
>
>That's pretty insane, we do have it in the enterprise here with almost
no firings.  Is http_inspect or your search-method going nuts?  The
signature has been around for quite some time, anything change on >your
end (I know, fallacy of causation)...

Yup - it looks like it's firing on all HTTP GET requests...  Only thing
I changed was testing Matt's Beta ET Pro Open ruleset - no changes to
the snort.conf.. 

How exactly would http_inspect or search-method go nuts?  This what your
referring to? Again no changes here...

config detection: search-method ac-bnfa max_queue_events 5
preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default \
    apache_whitespace no \
    ascii no \
        bare_byte no \
        chunk_length 500000 \
        flow_depth 1460 \
        directory no \
        double_decode no \
        iis_backslash no \
        iis_delimiter no \
        iis_unicode no \
        multi_slash no \
        non_strict \
        oversize_dir_length 500 \
        ports { 80 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888
9999 } \
        u_encode yes \
        non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
        webroot no

>
>> 	GET /Design/n1-members-over.gif HTTP/1.1
>> 	Accept: */*
>> 	Referer: http://www.nhrs.org/
>> 	Accept-Language: en-us
>> 	User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
>> Trident/4.0; FunWebProducts; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 
>> 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
>> 	Accept-Encoding: gzip, deflate
>> 
>> My idea is that the second content match starts at offset 5 and will 
>> almost always not be GET...  So we trigger on almost all HTTP GET 
>> requests...
>
>This rule shouldn't fire on this data.


At least I'm not crazy... But all that I checked I saw no off case http
get methods...

>
>
>> If that's the case shouldn't the rule just contain one content match 
>> like this "content:!"GET "; depth:4;"
>
>You can't have Snort rule which only contains a negated content match.


Well that makes perfect sense once you think about it...  Would
certainly fire if it saw "GeT", "get", "geT", though......  Not that you
could find it in the noise...


>
>> 
>> Ideas?
>> -J
>
>- -evilghost


_____________________________________________________________________________________________

Please visit www.nhrs.org to subscribe to NHRS email announcements and updates.


More information about the Emerging-sigs mailing list