Snort mailing list archives

Re: HTTP preprocessor and POST data

From: Xavi Garcia <xavi.garcia () gmail com>
Date: Thu, 1 Apr 2010 19:58:46 +0200

Hi,

I am not sure if there is something wrong with the http preprocessor.

Using the following 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:"bob";http_client_body;  nocase;  sid:20000002; rev:1;)

And the following POST requests:

curl  -d "alice=bob" \
  -d "include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd%00"
\
  "http://192.168.178.29/index.php";

curl  -d
"include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd%00" \
  -d "alice=bob" \
  "http://192.168.178.29/index.php";


It triggers only when alice=bob is going after "include=...":
(Only triggers in the second case).

alice=bob&include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd%00

or

include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd%00&alice=bob



Also, if I try to match against "include=", it only works when there is no
traversal:

include=foo
or
include=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd%00



Regards,

Xavier Garcia


2010/3/31 Xavi Garcia <xavi.garcia () gmail com>

Hi Matt,

Thank you very much for your help. It worked.

I have revised the Snort manual again and I have not found
any comment about this behavior.

I see that I cannot use the  POST variable  when I am using
http_client_body  (include=../../../../etc/passwd%00 )
and the preprocessor is also cleaning the traversal.

So, I can only match against "/etc/passwd". I was expecting that
http_client_body  and uricontent were having the same behavior.
With uricontent I can match against "include=../".

I thought  the best way was to  match against "include=",
because there are many ways make a injection and the variable
is the only thing in common (many different files in the file system,
php://input, etc).


Regards,

Xavier Garcia

2010/3/31 Matt Watchinski <mwatchinski () sourcefire com>

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 () gmail com>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 () sourcefire com>

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&#174; 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/



--
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&#174; 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

Current thread:

Re: HTTP preprocessor and POST data Xavi Garcia (Apr 01)