[Snort-sigs] Interesting false positive for HTTP_Connect

Jason security at ...704...
Sun Jul 18 10:34:00 EDT 2004


So I should not do rules after 6pm, not on weekends, and only when I 
have the time to test them, apologies to anyone that got inundated with 
crap alerts.

Here is an updated version that fixes a problem with the alignment of 
HTTP/1. and adds within to the negative tests. I did not see any false 
positives across a few gigs of traffic and it fires when I hit a proxy 
connecting to a non standard web port. I also did not put in flow which 
is just plain stupid.

Remaining Thoughts

I still see some potential evasion cases that could be had depending on 
padding however I think this rule does what was initially desired. I do 
not think pipelined requests are an issue with proxies but a keep-alive 
that pushes past the boundaries might cause an evasion.

It could be collapsed using pcre to catch both ports with one check. I 
think that it illustrates well some different behaviors of detection the 
way it is so I chose to leave it alone.

It could also have the within:1024 removed since the first 0d 0a should 
be at the end of the request but I do not have time to test it further 
today.

alert tcp any any -> any any (msg:"whaddya doing here"; \
content:"CONNECT "; nocase:; \
content:"|0d 0a|"; distance:0; within:1024; \
content:"HTTP/1."; distance:-10; within:8; nocase:; \
content:!"\:80"; distance:-11; within:4; \
content:"CONNECT "; nocase:; \
content:"|0d 0a|"; distance:0; within:1024; \
content:"HTTP/1."; distance:-10; within:8; nocase:; \
content:!"\:443"; distance:-12; within:5; \
flow:to_server,established; sid:2001000; rev:2; )


Matthew Jonkman wrote:

> THe new version here is actually hitting more falses for me on normal 
> http requests not going through a proxy.
> 
> I've disabled all the http_connect rules in the bleedingsnort set, 
> although they're still there. If anyone has sone time to tweak one out 
> please let us know what you come up with.
> 
> Thanks
> 
> Matt
> 
> Jason wrote:
> 
>> I was curious so I took a look a the rules. IMHO these are extremely 
>> problematic for any person running them, the pass rules have the 
>> effect of allowing arbitrary traffic to be ignored. For example, rule 
>> 2000003, rev 2 should fire on a request of
>>
>> http://someserver.com/msadcs.dll?exploit=some_byte_code&parm=content-type:&CONNECT=443 
>>
>>
>> unfortunately this attack will be successful and evade anything 
>> running these rules. _Publishing any pass rule_ is ultimately very 
>> dangerous. Extreme caution should be used. Answer to the real question 
>> below.
>>
>> -- relevant rules for above case --
>> pass tcp any any -> any any ( msg:"BLEEDING-EDGE HTTP CONNECT Tunnel"; 
>> content:"CONNECT "; nocase; content:"80"; content:" HTTP/1."; nocase; 
>> classtype:misc-activity; sid:2000549; rev:1;)
>>
>> pass tcp any any -> any any ( msg:"BLEEDING-EDGE HTTP CONNECT Tunnel"; 
>> content:"CONNECT "; nocase; content:"443"; content:" HTTP/1."; nocase; 
>> classtype:misc-activity; sid:2000550; rev:1;)
>>
>> alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS 
>> (msg:"BLEEDING-EDGE WEB-IIS MDAC Content-Type overflow attempt"; 
>> flow:to_server,established; uricontent:"/msadcs.dll"; 
>> content:"Content-Type\:"; nocase; content:!"|0A|"; within:50; 
>> reference:cve,CAN-2002-1142; 
>> reference:url,www.foundstone.com/knowledge/randd-advisories-display.html?id=337;classtype:web-application-attack; 
>> sid:2000003; rev:2;)
>> -- end relevant rules --
>>
>>
>> The problem is that the the HTTP/1. is not anchored appropriately. The 
>> rules are also redundant and trivially evaded because of the negated 
>> match. The rules should use a distance:0 and a reasonable within to 
>> find the proper place and eliminate the port designation immediately 
>> following the target. Given the spec, you should be able to find the 
>> CONNECT then a : then a HTTP/1.
>>
>> The problem is that the request could look like this
>>
>> CONNECT http://someplace.com:443 HTTP/1.1
>>
>> or it could look like this
>>
>> CONNECT 1.2.3.4:443 HTTP/1.0
>>
>> so we have an extra colon, this can be accounted for in a single rule 
>> by walking backwards.
>>
>> -- orig rules --
>> alert tcp any any -> any any ( msg:"BLEEDING-EDGE HTTP CONNECT 
>> Tunnel"; content:"CONNECT "; nocase; content:!"80"; content:" 
>> HTTP/1."; nocase; classtype:misc-activity; sid:2000547; rev:3; )
>>
>>
>> alert tcp any any -> any any ( msg:"BLEEDING-EDGE HTTP CONNECT 
>> Tunnel"; content:"CONNECT "; nocase; content:!"443"; content:" 
>> HTTP/1."; nocase; classtype:misc-activity; sid:2000548; rev:3; )
>> -- end orig rules --
>>
>> I believe these should work for what you want, I do not have any 
>> systems to test against but if you have some pcaps of different use 
>> cases I would be happy to play with them tonight.
>>
>> -- new rule --
>> alert tcp any any -> any any ( msg:"whaddya doing here"; 
>> content:"CONNECT"; nocase; content:"|0d 0a|"; distance:0; within:1024;\
>> content:"HTTP/1."; distance:-9; nocase; content:!"\:80"; distance:-11;\
>> content:"CONNECT"; nocase; content:"|0d 0a|"; distance:0; within:1024;\
>> content:"HTTP/1."; distance:-9; nocase; content:!"\:443"; distance:-12;\
>> sid:2001000; rev:1;)
>> -- end new rule --
>>
>> I would need to play with different proxy servers to know if arbitrary 
>> padding with spaces or tabs would be accepted to eliminate other 
>> evasion cases however this rule should do what you are looking for and 
>> you can depreciate the other 4. This rule will also alert on long 
>> requests greater than 1024 chars, if this is a problem you can simply 
>> remove within statement since the first newline should be at the end 
>> of the complete request so it should have little impact on detection. 
>> I personally would want to see long requests over 1024 chars on my 
>> small net.
>>
>> Jason.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 





More information about the Snort-sigs mailing list