[Snort-sigs] Couple sigs

Alex Kirk akirk at ...435...
Mon Sep 10 11:30:02 EDT 2012

Actually, the real issue with obfuscation is around the order of the width,
height, and style parameters. Right now, just swapping any of those around
in terms of their order within the packet evades the rule.

I had thought about doing a PCRE to validate that all three elements were
within a single tag, but that actually turns into a lot of potential
permutations fairly rapidly once you've got 3 distinct options (3! worth,
or 6 possible layouts, if my old math classes and my memory are serving me
right), which will make for a fairly expensive PCRE - especially given that
it would enter fairly frequently, since things like
"style=visibility:hidden" are somewhat common elements on any given HTML
page. Nick Randolph had an excellent idea that revolves around using
negative distance values to create a "window" of possible places for
matches to occur that actually works fairly well in testing:

(msg:"INDICATOR-OBFUSCATION hidden iframe - potential include of malicious
content"; flow:to_client, established; file_data; content:"<iframe ";
nocase; content:"width=1"; nocase; distance:0; within:50;
content:"height=1"; nocase; distance:-40; within:80;
content:"style=visibility|3a|hidden"; nocase; distance:-40; within:80;

I'd still want to verify that it's not common practice to do a hidden
iframe in this manner in the wild, but writing the rule like this is a nice
balance between specificity, non-evadability, and performance, IMHO. Yes,
there's the 2x2, or 0x0, iframes to deal with, etc., but since most of the
stuff I've ever seen in the wild is 1x1 or 0x0, then we'd just have a pair
of rules around this and be done with it.

FWIW, Nick is working on a blog post explaining the logic of using negative
distances like these for detection. Hopefully that'll be up this week.

On Mon, Sep 10, 2012 at 10:22 AM, James Lay <jlay at ...3266...>wrote:

> On 2012-09-10 07:52, Alex Kirk wrote:
> > With, that is, some tweaks to be slightly less specific. If you can
> > be
> > evaded by simply switching the order of the width and height on the
> > first one, for example, well, youre probably less than useful.
> >
> Thanks Alex.  For the hidden iframe, I'm thinking maybe something like
> the below:
> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
> (msg:"INDICATOR-COMPROMISE Hidden iframe"; flow:to_client, established;
> file_data; content:"<iframe"; content:"width="; content:"height=";
> pcre:"/=[0-1]/ms"; content:"style=visibility|3a|hidden";
> classtype:bad-unknown; sid:10000023; rev:2;)
> I was thinking a byte_test that will test to see if width= or height=
> are less than say 2, but I haven't yet figured out how to get that to
> fly, so I guess the pcre will suffice for now.  This alerts on my packet
> cap, and so far no FP's running live.  You think some within statements
> might help?  Thanks Alex.
> James
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
> Please visit http://blog.snort.org for the latest news about Snort!

Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
alex.kirk at ...435...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20120910/79a87f30/attachment.html>

More information about the Snort-sigs mailing list