Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

Re: [Snort-sigs] The rule 1054 fires up false positives!

Subject: Re: [Snort-sigs] The rule 1054 fires up false positives!
Date: Thu, 25 Nov 2004 11:30:56 -0700
"Matt Kettler" <mkettler@evi-inc.com> wrote:
At 04:43 AM 11/24/2004, Victor Meghesan wrote:
GET /l/l.jsp HTTP/1.1
Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/*
~~~~~~~: ~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Accept-Language: ro,en-us;q=0.7,en-gb;q=0.3
~~~~~~~~~~~~~~~: ~~~~~ ~~~~~~~
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: www.xxx.xxx
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: JSESSIONID=xxxgkpZN1pdq_L

still fires the rule modified with pcre:!"/^\w+\:?\s+[^\n\s\?]*\.jsp/smi".
Why? There's no % in there! is this a true or a false positive?

Yep.. the PCRE doesn't accomodate /es either.

This one should fix that, but I'd say that this PCRE is getting a bit 
over-complex:
         /^[\w\/]+\:?s+[^\n\s\?]*\.jsp/smi

Broadening the negative clause is making the rule more vulnerable to
false negatives. Consider a doctored referrer as an example.

especially looking for a % as in pcre:"/^\w+\s+[^\n\s\?]*%/sm"

Hmm.. that's not very good either. It introduces a different kind of FPs 
when some other part of the URL is escape-sequenced for valid reasons. (ie: 
a .jsp in a path with a %20 in it will trigger this)

IMHO, checking for presence of '%' in the raw URI as an *additional* test 
cannot in any way introduce *new* false positives (but it also does not 
eliminate all of the already present false positive as you have pointed
out in case of an embedded space, etc).

FWIW, I have been using a private clone of 1054, adding the '%' check, 
with a very low occurence of false positives.

Cheers,
nnposter


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>