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

Will Metcalf william.metcalf at ...2499...
Mon Mar 15 13:52:25 EDT 2010


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 at ...1461...> 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 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
> http://www.emergingthreats.net
> http://www.openinfosecfoundation.org
> ----------------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>




More information about the Snort-devel mailing list