[Snort-users] HTTP preprocessor and POST data

Matt Watchinski mwatchinski at ...1935...
Tue Mar 30 18:57:28 EDT 2010


Try this rule.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"TEST - local
file inclusion in POST"; flow:to_server,established; content:"POST"; nocase;
http_method; uricontent:"/index.php"; nocase; content:"passwd";
http_client_body;  nocase;  sid:20000001; rev:1;)

Cheers,
-matt

On Tue, Mar 30, 2010 at 2:12 PM, Xavi Garcia <xavi.garcia at ...11827...> wrote:

> Hi Matt,
>
> Thank you very much for your help.
>
> I did changed these settings before writing to the mailing list.
>
> I am sorry because I am sure that it is a stupid error and my fault,
> but I cannot find it myself after reading the documentation again
> and again.  I don't like wasting your time because I know you are
> busy.
>
>
> I put all the information in a single post and perhaps somebody can
> help me to find the mistake. I also attach a pcap file with the
> network trace.
>
>
> Snort binaries,
> Latest Snort version downloaded from the website:
> - Compiled from sources
> - RPM for RHEL5.
>
>
> Config,
>
>
> preprocessor http_inspect: global \
>     iis_unicode_map unicode.map 1252
>
> preprocessor http_inspect_server: \
>     server default profile apache \
>     ports { 80  }  \
>     post_depth 65495 \
>     client_flow_depth 1460 \
>     normalize_headers \
>     normalize_cookies
>
>
> Snort rule,
>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"TEST - local
> file inclusion in POST"; flow:to_server,established;content:"POST"; nocase;
> http_method; uricontent:"/index.php"; nocase; content:"include";
> http_client_body;  nocase;  sid:20000001; rev:1;)
>
>
> curl -d "include=../../../../../../../../../../../../../../etc/passwd%00" "
> http://192.168.178.29/index.php"
>
>
> HTTP Inspect initialization,
>
>
> HttpInspect Config:
>     GLOBAL CONFIG
>       Max Pipeline Requests:    0
>       Inspection Type:          STATELESS
>       Detect Proxy Usage:       NO
>       IIS Unicode Map Filename: /etc/snort/unicode.map
>       IIS Unicode Map Codepage: 1252
>     DEFAULT SERVER CONFIG:
>       Server profile: Apache
>       Ports: 80
>       Server Flow Depth: 300
>       Client Flow Depth: 1460
>       Max Chunk Length: 500000
>       Max Header Field Length: 0
>       Max Number Header Fields: 0
>       Inspect Pipeline Requests: YES
>       URI Discovery Strict Mode: NO
>       Allow Proxy Usage: NO
>       Disable Alerting: NO
>       Oversize Dir Length: 0
>       Only inspect URI: NO
>       Normalize HTTP Headers: YES
>       Normalize HTTP Cookies: YES
>       Ascii: YES alert: NO
>       Double Decoding: OFF
>       %U Encoding: OFF
>       Bare Byte: OFF
>       Base36: OFF
>       UTF 8: YES alert: NO
>       IIS Unicode: OFF
>       Multiple Slash: YES alert: NO
>       IIS Backslash: OFF
>       Directory Traversal: YES alert: NO
>       Web Root Traversal: YES alert: YES
>       Apache WhiteSpace: YES alert: NO
>       IIS Delimiter: OFF
>       IIS Unicode Map:  NOT CONFIGURED
>       Non-RFC Compliant Characters: NONE
>       Whitespace Characters: 0x09 0x0b 0x0c 0x0d
>
>
> HTTP Inspect statistics,
>
>
> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>     POST methods:                   2
>     GET methods:                    0
>     Headers extracted:              2
>     Header Cookies extracted:       0
>     Post parameters extracted:      2
>     Unicode:                        0
>     Double unicode:                 0
>     Non-ASCII representable:        0
>     Base 36:                        0
>     Directory traversals:           26
>     Extra slashes ("//"):           0
>     Self-referencing paths ("./"):  26
>     Total packets processed:        20
>
>
>
> Regards,
>
> Xavier Garcia
>
>
>
> 2010/3/26 Matt Watchinski <mwatchinski at ...1935...>
>
> You'll need to add "post_depth 65495" to your http_inspect_server
>> configuration.
>>
>> Once you have this you'll generate a "dir traversal alert from
>> http_inspect"
>>
>> Output at end of snort run will look like this:
>>
>>
>> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>>     POST methods:                   2
>>     GET methods:                    0
>>     Headers extracted:              2
>>      Avg Header length:              206.00
>>     Header Cookies extracted:       0
>>     Avg Cookie length:              n/a
>>     Post parameters extracted:      2
>>     Unicode:                        0
>>     Double unicode:                 0
>>     Non-ASCII representable:        0
>>     Base 36:                        0
>>
>> ->>>>>    Directory traversals:           26
>>
>>     Extra slashes ("//"):           0
>>     Self-referencing paths ("./"):  26
>>     Total packets processed:        4
>>
>> If you want to inspect the post data, then use the "http_client_body"
>> keyword after "content".  Just keep in mind that uricontent normalization
>> and "http_client_body" normalization are not the same and produce different
>> normalized buffers.
>>
>> Cheers,
>> -matt
>>
>> On Fri, Mar 26, 2010 at 1:26 PM, Xavi Garcia <xavi.garcia at ...11827...>wrote:
>>
>>> Hi,
>>>
>>> I am using the following rule to test a local file inclusion.
>>>
>>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"TEST -
>>> local file inclusion POST"; flow:to_server,established;content:"POST";
>>> nocase; http_method; uricontent:"/index.php"; nocase; content:"include=..";
>>> nocase;  classtype:web-application-attack;  sid:20000000; rev:1;)
>>>
>>> that catches the following attack:
>>>
>>> curl  -d
>>> "include=../../../../../../../../../../../../../../../../../../../../../etc/passwd%00"
>>> "http://192.168.178.29/index.php"
>>>
>>> But fails when I encode the data in Hex.
>>>
>>> curl  -d
>>> "include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc/passwd%00"
>>> "http://192.168.178.29/index.php"
>>>
>>> I have checked the Changelog and the POST data should be
>>> normalized, but I cannot find how to match against this normalized data.
>>>
>>> 007-04-27 Steven Sturges <ssturges at ...1935...>
>>>
>>> Update to normalize the body of a client request to
>>> allow
>>>
>>> rules to check specifically for parameters of a POST or GET request.
>>> Also add stats that are part of the hourly stats that
>>> track
>>>
>>> various HTTP encodings and normalizations that have occurred.
>>>
>>>
>>> Perhaps the preprocessor is misconfigured ...
>>>
>>> preprocessor http_inspect: global \
>>>     iis_unicode_map unicode.map 1252
>>>
>>> preprocessor http_inspect_server: \
>>>     server default profile apache \
>>>     client_flow_depth 1460 \
>>>     ports { 80  }  \
>>>     normalize_headers \
>>>     normalize_cookies \
>>>     post_depth 65495
>>>
>>>
>>> Regards,
>>>
>>> Xavier Garcia
>>>
>>> 2010/3/25 Xavi Garcia <xavi.garcia at ...11827...>
>>>
>>> Hi,
>>>>
>>>> Thank you for your fast answer.
>>>>
>>>> As far I understand, http_uri  works like uricontent.
>>>> It is useful to fix the the resource being requested
>>>> but then we have to match against the data. I have
>>>> only been able to do so when I use "content"
>>>> without modifiers.
>>>>
>>>> Regards,
>>>>
>>>> Xavier Garcia
>>>>
>>>> 2010/3/25 Crook, Parker <Parker_Crook at ...14786...>
>>>>
>>>>  Xavi,
>>>>>
>>>>>
>>>>>
>>>>> You can definitely use the (content:”POST”; http_method;) to alert only
>>>>> on POST data; however for the data normalization, I’m having a brain-fart
>>>>> right now… maybe somebody else knows, perhaps content:”<match_string>”;
>>>>> http_uri; pcre:”<more specific criteria>”;
>>>>>
>>>>>
>>>>>
>>>>> -Parker
>>>>>
>>>>>
>>>>>  ------------------------------
>>>>>
>>>>> *From:* Xavi Garcia [mailto:xavi.garcia at ...11827...]
>>>>> *Sent:* Thursday, March 25, 2010 2:27 PM
>>>>> *To:* snort-users at lists.sourceforge.net
>>>>> *Subject:* [Snort-users] HTTP preprocessor and POST data
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am learning how HTTP Inspect works and also trying
>>>>> to write some rules that use normalized data. I think that
>>>>> all is explained in the documentation and you have done
>>>>> a great job, but I have a doubt regarding the POST data.
>>>>>
>>>>> I am sure that my question is too obvious, but I have tried
>>>>> to find the right answer by myself without luck. :)
>>>>>
>>>>> I see that the newer versions of Snort permit to normalize
>>>>> data from the URI, headers, cookies and the body, but there
>>>>> is nothing about the POST data. I have tried to use the
>>>>> different modifiers for  "content" without luck.
>>>>>
>>>>> I understand that POST data cannot be normalized, but
>>>>> there is no mention in the documentation. Am I wrong?
>>>>> In that case, which is the best practice when I want to
>>>>> detect an attack that is using POST instead of GET?
>>>>>
>>>>> Thank you very much for your help :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Xavier Garcia
>>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Snort-users mailing list
>>> Snort-users at lists.sourceforge.net
>>> Go to this URL to change user options or unsubscribe:
>>> https://lists.sourceforge.net/lists/listinfo/snort-users
>>> Snort-users<https://lists.sourceforge.net/lists/listinfo/snort-users%0ASnort-users>list archive:
>>> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>>>
>>
>>
>>
>> --
>> Matthew Watchinski
>> Sr. Director Vulnerability Research Team (VRT)
>> Sourcefire, Inc.
>> Office: 410-423-1928
>> http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/
>>
>
>


-- 
Matthew Watchinski
Sr. Director Vulnerability Research Team (VRT)
Sourcefire, Inc.
Office: 410-423-1928
http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100330/19366765/attachment.html>


More information about the Snort-users mailing list