Snort mailing list archives

Previous By Date Next
Previous By Thread Next

Re: BUG: corner case involving http_cookie

From: Matt Jonkman <jonkman () jonkmans com>
Date: Wed, 10 Mar 2010 12:12:32 -0500
Appreciate the clarification Steve. But I'm concerned, this will make
hundreds if not a few thousand rules not work correctly in our set and
in vrt/snort gpl. If someone has http_inspect on in a recent snort, but
does NOT have ALL of their http related rules converted to the new form
using the http_* modifiers (which we have none converted) then they're
going to have massive problems, no? I think a lot of people are missing
a lot of things right now.

Is there a way to make http_inspect not do this? We have a lot of sigs
that won't work on normalized data, for instance the recent trojan sigs
that look at the order of the parameters in an http post for uniqieness.
With the normalized only we can't see that can we?

Thanks!

Matt

On 3/10/10 10:26 AM, Will Metcalf wrote:

1) Use http_cookie in the rule as you note in the case that works.


Right so the reason that I cc'd the emerging list is that they are not
using the http_* modifiers to maintain compatibility with older
versions of snort.  Shouldn't this buffer at least be available to
match on via rawbytes  which is what would be consistent with what you
have done with telnet and dcerpc.  Does this also not add a potential
evasion method if this is the intended behavior, one that perhaps
VRT/ET should be made aware of.  I haven't gone through very many of
the sigs but since the normalized buffer begins with the "Cookie:"
instead of the value isn't there a now a potential evasion if I can
get another sig to trip on the same packet as say sid 2136.

Regards,

Will

On Wed, Mar 10, 2010 at 8:15 AM, Steven Sturges
<steve.sturges () sourcefire com> wrote:

Will--

In the 2nd rule the only content is an HTTP cookie.  Without using
http_cookie, it would try to match the raw data.

With HTTP Inspect enabled, it is separating the headers, cookie,
method, etc from the raw data, hence all of the modifier keywords
that you can use with content -- can use more than one together.

Without specifying http_cookie in the rule and when HTTP Inspect
enabled (and cookie inspection enabled in 2.8.6), if the pattern
matcher searches any of the HTTP buffers, it doesn't search the raw
data.  If no rules use the specific HTTP buffers or there are no HTTP
buffers, the pattern matcher will search the raw data, which is why
the rule byte itself (without http_cookie) works.

This was done to avoid going over the same data twice in the pattern
matcher, and it is working as it is designed.

Two options:

1) Use http_cookie in the rule as you note in the case that works.

2) Turn off HTTP Inspect (not realistic)

Cheers
-steve

Will Metcalf wrote:

hmmm I don't think so.  Look at first test.  both rules fire.

Regards,

Will

On Tue, Mar 9, 2010 at 10:31 PM, beenph <beenph () gmail com> wrote:

I will try a wild guess, what is your event_queue size like?

Its probably a bug or something  that need clarification regarding
http_cookie and http_inspect, but mabey http_cookie enable a modifier
in http_inspect that alter alerting behavior when event_queue is at 1
(since i guess both "alerts" are part of the same normalized http
stream)


-elz
ps: didin't run the pcap and rules test.


On Tue, Mar 9, 2010 at 11:15 PM, Will Metcalf <william.metcalf () gmail com> wrote:

failing to use the http_cookie modifier on a rule where there is
another rule that matches the same packet makes a rule that should
fire fail.

src/snort -V

  ,,_     -*> Snort! <*-
 o"  )~   Version 2.8.5.3 (Build 124)
  ''''    By Martin Roesch & The Snort Team:
http://www.snort.org/snort/snort-team
          Copyright (C) 1998-2009 Sourcefire, Inc., et al.
          Using PCRE version: 7.8 2008-09-05


src/snort -k none -q -A console -c etc/snort.conf -l ./ -r oisfsearchnums.pcap

#this combo works
#alert tcp any any -> any any (msg:"http_client_body";
content:"searchword="; uricontent:"/index.php"; nocase;
classtype:bad-unknown; sid:59; rev:1;)
#alert tcp any any -> any any (msg:"http_cookie match ";
content:"e6504ae48c99f09df7f58996aacbb6b0=120e494ce857d6ceeef89f9678d4d703";
http_cookie; classtype:bad-unknown; sid:68; rev:1;)
#
#03/07-21:19:54.242506  [**] [1:59:1] http_client_body [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80
#03/07-21:19:54.242506  [**] [1:68:1] http_cookie match  [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80
#03/07-21:19:54.364173  [**] [1:68:1] http_cookie match  [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80

#the second rule does not fire
#alert tcp any any -> any any (msg:"http_client_body + depth";
content:"searchword="; uricontent:"/index.php"; nocase;
classtype:bad-unknown; sid:59; rev:1;)
#alert tcp any any -> any any (msg:"http_cookie match";
content:"e6504ae48c99f09df7f58996aacbb6b0=120e494ce857d6ceeef89f9678d4d703";
classtype:bad-unknown; sid:68; rev:1;)
#
#03/07-21:19:54.242506  [**] [1:59:1] http_client_body + depth [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80

#this rule fires when used on it's own.
#alert tcp any any -> any any (msg:"http_cookie match";
content:"e6504ae48c99f09df7f58996aacbb6b0=120e494ce857d6ceeef89f9678d4d703";
classtype:bad-unknown; sid:68; rev:1;)
#
#03/07-21:19:54.242506  [**] [1:68:1] http_cookie match [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80
#03/07-21:19:54.364173  [**] [1:68:1] http_cookie match [**]
[Classification: Potentially Bad Traffic] [Priority: 2] {TCP}
192.168.100.17:38111 -> 96.43.130.5:80

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel




------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel





------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel


-- 

----------------------------------------------------
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

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Previous By Date Next
Previous By Thread Next

Current thread: