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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | [Snort-sigs] Bleedingsnort.com Daily Update, bleeding |
|---|---|
| Next by Date: | [Snort-sigs] False +ves for 2657 EXPLOIT SSLv2 Client_Hello with pad Challenge Length overflow attempt, Russell Fulton |
| Previous by Thread: | Re: [Snort-sigs] The rule 1054 fires up false positives!, Matt Kettler |
| Next by Thread: | [Snort-sigs] False Negative Submission, Matthew K. Lee |
| Indexes: | [Date] [Thread] [Top] [All Lists] |