[Snort-sigs] Interesting false positive for HTTP_Connect

Matthew Jonkman matt at ...2436...
Sat Jul 17 23:26:01 EDT 2004


You're certainly right about any pass rules. They can cause undesired 
results.

I've put the new rule up on bleeding. Lets see how it shakes out. Thanks 
for your effort on it Jason.

If anyone gets falses on this version please let us all know.

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