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

L0rd Ch0de1m0rt l0rdch0de1m0rt at ...11827...
Wed Dec 4 12:07:29 EST 2013


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 ...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
> B
>
>>
>> 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 ...11827...> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20131204/4e90cffe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bhaggy1.pcap
Type: application/vnd.tcpdump.pcap
Size: 493 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20131204/4e90cffe/attachment.pcap>


More information about the Snort-users mailing list