[Emerging-Sigs] cansecwest pdf problem???

Serinity Wiggins s3rinity at hotmail.com
Fri Oct 1 13:22:52 EDT 2010


lol.  Apparently Kevin Ross does rule -- http://en.wikipedia.org/wiki/Kevin_A._Ross.
So much makes sense now.  How he has time to write snort rules as well is impressive but, 3vil Ghost, I think we need to take these rules with a grain of salt ... many of us here (not you necessarily) are amateurs/hobbyists and tend to write rules that are prone to false positives or are too constrained to the exploit (e.g. trivially bypassed ActiveX rules).  Fortunately we have a strong community and that is what it is for -- creating better rules.
As for this rule, maybe the content match on "#" and 'within:19' will apply to the most recent non-negated content match.  I don't know for sure so this is speculation but looking at the rule, this is easily bypassed by modifying case or using a different HTML encoding (e.g. Unicode).
Detecting on malicious JavaScript can always be bypassed.  Always.  The best you can do is have a next-generation JavaScript engine built into your IDS/IPS (no one does this, though) but then you open up a can of worms when it comes to performance.  Plus, you have different browsers that implement different JavaScript engines and they don't all do it the same. lol.
-S3rinity
On 09/29/2010 02:28 PM, waldo kitty wrote:
does anyone have any connections over there that can maybe shed some light on this?

This is a Kevin Ross rule, I think the best place is to start there and
ask Kevin what observed level of false positives these were submitted with.

For us, we don't see 2011528 fire often, if at all.  Kevin says 2011528
detects on name representation obfuscation in PDF files.

The PDF in question certainly matches the PCRE but I don't believe the
PDF is hostile.

%PDF matches, as does forward-slash in "/Length" at position 00000000.
SubType is not listed with-in 7 bytes.

The only thing that's odd is the negated content match used with
"!SubType"; within:7 followed by a content match on "#" within:19.  How
can a content match of within:19 be relative to a negated content match
within:7?  I'm having trouble wrapping my head around that one...

The PCRE matches "/Subtype" as position 0000060C, so the signature fires.

I don't understand the relative content matches hinged around a negated
content match.  I do think this is a malformed signature (possibly) for
what Kevin wanted/intended to detect on...  but I'll gladly be corrected.

- -evilghost 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20101001/15468946/attachment.html


More information about the Emerging-sigs mailing list