--- Matt Kettler <mkettler@evi-inc.com> wrote:
At 08:44 AM 11/22/2004, Victor Meghesan wrote:
--- Matthew Watchinski <mwatchinski@sourcefire.com>
wrote:
<snip>
web-misc.rules:alert tcp $EXTERNAL_NET any ->
$HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC weblogic/tomcat .jsp view source
attempt";
flow:to_server,established; uricontent:".jsp";
nocase;
pcre:!"/^\w+\s+[^\n\s\?]*\.jsp/smi";
reference:bugtraq,2527;
classtype:web-application-attack; sid:1054; rev:7;)
Here is how it works.
<snip>
Here is what happens:
a) the GET and Referer: lines below match uricontent:
.jsp
b) the other lines match the negated regexp pcre:!...
and nothing in there (the example content I send) is a
%
c)the rule fires up with false positives!
because of a) + b) then c) happens
<snip>
Referer: http://xxx.xxx.xxx/l/l.jsp
It would seem to be happening because the PCRE will not match the
Referrer:
header like it should. This does however assume that the GET and the
Referrer: are in separate packets from a stream4 perspective. Since
there's
a lot of junk inbetween, and stream4's reassembly is pretty limited in
size, this is very possible.
It won't ever match any Referrer: header at all, because the inclusion of
a
: breaks the \w+\s+ sequence at the start, and the prce fails to match.
Thus this rule can easily false-fire on a http request with a Referrer:
that's a .jsp.
If uricontent matches Referer: headers, then the PCRE needs to change to
handle that.
Try this prce instead... it should fix the false match.
/^\w+\:?\s+[^\n\s\?]*\.jsp/smi
Yes, the false positives were probably generated
in that case because of the
Referrer: header line that produced a match for [1:1054:7];
the negated pcre was not matching and uricontent was matching.
Using your modified version of the initial pcre
the false positives with Referrer: were gone;
however something like this:
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?
In the meantime when using a work-around found on Google:
with a pcre
especially looking for a % as in pcre:"/^\w+\s+[^\n\s\?]*%/sm"
the false positives were gone.
And my point is: if we're looking for a % match
why use a negated pcre instead of a pcre especially looking for a %
in the first place?
Looking for a % would make much more sense than a negated regexp
in my opinion.
-- Victor
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
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
