[Snort-sigs] Interesting false positive for HTTP_Connect

Jason security at ...704...
Sun Jul 18 09:31:14 EDT 2004


You are right lotsa hits because of the lack of a space.

Take this snippet
61 74 65 0D 0A 41 63 63 65 70 74 2D 43 68 61 72  ate..Accept-Char
73 65 74 3A 20 49 53 4F 2D 38 38 35 39 2D 31 2C  set: ISO-8859-1,
75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A 3B 71 3D  utf-8;q=0.7,*;q=
30 2E 37 0D 0A 4B 65 65 70 2D 41 6C 69 76 65 3A  0.7..Keep-Alive:
20 33 30 30 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E   300..Connection
3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A 52 65  : keep-alive..Re
66 65 72 65 72 3A 20 68 74 74 70 3A 2F 2F 77 77  ferer: http://ww
77 2E 63 6E 6E 2E 63 6F 6D 2F 32 30 30 33 2F 54  w.cnn.com/2003/T
45 43 48 2F 69 6E 74 65 72 6E 65 74 2F 30 37 2F  ECH/internet/07/
33 31 2F 69 6E 74 65 72 6E 65 74 2E 61 74 74 74  31/internet.attt
61 63 6B 2F 69 6E 64 65 78 2E 68 74 6D 6C 0D 0A  ack/index.html..
0D 0A 47 45 54 20 2F 63 6E 6E 2F 2E 65 6C 65 6D  ..GET /cnn/.elem
65 6E 74 2F 73 73 69 2F 63 73 73 2F 31 2E 30 2F  ent/ssi/css/1.0/
6D 61 69 6E 2E 63 73 73 20 48 54 54 50 2F 31 2E  main.css HTTP/1.
31 0D 0A 48 6F 73 74 3A 20 69 2E 63 6E 6E 2E 6E  1..Host: i.cnn.n
65 74 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20  et..User-Agent:
4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 28 58 31 31  Mozilla/5.0 (X11
3B 20 55 3B 20 4C 69 6E 75 78 20 69 36 38 36 3B  ; U; Linux i686;
20 65 6E 2D 55 53 3B 20 72 76 3A 31 2E 34 29 20   en-US; rv:1.4)
47 65 63 6B 6F 2F 32 30 30 33 30 37 31 34 20 44  Gecko/20030714 D
65 62 69 61 6E 2F 31 2E 34 2D 32 0D 0A 41 63 63  ebian/1.4-2..Acc
65 70 74 3A 20 74 65 78 74 2F 63 73 73 2C 2A 2F  ept: text/css,*/
2A 3B 71 3D 30 2E 31 0D 0A 41 63 63 65 70 74 2D  *;q=0.1..Accept-
45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 64  Encoding: gzip,d
65 66 6C 61 74 65 0D 0A 41 63 63 65 70 74 2D 43  eflate..Accept-C
68 61 72 73 65 74 3A 20 49 53 4F 2D 38 38 35 39  harset: ISO-8859
2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A  -1,utf-8;q=0.7,*
3B 71 3D 30 2E 37 0D 0A 4B 65 65 70 2D 41 6C 69  ;q=0.7..Keep-Ali
76 65 3A 20 33 30 30 0D 0A 43 6F 6E 6E 65 63 74  ve: 300..Connect
69 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D  ion: keep-alive.
0A 52 65 66 65 72 65 72 3A 20 68 74 74 70 3A 2F  .Referer: http:/
2F 77 77 77 2E 63 6E 6E 2E 63 6F 6D 2F 32 30 30  /www.cnn.com/200
33 2F 54 45 43 48 2F 69 6E 74 65 72 6E 65 74 2F  3/TECH/internet/
30 37 2F 33 31 2F 69 6E 74 65 72 6E 65 74 2E 61  07/31/internet.a
74 74 74 61 63 6B 2F 69 6E 64 65 78 2E 68 74 6D  tttack/index.htm
6C 0D 0A 0D 0A                                   l....

so it finds connect in connection, finds |0d 0a| shortly thereafter, 
walks back looking for HTTP/1. but keeps going past where I want and 
finds HTTP/1. then walks back to find !:80 or !:443.

Adding a space to the rule in the CONNECT so it looks like this changes 
results a lot, I need to look and see if a within can be applied to a 
negative distance to prevent walking past the newline too.

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:2000000;\
rev:3; )



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