Hi Matt,<br><br>Thank you very much for your help. It worked.<br><br>I have revised the Snort manual again and I have not found  <br>any comment about this behavior.<br><br>I see that I cannot use the  POST variable  when I am using<br>
http_client_body  (include=../../../../etc/passwd%00 )<br>and the preprocessor is also cleaning the traversal.<br><br>So, I can only match against "/etc/passwd". I was expecting that<br>http_client_body  and uricontent were having the same behavior.<br>
With uricontent I can match against "include=../".<br><br>I thought  the best way was to  match against "include=",<br>because there are many ways make a injection and the variable<br>is the only thing in common (many different files in the file system,<br>
php://input, etc).<br><br><br>Regards,<br><br>Xavier Garcia<br><br><div class="gmail_quote">2010/3/31 Matt Watchinski <span dir="ltr"><<a href="mailto:mwatchinski@...1935...">mwatchinski@...1935...</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Try this rule.<br><br>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;)<br><br>Cheers,<br><font color="#888888">-matt</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, Mar 30, 2010 at 2:12 PM, Xavi Garcia <span dir="ltr"><<a href="mailto:xavi.garcia@...11827..." target="_blank">xavi.garcia@...11827...</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Matt,<br><br>Thank you very much for your help.  <br><br>I did changed these settings before writing to the mailing list.<br>

<br>I am sorry because I am sure that it is a stupid error and my fault,<br>but I cannot find it myself after reading the documentation again<br>
and again.  I don't like wasting your time because I know you are<br>busy.<br><br><br>I put all the information in a single post and perhaps somebody can<br>help me to find the mistake. I also attach a pcap file with the<br>


network trace.<br><br><br>Snort binaries,<br>Latest Snort version downloaded from the website:<br>- Compiled from sources<br>- RPM for RHEL5.<br><br><br>Config,<div><br><br>preprocessor http_inspect: global \<br>
    iis_unicode_map unicode.map 1252<br>
<br>preprocessor http_inspect_server: \<br>    server default profile apache \<br></div>    ports { 80  }  \<br>    post_depth 65495 \<br>    client_flow_depth 1460 \<br>    normalize_headers \<br>    normalize_cookies<br>

<br><br>
Snort rule,<br><br>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;)<div>

<br>
<br>curl -d "include=../../../../../../../../../../../../../../etc/passwd%00" "<a href="http://192.168.178.29/index.php" target="_blank">http://192.168.178.29/index.php</a>"<br><br><br></div>HTTP Inspect initialization,<br>


<br><br>HttpInspect Config:<br>    GLOBAL CONFIG<br>      Max Pipeline Requests:    0<br>      Inspection Type:          STATELESS<br>      Detect Proxy Usage:       NO<br>      IIS Unicode Map Filename: /etc/snort/unicode.map<br>


      IIS Unicode Map Codepage: 1252<br>    DEFAULT SERVER CONFIG:<br>      Server profile: Apache<br>      Ports: 80<br>      Server Flow Depth: 300<br>      Client Flow Depth: 1460<br>      Max Chunk Length: 500000<br>

      Max Header Field Length: 0<br>
      Max Number Header Fields: 0<br>      Inspect Pipeline Requests: YES<br>      URI Discovery Strict Mode: NO<br>      Allow Proxy Usage: NO<br>      Disable Alerting: NO<br>      Oversize Dir Length: 0<br>      Only inspect URI: NO<br>


      Normalize HTTP Headers: YES<br>      Normalize HTTP Cookies: YES<br>      Ascii: YES alert: NO<br>      Double Decoding: OFF<br>      %U Encoding: OFF<br>      Bare Byte: OFF<br>      Base36: OFF<br>      UTF 8: YES alert: NO<br>


      IIS Unicode: OFF<br>      Multiple Slash: YES alert: NO<br>      IIS Backslash: OFF<br>      Directory Traversal: YES alert: NO<br>      Web Root Traversal: YES alert: YES<br>      Apache WhiteSpace: YES alert: NO<br>


      IIS Delimiter: OFF<br>      IIS Unicode Map:  NOT CONFIGURED<br>      Non-RFC Compliant Characters: NONE<br>      Whitespace Characters: 0x09 0x0b 0x0c 0x0d<br><br><br>HTTP Inspect statistics,<div><br><br>
