[Snort-sigs] Interesting false positive for HTTP_Connect

Jason security at ...704...
Sat Jul 17 17:54:24 EDT 2004


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.

Matthew Jonkman wrote:

> Getting a rather unusual false pos for the http connect tunnel rule 
> Brandon Barnes sent up.
> 
> The rule is really close to being right I think, the other false 
> positives I get I expect. But here's one that I find interesting. The 
> target net is a bank, the traffic is a person hitting the non-ssl 
> portion of their website:
> 
> 000 : 47 45 54 20 2F 69 6D 67 2F 67 72 61 70 68 69 63   GET /img/graphic
> 010 : 5F 70 65 66 63 75 5F 6E 61 6D 65 2E 67 69 66 20   _xxxxx_name.gif
> 020 : 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 74   HTTP/1.1..Accept
> 030 : 3A 20 2A 2F 2A 0D 0A 52 65 66 65 72 65 72 3A 20   : */*..Referer:
> 040 : 68 74 74 70 3A 2F 2F 70 75 72 64 75 65 65 66 63 http://<bankname>
> 050 : 75 2E 63 6F 6D 2F 0D 0A 41 63 63 65 70 74 2D 4C   x.com/..Accept-L
> 060 : 61 6E 67 75 61 67 65 3A 20 65 6E 2D 75 73 0D 0A   anguage: en-us..
> 070 : 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69   User-Agent: Mozi
> 080 : 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 61 74 69   lla/4.0 (compati
> 090 : 62 6C 65 3B 20 4D 53 49 45 20 36 2E 30 3B 20 43   ble; MSIE 6.0; C
> 0a0 : 53 20 32 30 30 30 20 36 2E 30 3B 20 57 61 6C 2D   S 2000 6.0; Wal-
> 0b0 : 4D 61 72 74 20 43 6F 6E 6E 65 63 74 20 36 2E 30   Mart Connect 6.0
> 0c0 : 3B 20 57 69 6E 64 6F 77 73 20 4E 54 20 35 2E 31   ; Windows NT 5.1
> 0d0 : 3B 20 42 65 6C 6C 53 6F 75 74 68 2F 31 2E 30 2E   ; BellSouth/1.0.
> 0e0 : 30 29 0D 0A 43 6F 6F 6B 69 65 3A 20 43 46 49 44   0)..Cookie: CFID
> 0f0 : 3D 31 30 39 36 30 31 36 3B 20 43 46 54 4F 4B 45   =1096016; CFTOKE
> 100 : 4E 3D 34 38 33 39 33 36 34 33 0D 0A 48 6F 73 74   N=48393644..Host
> 110 : 3A 20 70 75 72 64 75 65 65 66 63 75 2E 63 6F 6D   : <bankname>.com
> 120 : 0D 0A 0D 0A                                       ....
> 
> 
> Looks like the user agent fields are tripping the rule. But I'm curious 
> as to what the application is that's sending the request. Maybe a 
> walmart kiosk of some sort? Or maybe they've got a custom proxy for 
> outbound traffic changing the username. Who really needs to know that 
> Bellsouth and Walmart have something to do with the request. Unless this 
> is some tracking junk bellsouth is packaging with broadband CD's or 
> something.
> 
> The point is I think someone mentioned earlier that a within statement 
> for netween the CONNECT and the http1.x would make the rule better. Have 
> you tried that in your nets Brandon? Anyone know about what the max 
> range should be between those?
> 
> matt
> 
> 
> 
> -------------------------------------------------------
> 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