[prev in list] [next in list] [prev in thread] [next in thread]
List: snort-sigs
Subject: Re: [Snort-sigs] Using within after http_headers
From: Alex Kirk <akirk () sourcefire ! com>
Date: 2010-05-03 14:22:22
Message-ID: m2x8e0a702c1005030722k8f62e52w91921edcc4545faf () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Actually, the use of distance:0 in a uricontent is almost certainly no good,
as you've mentioned - if for no other reason than the possible false
positive cases. I'll review the spyware rules for cases where that occurs,
and fix them up. If there are other places you've seen that, let me know, so
we can take care of them.
On Fri, Apr 30, 2010 at 3:44 PM, Will Metcalf <william.metcalf@gmail.com>wrote:
> >On Fri, Apr 30, 2010 at 2:31 PM, Joel Esler <jesler@sourcefire.com>
> wrote:
> > http_client_body and http_uri aren't normalizers though, they are just
> > pointers to locations, the way that I read it.
> http_uri is normalized... Not sure about http_client_body..
>
> > As far as the distance:0; that's simply saying that the subsequent
> content
> > must be after the uricontent. not any distance "away" from the end of
> it,
> > just after the previous match succeeded.
>
> I understand but this can lead to false negatives. If the uricontent
> has to be decoded, using the uricontent,content,distance:0 combo
> causes the rule not to fire completely....
>
> Regards,
>
> Will
>
> > J
> > On Fri, Apr 30, 2010 at 3:21 PM, Will Metcalf <william.metcalf@gmail.com
> >
> > wrote:
> >>
> >> > Correct. Since this is a normalized field (similar to uricontent),
> you
> >> > can't have a relative statement to a normalized http field like that.
> >> > This is as designed.
> >> >
> >> This is not entirely accurate ;-)... For example some of the
> >> spyware-put rules mix uricontent,content and distance:0
> >>
> >> Also from my tests you can mix http_client_body and http_uri with
> >> distance and within, but it fails always for cookie and header. Also
> >> with http_uri just like uricontent if you encode the url distance and
> >> within doesn't work.
> >>
> >> Regards,
> >>
> >> Will
> >>
> >> On Fri, Apr 30, 2010 at 11:47 AM, Joel Esler <jesler@sourcefire.com>
> >> wrote:
> >>
> >> > On Fri, Apr 30, 2010 at 12:35 PM, Mike Cox <mike.cox52@gmail.com>
> wrote:
> >> >>
> >> >> I'm testing some rules and it seems that using the within content
> >> >> modifier on a content match that is relative to a previous content
> >> >> match and uses the http_headers content modifier does not work. For
> >> >> example, this is the original rule that is not alerting:
> >> >>
> >> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> >> >> flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> >> >> http_header; content:!"google.com"; nocase; within:50;
> >> >> classtype:bad-unknown; rev:1; sid:7500010;)
> >> >>
> >> >> But if I remove the within OR the http_header content modifiers, the
> >> >> rule alerts. So both these alert:
> >> >>
> >> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> >> >> flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> >> >> content:!"google.com"; nocase; within:50; classtype:bad-unknown;
> >> >> rev:1; sid:7500010;)
> >> >>
> >> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> >> >> flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> >> >> http_header; content:!"google.com"; nocase; classtype:bad-unknown;
> >> >> rev:1; sid:7500010;)
> >> >>
> >> >> Is there some weird stuff going on with the HTTP header buffer such
> >> >> that subsequent within content modifiers don't work? If so, is this
> >> >> as designed?
> >> >>
> >> >> Thanks.
> >> >>
> >> >> -Mike Cox
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> _______________________________________________
> >> >> Snort-sigs mailing list
> >> >> Snort-sigs@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Snort-sigs mailing list
> >> > Snort-sigs@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >> >
> >> >
> >
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
--
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk@sourcefire.com
[Attachment #5 (text/html)]
Actually, the use of distance:0 in a uricontent is almost certainly no good, as \
you've mentioned - if for no other reason than the possible false positive cases. \
I'll review the spyware rules for cases where that occurs, and fix them up. If \
there are other places you've seen that, let me know, so we can take care of \
them.<br> <br><div class="gmail_quote">On Fri, Apr 30, 2010 at 3:44 PM, Will Metcalf \
<span dir="ltr"><<a \
href="mailto:william.metcalf@gmail.com">william.metcalf@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">>On Fri, Apr 30, 2010 at 2:31 PM, \
Joel Esler <<a href="mailto:jesler@sourcefire.com">jesler@sourcefire.com</a>> \
wrote:<br> > http_client_body and http_uri aren't normalizers though, they are \
just<br> > pointers to locations, the way that I read it.<br>
</div>http_uri is normalized... Not sure about http_client_body..<br>
<div class="im"><br>
> As far as the distance:0; that's simply saying that the subsequent \
content<br> > must be after the uricontent. not any distance "away" \
from the end of it,<br> > just after the previous match succeeded.<br>
<br>
</div>I understand but this can lead to false negatives. If the uricontent<br>
has to be decoded, using the uricontent,content,distance:0 combo<br>
causes the rule not to fire completely....<br>
<br>
Regards,<br>
<font color="#888888"><br>
Will<br>
</font><div><div></div><div class="h5"><br>
> J<br>
> On Fri, Apr 30, 2010 at 3:21 PM, Will Metcalf <<a \
href="mailto:william.metcalf@gmail.com">william.metcalf@gmail.com</a>><br> > \
wrote:<br> >><br>
>> > Correct. Since this is a normalized field (similar to uricontent), \
you<br> >> > can't have a relative statement to a normalized http field \
like that.<br> >> > This is as designed.<br>
>> ><br>
>> This is not entirely accurate ;-)... For example some of the<br>
>> spyware-put rules mix uricontent,content and distance:0<br>
>><br>
>> Also from my tests you can mix http_client_body and http_uri with<br>
>> distance and within, but it fails always for cookie and header. Also<br>
>> with http_uri just like uricontent if you encode the url distance and<br>
>> within doesn't work.<br>
>><br>
>> Regards,<br>
>><br>
>> Will<br>
>><br>
>> On Fri, Apr 30, 2010 at 11:47 AM, Joel Esler <<a \
href="mailto:jesler@sourcefire.com">jesler@sourcefire.com</a>><br> >> \
wrote:<br> >><br>
>> > On Fri, Apr 30, 2010 at 12:35 PM, Mike Cox <<a \
href="mailto:mike.cox52@gmail.com">mike.cox52@gmail.com</a>> wrote:<br> >> \
>><br> >> >> I'm testing some rules and it seems that using the \
within content<br> >> >> modifier on a content match that is relative to \
a previous content<br> >> >> match and uses the http_headers content \
modifier does not work. For<br> >> >> example, this is the original rule \
that is not alerting:<br> >> >><br>
>> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing \
Referer";<br> >> >> flow:established,to_server; content:"|0d \
0a|Referer\: "; nocase;<br> >> >> http_header; content:!"<a \
href="http://google.com" target="_blank">google.com</a>"; nocase; within:50;<br> \
>> >> classtype:bad-unknown; rev:1; sid:7500010;)<br> >> \
>><br> >> >> But if I remove the within OR the http_header content \
modifiers, the<br> >> >> rule alerts. So both these alert:<br>
>> >><br>
>> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing \
Referer";<br> >> >> flow:established,to_server; content:"|0d \
0a|Referer\: "; nocase;<br> >> >> content:!"<a \
href="http://google.com" target="_blank">google.com</a>"; nocase; within:50; \
classtype:bad-unknown;<br> >> >> rev:1; sid:7500010;)<br>
>> >><br>
>> >> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing \
Referer";<br> >> >> flow:established,to_server; content:"|0d \
0a|Referer\: "; nocase;<br> >> >> http_header; content:!"<a \
href="http://google.com" target="_blank">google.com</a>"; nocase; \
classtype:bad-unknown;<br> >> >> rev:1; sid:7500010;)<br>
>> >><br>
>> >> Is there some weird stuff going on with the HTTP header buffer \
such<br> >> >> that subsequent within content modifiers don't work? \
If so, is this<br> >> >> as designed?<br>
>> >><br>
>> >> Thanks.<br>
>> >><br>
>> >> -Mike Cox<br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------------------------------------------------------<br>
>> >> _______________________________________________<br>
>> >> Snort-sigs mailing list<br>
>> >> <a \
href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@lists.sourceforge.net</a><br>
>> >> <a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br> \
>> ><br> >> ><br>
>> ><br>
>> > ------------------------------------------------------------------------------<br>
>> ><br>
>> > _______________________________________________<br>
>> > Snort-sigs mailing list<br>
>> > <a href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@lists.sourceforge.net</a><br>
>> > <a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br> \
>> ><br> >> ><br>
><br>
><br>
<br>
------------------------------------------------------------------------------<br>
_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br> \
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alex Kirk<br>AEGIS \
Program Lead<br>Sourcefire Vulnerability Research Team<br>+1-410-423-1937<br><a \
href="mailto:alex.kirk@sourcefire.com">alex.kirk@sourcefire.com</a><br>
------------------------------------------------------------------------------
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic