Re: [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword

["Joel Esler (jesler)" <jesler () cisco com>]

Sorry for taking a while to get back to you.  2.9.4.1 is EOL.  2.9.4.6 is the last version supported in the 2.9.4.x 
tree.

--
Joel Esler
AEGIS Intelligence Lead
OpenSource Manager
Vulnerability Research Team

On Dec 5, 2013, at 2:12 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com<mailto:l0rdch0de1m0rt () gmail com>> wrote:

Hello.  OH thanks 2 u rmkl, you see the problem that I do!  Snort 2.9.4.1 and previous could have issue and then it is 
not just me.  Are these versions supported and can we get a patch?  IF the fix is to upgrade to a later version then 
that is not trival and could delay many months or up to a year or more or never on embedded devices (eps military 
ones).  Hopefully supported versions get attention since vendors such as Apple release updates for their software even 
if newer versions are available (for an example, a bug in OS X Lions doesn't make me get suggested to upgrade to the 
Mavaricks', it just gets fixed b/c is is still supported),

Cheers,

Lord C.

On Wed, Dec 4, 2013 at 4:08 PM, rmkml <rmkml () yahoo fr<mailto:rmkml () yahoo fr>> wrote:
Hi L0rd,

ok my testing with your pcap: (in this test, all snort use same config)

-v2.9.5.6 all sigs fire

-v2.9.4.6 all sigs fire

-v2.9.4.5 all sigs fire

-v2.9.4.1 sig three only fire

-v2.9.3.1 sig three only fire

Regards
@Rmkml



On Wed, 4 Dec 2013, L0rd Ch0de1m0rt wrote:

Thanks Bhagya,

I looked again and the sensor is SNORT v2.9.3.1 (we have a number of different versions and I access multiples on 
different consoles so I think I saw the wrong one when I said 2.9.5.3).  Hopefully v2.9.3.1
is supported still too :) If no, could there be issues with supported version?

The issue is a problem with holistic recursion on the http_uri buffer.  The engine when looking in the http_uri buffer 
detects on a content match that comes before a subsequent relative content match.  But
the enginge does not properly recurse to find all the (initial) content matches and attempt to match them using the 
subsequent relative content match.

I have attached a simple pcap.  I do not have a config readily available but (althou as you can see below), the info 
below shows that the HTTP_INSPECT pre-processor is enabled, working, and inspecting data
for the ports and data in the packets.  Here is the datum:

These rules do *NOT* alert:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; http_uri; content:"|3A|"; http_uri; distance:1;
within:20;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; http_uri; content:"|3A|"; http_uri; distance:1;
within:48;)

Howevers, this one *DOES ALERT*!:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; http_uri; content:"|3A|"; http_uri; distance:1;
within:49;)

If you count bytes in the packet you can see that clearly the proper recursion for detection is not taking place.

Pls let me know if you have any question.

Tks & Cheers,

Lord C.


On Fri, Nov 22, 2013 at 11:58 AM, Bhagya Bantwal <bbantwal () sourcefire com<mailto:bbantwal () sourcefire com>> wrote:



      On Thu, Nov 7, 2013 at 4:42 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com<mailto:l0rdch0de1m0rt () gmail com>> 
wrote:
            Hello.

@Bad Horse: I tried http_raw_uri and it still does not work.  That is good point about the colon in the uri.  The funny 
thing is that if I increase the distance, it WILL work so it seems that
maybe the parser it getting "stuck" on the first content match (0x2F) and not evaluating everything in full.  To test, 
I tried this rule and it DID work! :

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; http_uri; content:"|3A|"; http_uri;
distance:1; within:50;)

@Baggy: I tried a number of versions and the latest was 2.9.5.3 I believe, is that still supported?


Yes. It is supported. Can you please send your conf and pcap for further debugging?

Thanks
B

Thanks for everyones' help.

Cheers,

Lord C.


On Thu, Nov 7, 2013 at 12:31 PM, Bhagya Bantwal <bbantwal () sourcefire com<mailto:bbantwal () sourcefire com>> wrote:
      Hello,

Have you tested with snort version snort 2.9.5.5? With this snort version I see the alert as expected.

If it still doesn't work, you can send me your pcap & conf and I will take a look.

Thanks!
B


On Wed, Nov 6, 2013 at 2:01 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com<mailto:l0rdch0de1m0rt () gmail com>> wrote:
      Hello,

      Previously I posted on this list with an email subject of, "distance, within, and negated matches".  Today I 
bring another issue that I am having that I believes could be
      related and is non-trivial and super serious.

      When I analyze it I believe that relative (1 byte?) content matches are not being properly applied in the 
http_uri buffer.  Other buffers for the http preprocessor may be
      affected as well but I have not tested them but I won't be suprised if they are also infected by this bug.

      This is an example of the rule Im using:

      alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; http_uri;
      content:"|3A|"; http_uri; distance:1; within:20;)

      Using a simple pcap ("Follow TCP stream" output from Ethereal is here:)

      GET /iused/2/trust/the.http_preprocessor/sad1/cr1090hs:SN-IF-FF- HTTP/1.1

      The rule does not alert even though the Snort output shows that the HTTP data is being properly recognized and 
processed by the http_inspect preprocessor. The Snort output shows
      that the specific GET request is being recognized as a HTTP "GET" request.

      When I remove the http_inspect directives, the rule starts to work, this is an example:

      alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me Trojanina"; flow:established, to_server; 
content:"GET"; http_method; content:"|2F|"; content:"|3A|";
      distance:1; within:20;)

      Is this (still?) a known issue?  I have tested this on multiple different versions of Snort 2.9.

      Cheers,

      Lord C.

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!