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

rmkml rmkml at ...2519...
Fri Nov 8 04:09:29 EST 2013


Hi L0rd,

Replyed offline but no feedback, ok send to the list.

ok it's work for me,

simply tested with:
  wget "http://www.google.com/iused/2/trust/the.http_preprocessor/sad1/cr1090hs:SN-IF-FF-"

joigned pcap file.

with your two sigs:
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; sid:10; rev:1;)

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; sid:11; rev:1;)

and snort ... -r pcap -k none :
11/07-11:49:40.590605  [**] [1:11:1] Dont Cry 4 Me Trojanina [**] [Priority: 0] {TCP} 192.168.42.150:53853 -> 173.194.40.178:80

11/07-11:49:40.590605  [**] [1:10:1] Dont Cry 4 Me Trojanina [**] [Priority: 0] {TCP} 192.168.42.150:53853 -> 173.194.40.178:80

Could you share a pcap + snort.conf + snort cmd line please ?
Do you have disabled cksum ? (-k none)

Regards
@Rmkml


On Thu, 7 Nov 2013, L0rd Ch0de1m0rt 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?
> 
> Thanks for everyones' help.
> 
> Cheers,
> 
> Lord C.
> 
> 
> On Thu, Nov 7, 2013 at 12:31 PM, Bhagya Bantwal <bbantwal at ...402...> 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 ...3054....> 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.
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at 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!
> 
> 
> 
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exemple_http_test_7nov2013a.pcap
Type: application/cap
Size: 2217 bytes
Desc: 
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20131108/7d5d1176/attachment.bin>


More information about the Snort-devel mailing list