Snort mailing list archives
Re: [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword
From: rmkml <rmkml () yahoo fr>
Date: Wed, 4 Dec 2013 22:08:34 +0100 (CET)
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> wrote:
On Thu, Nov 7, 2013 at 4:42 PM, L0rd Ch0de1m0rt <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> 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> 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-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!
Current thread:
- Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Nov 06)
- Re: [Snort-devel] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword Bad Horse (Nov 07)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword Bhagya Bantwal (Nov 07)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Nov 07)
- Re: [Snort-sigs] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword rmkml (Nov 08)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Nov 20)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword rmkml (Nov 20)
- Re: [Snort-devel] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword Bhagya Bantwal (Nov 22)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Dec 04)
- Re: [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword rmkml (Dec 04)
- Re: [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Dec 05)
- Re: [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword Joel Esler (jesler) (Dec 09)
- Re: [Snort-users] [Snort-devel] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword lists () packetmail net (Dec 09)
- Re: [Snort-sigs] [Snort-users] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword Joel Esler (jesler) (Dec 09)
- Re: Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword L0rd Ch0de1m0rt (Nov 07)
