Re: [Emerging-Sigs] distance:0; in conjunction with uricontent/content pair.

[Will Metcalf <william.metcalf () gmail com>]

BTW I don't want there to be a mis-understanding here, this isn't
meant to be an attack on SF or Snort.  One of the goals of Suricata is
to have support for snort rule language, so essentially given a set of
pcaps I'm creating rules to see how undocumented content/modifier
combinations interact with each other.  I will share the results when
I'm finished.  Maybe the output will be useful to rule writers ;-)...

Regards,

Will


On Mon, Mar 15, 2010 at 12:41 PM, Matt Jonkman <jonkman () jonkmans com> wrote:
> I agree, the official line is that distance/within do not work relative
> to uri because the uri buffer is normalized, and thus may be a different
> length that what it was in the packet. So then where should the engine
> mark distance from, the end of the pre-normalized stream, or the end of
> where it is after normalization?
>
> Personally, I think it ought to automatically count a range from the end
> of both, giving the widest latitude for a match and avoiding evasion.
>
> But (please correct me if wrong joel) the official line is that
> distance/within is ignored if a uri is involved, no? So these sigs ought
> to work, just won't have that modifier, thus potential for false positives?
>
> I'm changing these sigs anyway, it's incorrect form and isn't really
> important to the matches.
>
> So I was talking to Will offline, I think I understand what he's finding
> in testing here. I'll try to summarize:
>
> 1. If a URI is encoded and requires normalization then snort fails to
> match any other content match modified with a distance/within modifier
> relative to that uricontent.
>
> 2. Is a URI is plain ascii and does not require normalization then
> distance/within works even though there is a uricontent related to a
> content and will match.
>
> So we have the preprocessor designed to prevent evasion introducing an
> evasion technique. :)   (sorry, that's just funny... in a
> vulnerability/evil kinda way)
>
> So I don't expect this is how snort is intended to work. What is the
> real intent here? Should we not use distance/within against a uricontent?
>
> Thanks!!
>
> Matt
>
> On 3/15/10 1:17 PM, Will Metcalf wrote:
> > I don't think that distance:0; should be used in rules where the
> > previous match is uricontent.  This works but only if the uricontent
> > doesn't have to be decoded. If the uri is encoded with say unicode
> > these sigs will fail to fire completely.  I realize that this is
> > automated code as these are malware sigs but I don't think the
> > performance payoff setting the doe_ptr is worth the potential evasion.
> >  Maybe a better way to say this would be, I think these sigs should be
> > changed to remove the distance:0; as a new rule writer may use them as
> > an example and his sig may be bypassed by some piece of malware that
> > occasionally decides to encode it's uri somehow.  VRT does this as
> > well with their spyware rules... Opinions?
> >
> > Regards,
> >
> > Will
> >
> > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN
> > Egspy Infection Report via HTTP"; flow:established,to_server;
> > uricontent:"/keylogkontrol/"; content:"|0d 0a|User-Agent|3a|
> > Mozilla/3.0 (compatible|3b| Indy Library)"; distance:0;
> > classtype:trojan-activity;
> > reference:url,research.sunbelt-software.com/threatdisplay.aspx?name=EgySpy&threatid=48410;
> > reference:url,doc.emergingthreats.net/2008047;
> > reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Egyspy;
> > sid:2008047; rev:2;)
> >
> > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN
> > Generic Spambot (often Tibs) Post-Infection Checkin";
> > flow:established,to_server; uricontent:"/access.php?"; nocase;
> > uricontent:"w="; nocase; uricontent:"&a="; nocase; content:"|0d
> > 0a|Host\: "; distance:0; pcre:"/Host\: \d+\.\d+\.\d+\.\d+\x0d\x0a/";
> > content:"|0d 0a|Cache-Control\: no-cache|0d 0a|"; content:!"|0d
> > 0a|User-Agent\: "; classtype:trojan-activity;
> > reference:url,doc.emergingthreats.net/2008174;
> > reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Tibs;
> > sid:2008174; rev:2;)
> >
> > _______________________________________________
> > Emerging-sigs mailing list
> > Emerging-sigs () emergingthreats net
> > http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> >
> > Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> > http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html
>
> --
>
> ----------------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Open Information Security Foundation (OISF)
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> http://www.openinfosecfoundation.org
> ----------------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel