|
osdir.com mailing list archive |
|
Subject: Re: New adobe vulnerability - msg#00210List: security.ids.snort.sigsFrank Knobbe <frank@xxxxxxxxx> wrote > On Thu, 2004-08-19 at 15:17, Joseph Gama wrote: > > My rule was posted the same day as this posting and it > > has no false positives: > >=20 > > [...]pcre:"/[\w]+\.pdf%00[\w-_\.!~*'"\(\)]+HTTP\/1\.1/Bi";[...] > > Does your rule actually fire on the exploit? > > If so, question to nnposter, does his rule (using |00|) fire on the > exploit? Yes > I understand that the preprocessor will convert %00 into |00| within > matches using uricontent. But if Josephs rules works too, does that mean > that anything that is matched using pcre has not been run through > http_inspect? Yes. Only uricontent is preprocessed with http_inspect. content and pcre are not. > How does the matching occur? All munged by http_inspect first, then > matched by uricontent and pcre? Or first pcre, then munging by > http_inspect, then uricontent? The latter, see above. > Who is right and will alert on the exploit (tested)? pcre using %00 or > uricontent using |00| or both? I have tested mine. I have not tested Joseph's variant but his approach of matching on %00 with pcre will work in general as well. (Although I can see several ways how to craft false negatives to get around this particular PCRE.) > Regards, > Frank > > > BTW: I try to stay away from pcre due to the performance impact. Is that > fear unfounded these days (read, with newer versions of Snort)? IMHO, having a rule without good "content" or "uricontent" is expensive. In other words, PCRE is great but I would always try to use at least one content or uricontent clause as a pre-match. Cheers, nnposter ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 Thread at a glance:
Previous Message by Date: click to view message previewRe: DHCP AttackOn Thu, 2004-08-19 at 14:30, Nick Hatch wrote: > Where do you have your Snort sensor for this rule? There are quite a few > tools to find Rogue DHCP servers, but our problem has been finding a > graceful solution to mitigate the amount of hardware needed to watch 30 > subnets. How about setting up a script on a box whose segment is monitored by Snort. That script can fire a dummy "whos-my-dhcp-server-daddy" broadcast query packet to 255.255.255.255 port 67 and see what machines respond (server:67 to client:68... iirc). That way you don't need to monitor each collision domain, only your broadcast domains. In essence, you're baiting the rogue DHCP server with fake DHCP queries :) Regards, Frank signature.asc Description: This is a digitally signed message part Next Message by Date: click to view message previewBleedingSnort rules hits informationHi, recently I posted some rules for detecting XSS and SQL Injection attempts against PHP Nuke, and those rules were added to BleedingEdge. Now, I would like to know if I will get any feedback about if those were useful or not (FPs, FNs, correct detections, etc). Is there any place where information about this is published? Thank you! -- Federico Petronio petrus@xxxxxxxxxxxxx ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 Previous Message by Thread: click to view message previewRe: New adobe vulnerabilityOn Thu, 2004-08-19 at 15:17, Joseph Gama wrote: > My rule was posted the same day as this posting and it > has no false positives: > > [...]pcre:"/[\w]+\.pdf%00[\w-_\.!~*'"\(\)]+HTTP\/1\.1/Bi";[...] Does your rule actually fire on the exploit? If so, question to nnposter, does his rule (using |00|) fire on the exploit? I understand that the preprocessor will convert %00 into |00| within matches using uricontent. But if Josephs rules works too, does that mean that anything that is matched using pcre has not been run through http_inspect? How does the matching occur? All munged by http_inspect first, then matched by uricontent and pcre? Or first pcre, then munging by http_inspect, then uricontent? Who is right and will alert on the exploit (tested)? pcre using %00 or uricontent using |00| or both? Regards, Frank BTW: I try to stay away from pcre due to the performance impact. Is that fear unfounded these days (read, with newer versions of Snort)? signature.asc Description: This is a digitally signed message part Next Message by Thread: click to view message previewRe: New adobe vulnerabilityOn Fri, 2004-08-20 at 10:37, nnposter@xxxxxxxxxxxxxxxxxxxxx wrote: > Yes. Only uricontent is preprocessed with http_inspect. content and pcre > are not. Okay, so I would assume that all HTTP related rules should be crafted with [uri]content instead of pcre then..... to take advantage of the HTTP normalization by the preprocessor. In other words, pcre based rules would be easy to evade by various HTTP encodings, right? Cheers, Frank signature.asc Description: This is a digitally signed message part Loading Comments...
|
|
