[Snort-sigs] Interesting false positive for HTTP_Connect

Matthew Jonkman matt at ...2436...
Sun Jul 18 07:45:01 EDT 2004


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.





More information about the Snort-sigs mailing list