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

rmkml rmkml at ...1855...
Wed Dec 4 16:08:34 EST 2013


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 at ...1935...> wrote:
> 
> 
>
>       On Thu, Nov 7, 2013 at 4:42 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt at ...979...11827...> 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
>> 
> Thanks for everyones' help.
> 
> Cheers,
> 
> Lord C.
> 
> 
> On Thu, Nov 7, 2013 at 12:31 PM, Bhagya Bantwal <bbantwal at ...1935...> 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 at ...14459.....> 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.


More information about the Snort-users mailing list