[Snort-sigs] sid: 1113 - FPs

Jon warchild at ...288...
Fri Feb 28 21:12:07 EST 2003


On Fri, Feb 28, 2003 at 02:52:11PM -0600, Paul Schmehl wrote:

> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC
> http directory traversal"; flow:to_server,established; content: "../";
> reference:arachnids,297; classtype:attempted-recon; sid:1113;  rev:4;)
> 
> content: "../" will trigger on any webpage that uses relative paths to
> reference files in Unix directories.  We have tons of pages that do
> this, so we get many alerts.  However, the Arachnids description is very
> specific.  
> 
> "Contents: "../"  The packet offset is zero, meaning that we start
> looking for this content string in the start of the packet data. This is
> a case sensitive search."
> 
> The request must come with a GET in front of it in order to exploit the
> vulnerability.  In fact the packet trace that Arachnids shows to explain
> the exploit shows that clearly:
> 
> 07/08-12:29:21.103460 attacker:1737 -> target:80
> TCP TTL:64 TOS:0x10 ID:48175  DF
> *****PA* Seq: 0x8CDE2D5B   Ack: 0xD24163C   Win: 0x7FB8
> TCP Options => NOP NOP TS: 152351356 190236 
> 47 45 54 20 2F 63 67 69 2D 62 69 6E 2F 66 6F 6F  GET /cgi-bin/foo
> 62 61 72 2E 70 6C 3F 2F 62 6F 72 69 6E 67 2F 2E  bar.pl?/boring/.
> 2E 2F 2E 2E 2F 2E 2E 2F 65 74 63 2F 70 61 73 73  ./../../etc/pass
> 77 64 20 48 54 54 50 2F 31 2E 30 0A              wd HTTP/1.0.
> 
> It seems that this rule could be improved by using 
> 
> uricontent: "../"; depth: 512;
> 
> or
> 
> content: "GET /cgi-bin/"; nocase; offset: "0"; content: "../"; within:
> 50;

This probably would help reduce some false positives, but keep in mind what
you'll leave out:

* all requests outside of /cgi-bin/ (very common, although a bad practice)
* requests longer than 50 which isn't all that much.
* any packets that don't start with GET (i.e., HEAD, POST, etc)
* traffic that does start with GET, but the actual bad stuff comes in
  another packet

> or something similar, to eliminate FPs from the body of an HTML
> document.

I actually though uricontent would be useful here, but that wouldn't catch
cases where the bad content isn't in the url itself and is actually, say,
in the http headers that the client sends (i.e., "Cookie:
898239823982/../../../etc/passwd").

I took a bit of a compromise between missing attacks and being overwhelmed
with false positives by changing "../" to "../../" or even "../../../".
In my experience I've found that some of the rules are just too noisy in
their default state, but oftentimes there isn't a very clean way to reduce
false positives for everybody and I end up making site-specific changes.
Especially for .edu environments where the traffic covers the entire
spectrum of all the really odd ports/protocols/services that most corporate
environments never see, site specific configs are a way of life.
 
> Here's a payload that shows a FP:
> 290 : 30 22 3E 3C 74 72 3E 3C 74 64 20 61 6C 69 67 6E   0"><tr><td align
> 2a0 : 3D 22 63 65 6E 74 65 72 22 20 63 6F 6C 73 70 61   ="center" colspa
> 2b0 : 6E 3D 22 32 22 20 62 67 63 6F 6C 6F 72 3D 22 23   n="2" bgcolor="#
> 2c0 : 30 30 30 30 30 30 22 3E 0A 3C 66 6F 6E 74 20 73   000000">.<font s
> 2d0 : 69 7A 65 3D 22 36 22 20 66 61 63 65 3D 22 41 72   ize="6" face="Ar
> 2e0 : 69 61 6C 22 3E 3C 62 3E 3C 69 6D 67 20 73 72 63   ial"><b><img src
> 2f0 : 3D 22 2E 2E 2F 2E 2E 2F 70 69 63 73 2F 6D 6C 6F   ="../../pics/mlo
> 300 : 67 6F 2E 6A 70 67 22 20 61 6C 69 67 6E 3D 22 6C   go.jpg" align="l
> 310 : 65 66 74 22 20 68 73 70 61 63 65 3D 22 30 22 20   eft" hspace="0" 
> 320 : 77 69 64 74 68 3D 22 38 35 22 20 68 65 69 67 68   width="85" heigh
> 330 : 74 3D 22 38 35 22 3E 3C 2F 62 3E 3C 2F 66 6F 6E   t="85"></b></fo

*nod*.  If we could get all web designers to not use relative paths, this
would not be an issue.  The fact of the matter, as you pointed out, is that
this type of thing happens alot.
 
> Am I starting to drive anyone nuts with this stuff?  I hope not.  I'm
> trying to contribute to improving the rules so they're more effective
> for everyone.  I just happen to have a *lot* of traffic to extract data
> from. :-)

IMO, between discussion on this list and actually tweaking your rules
locally, you can sometimes get your rulesets to a better state. 

-jon




More information about the Snort-sigs mailing list