HTTP Inspect - encodings (Note: stream-reassembled packets included):<br>
    POST methods:                   2         <br>    GET methods:                    0         <br>    Headers extracted:              2         <br></div>    Header Cookies extracted:       0         <br><div>
    Post parameters extracted:      2         <br>
    Unicode:                        0         <br>    Double unicode:                 0         <br>    Non-ASCII representable:        0         <br>    Base 36:                        0         <br>    Directory traversals:           26        <br>


    Extra slashes ("//"):           0         <br>    Self-referencing paths ("./"):  26        <br></div>    Total packets processed:        20<br><br><br><br>Regards,<br><br>Xavier Garcia<br><br><br>

<br><div class="gmail_quote">
2010/3/26 Matt Watchinski <span dir="ltr"><<a href="mailto:mwatchinski@...1935..." target="_blank">mwatchinski@...1935...</a>></span><div><div></div><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


You'll need to add "post_depth 65495" to your http_inspect_server configuration.<br><br>Once you have this you'll generate a "dir traversal alert from http_inspect"<br><br>Output at end of snort run will look like this:<div>


<br>
<br>HTTP Inspect - encodings (Note: stream-reassembled packets included):<br>    POST methods:                   2         <br>    GET methods:                    0         <br>    Headers extracted:              2         <br>


</div>
    Avg Header length:              206.00    <br>    Header Cookies extracted:       0         <br>    Avg Cookie length:              n/a       <br><div>    Post parameters extracted:      2         <br>    Unicode:                        0         <br>



    Double unicode:                 0         <br>    Non-ASCII representable:        0         <br>    Base 36:                        0<br>         <br>->>>>>    Directory traversals:           26        <br>



<br>    Extra slashes ("//"):           0         <br>    Self-referencing paths ("./"):  26        <br></div>    Total packets processed:        4<br><br>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.  <br>



<br>Cheers,<br>-matt<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Mar 26, 2010 at 1:26 PM, Xavi Garcia <span dir="ltr"><<a href="mailto:xavi.garcia@...11827..." target="_blank">xavi.garcia@...14459.....</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>
Hi,<br><br>I am using the following rule to test a local file inclusion.<br><br>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;)<br>




<br>that catches the following attack:<br><br>curl  -d "include=../../../../../../../../../../../../../../../../../../../../../etc/passwd%00" "<a href="http://192.168.178.29/index.php" target="_blank">http://192.168.178.29/index.php</a>"<br>




<br>But fails when I encode the data in Hex.<br><br>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" "<a href="http://192.168.178.29/index.php" target="_blank">http://192.168.178.29/index.php</a>"<br>




<br>I have checked the Changelog and the POST data should be<br>normalized, but I cannot find how to match against this normalized data.<br><br>007-04-27 Steven Sturges <<a href="mailto:ssturges@...1935..." target="_blank">ssturges@...1935...</a>>                                                                                                          <br>




Update to normalize the body of a client request to allow                                                                                                    <br>rules to check specifically for parameters of a POST or GET request. <br>




Also add stats that are part of the hourly stats that track                                                                                                  <br>various HTTP encodings and normalizations that have occurred.<br>




<br><br>Perhaps the preprocessor is misconfigured ...<br><br>preprocessor http_inspect: global \<br>    iis_unicode_map unicode.map 1252<br><br>preprocessor http_inspect_server: \<br>    server default profile apache \<br>




    client_flow_depth 1460 \<br>    ports { 80  }  \<br>    normalize_headers \<br>    normalize_cookies \<br>    post_depth 65495<br><br><br>Regards,<br><br>Xavier Garcia<br><br><div class="gmail_quote">2010/3/25 Xavi Garcia <span dir="ltr"><<a href="mailto:xavi.garcia@...11827..." target="_blank">xavi.garcia@...11827...</a>></span><div>



<div></div><div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br><br>Thank you for your fast answer.<br><br>As far I understand, http_uri  works like uricontent.<br>




