| Main Archive Page > Month Archives > snort-users archives |
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@gmail.com> 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@sourcefire.com>
>
> 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@gmail.com>
>
> 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@reyrey.com>
>>
>> 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@gmail.com]
>>> *Sent:* Thursday, March 25, 2010 2:27 PM
>>> *To:* snort-users@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@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/
------------------------------------------------------------------------------
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@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users