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

Will Metcalf william.metcalf at ...2499...
Mon Mar 15 14:42:40 EDT 2010

Something to add since it may be somewhat related is that that pcre +
/U appears to work for certain modifiers such as isdataat,relative but
always fails to match when used with distance and within;

#test 37 pcre with distance modifier on next content Supported. Works
#file allworkandnoplayplain.pcap
#alert tcp any any -> any any (msg:"pcre with distance modifier";
pcre:"/AllWorkAndNoPlayMakesWillADullBoy/"; content:"HTTP";
distance:1; within:4; classtype:bad-unknown; sid:37; rev:1;)

#test 38 pcre with /U distance modifier on next content
#Fails to match always regardless of encoding
#file allworkandnoplayplain.pcap and allworkandnoplayencoded.pcap
#alert tcp any any -> any any (msg:"pcre with /U distance modifier";
pcre:"/AllWorkAndNoPlayMakesWillADullBoy/U"; content:"HTTP";
distance:1; within:4; classtype:bad-unknown; sid:38; rev:1;)

#test 106 uricontent with isdataat
#appears to work
#file allworkandnoplayplain.pcap allworkandnoplayencoded.pcap
#alert tcp any any -> any any (msg:"pcre with isdataat + relative";
isdataat:40,relative; sid:106;)

On Mon, Mar 15, 2010 at 12:52 PM, Will Metcalf
<william.metcalf at ...2499...> wrote:
> 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