It is useful to fix the the resource being requested<br>but then we have to match against the data. I have<br>only been able to do so when I use "content"<br>
without modifiers.<br><br>Regards,<br><br>Xavier Garcia <br><br><div class="gmail_quote">2010/3/25 Crook, Parker <span dir="ltr"><<a href="mailto:Parker_Crook@...14786..." target="_blank">Parker_Crook@...14786...</a>></span><div>




<div></div><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">






<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">Xavi,</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">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>”;</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">-Parker</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<div>
<div class="MsoNormal" style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">
<hr width="100%" size="2" align="center">
</span></font></div>
<p class="MsoNormal"><b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma;"> Xavi Garcia [mailto:<a href="mailto:xavi.garcia@...13610...7..." target="_blank">xavi.garcia@...11827...</a>]
<br>
<b><span style="font-weight: bold;">Sent:</span></b> Thursday, March 25, 2010 2:27 PM<br>
<b><span style="font-weight: bold;">To:</span></b> <a href="mailto:snort-users@lists.sourceforge.net" target="_blank">snort-users@...2987...rge.net</a><br>
<b><span style="font-weight: bold;">Subject:</span></b> [Snort-users] HTTP preprocessor and POST data</span></font></p>
</div><div><div></div><div>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"> </span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Hi,<br>
<br>
I am learning how HTTP Inspect works and also trying<br>
to write some rules that use normalized data. I think that<br>
all is explained in the documentation and you have done<br>
a great job, but I have a doubt regarding the POST data.  <br>
<br>
I am sure that my question is too obvious, but I have tried<br>
to find the right answer by myself without luck. :) <br>
<br>
I see that the newer versions of Snort permit to normalize<br>
data from the URI, headers, cookies and the body, but there<br>
is nothing about the POST data. I have tried to use the<br>
different modifiers for  "content" without luck.<br>
<br>
I understand that POST data cannot be normalized, but<br>
there is no mention in the documentation. Am I wrong?<br>
In that case, which is the best practice when I want to<br>
detect an attack that is using POST instead of GET?<br>
<br>
Thank you very much for your help :)<br>
<br>
Regards,<br>
<br>
Xavier Garcia</span></font></p>
</div></div></div>
</div>

</blockquote></div></div></div><br>
</blockquote></div></div></div><br>
<br></div></div>------------------------------------------------------------------------------<br>
Download Intel&#174; Parallel Studio Eval<br>
Try the new software tools for yourself. Speed compiling, find bugs<br>
proactively, and fine-tune applications for parallel performance.<br>
See why Intel Parallel Studio got high marks during beta.<br>
<a href="http://p.sf.net/sfu/intel-sw-dev" target="_blank">http://p.sf.net/sfu/intel-sw-dev</a><br>_______________________________________________<br>
Snort-users mailing list<br>
<a href="mailto:Snort-users@lists.sourceforge.net" target="_blank">Snort-users@lists.sourceforge.net</a><br>
Go to this URL to change user options or unsubscribe:<br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-users%0ASnort-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-users<br>
Snort-users</a> list archive:<br>
<a href="http://www.geocrawler.com/redir-sf.php3?list=snort-users" target="_blank">http://www.geocrawler.com/redir-sf.php3?list=snort-users</a><br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>Matthew Watchinski<br>


Sr. Director Vulnerability Research Team (VRT)<br>
Sourcefire, Inc.<br>Office: 410-423-1928<br><a href="http://vrt-sourcefire.blogspot.com" target="_blank">http://vrt-sourcefire.blogspot.com</a> && <a href="http://www.snort.org/vrt/" target="_blank">http://www.snort.org/vrt/</a><br>



</font></blockquote></div></div></div><br>
</blockquote></div><br><br clear="all"><br>-- <br>Matthew Watchinski<br>Sr. Director Vulnerability Research Team (VRT)<br>Sourcefire, Inc.<br>Office: 410-423-1928<br><a href="http://vrt-sourcefire.blogspot.com" target="_blank">http://vrt-sourcefire.blogspot.com</a> && <a href="http://www.snort.org/vrt/" target="_blank">http://www.snort.org/vrt/</a><br>


</div></div></blockquote></div><br>