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

Will Metcalf william.metcalf at ...2499...
Mon Mar 15 16:13:02 EDT 2010


I guess the results of test 106 are not completely correct as isdataat
+ relative doesn't error out when a previous content match it
considers valid can't be found, instead it just starts from the
beginning of the payload so if my payload for the pcap is 135 bytes I
can specify isdataat:135,relative with a previous match of pcre + /U
it will still match.  This is what distance/within normally does as
well but in the case of /U with pcre it will always fail to match?

Regards,

Will

On Mon, Mar 15, 2010 at 1:42 PM, Will Metcalf <william.metcalf at ...2499...> wrote:
> 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";
> pcre:"/A(ll|pp)WorkAndNoPlayMakesWillADullBoy/U";
> 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