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

Matt Jonkman jonkman at ...1461...
Mon Mar 15 13:41:50 EDT 2010

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?



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 at ...2992...
> 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

PGP: http://www.jonkmans.com/mattjonkman.asc

More information about the Snort-devel mailing list