Re: flow_depth and WMF exploit

[Matthew Watchinski <mwatchinski () sourcefire com>]

Just to clarify, and sum up some of the other comments on this thread.

1. All flow_depth 0 does is tell http_inspect not to truncate server 
responses.  It doesn't have anything to do with the number of packets to 
 inspect.

IE if you set flow_depth to 0 and the web server sends you 3 full 1500 
byte packets back snort will look at all the data in them and not 
truncate them at 300 bytes (ie the default)

2. Stream reassembly is done by the stream reassembler.  If you want to 
put multiple packets back together and then look for a combined content 
that might span all of the packets you have to tell snort to do that. 
Ala "stream4_reassemble: both, ports all" or something like that, as 
stream4 is set to client_only by default.  You are then governed by the 
rules of the stream reassembler.

3. Http_inspect was designed on purpose to ignore most if not all server 
response traffic.  If you set flow_depth to 0 and stream4_reassemble to 
both all, you will take a 80% to 90% performance hit.  This is probably 
ok if you have sub 10 meg links.  If you don't this is not ok, 
especially if you are in an inline configuration.

4. If you are really worried about WMF style attacks then snort or any 
IDS/IPS is the wrong product for you to use to defend yourself.  It's 
like using a pillow to stop bullets.  Here is why:

a. Compression - Microsoft IE support 3 compression types that I know about.
b. Chunked encoding - Every web server supports chunked requests, lets 
say the bad guy chunks every attack into 3 byte chunks.
c. Character Encodings - IE supports several different character 
encodings and ways to represent characters.  Simple example \x2F is not 
always \x2F it can sometimes be \x00 \x2F.  It can also be other things.
d. Microsoft loves to let you embed any file in any file.  So if your 
worried about WMF files you might want to check out DOC files, as 
Microsoft support embedding WMF files in DOC files.  You can do it with 
tons of other files too.  Oh and some of those file types support 
compression algorithms.
e. Then my favorite, Xscript (javascript,vbscript,ActiveX,etc).  Since 
vbscript supports things like stream objects and other silly things you 
don't even have to return the actual file you can return code that 
generates the file on the client side and then tells IE to open it :) .
f. Then it just gets kind of silly.  So if you use "e" above, and then 
write your own page encoder and decoder in javascript or some other 
language you can have all kinds of fun.
g. etc....

The best your going to be able to do with any IPS/IDS is clean up after 
yourself by tracking down infected hosts.  This is why a layered 
approach is a better option, use the right tools for the job and you'll 
get a better result.

Cheers,
Matthew Watchinski
Director, Vulnerability Research
Sourcefire, Inc.



Frank Knobbe wrote:
> On Wed, 2006-01-04 at 12:33 +1300, Jason Haar wrote:
>
> > The "fix" is to set flow_depth to zero - which apparently will/might
> > effectively DoS your IDS on a busy network. So it's not much of a fix.
> > Also, I get the impression flow_depth only ever looks at the first packet?
>
>
> Hi Jason,
>
> here an excerpt from README.http_inspect:
> ---8<---
> * flow_depth [integer] *
> [...]
> This value can be set from -1 to 1460. A value of -1 causes Snort
> to ignore all server side traffic for ports defined in "ports."
> Inversely, a value of 0 causes Snort to inspect all HTTP server
> payloads defined in "ports" (note that this will likely slow down IDS
> performance).  Values above 0 tell Snort the number of bytes to
> inspect in the first packet of the server response.
> --->8---
>
> I'm not quite sure how to read that, but from the performance collapse
> of flow_depth 0, I think 0 truly means ALL packets (or all data in the
> stream). I don't think 0 means 1460. As such, there is probably no
> limit.
>
> But you can inspect only, say two packets. It's either the max of one,
> or all data. (someone please correct me where I'm wrong).
>
>
> > Is that the case, and if so, are there better ways of doing it? Reading
> > returned HTTP data seems to me to be rather a necessary act for an IDS...
>
>
> Heh... it would certainly helps ;)   There were several rules that
> people wrote to detect content on web pages. With the default settings,
> Snort would never get to that content. It would evaluate 300 bytes,
> which covers the header, and providing there are no massive cookies set,
> part of the web page. Usually that part is <html><head>, scripts and
> stuff, but by the time you reach <body>, you are most likely past the
> 300 bytes.
>
> So all rules trying to detect stuff like "terrorist" on a web page would
> never fire (unless terrorist is in a meta-tag way on top of the html
> content... ;)
>
> It's a bit of concern, but an IDS is an Intrusion Detection System, not
> a web filter :)  We should probably use screening web proxies for that
> purpose.
>
> Having said that, the two largest vectors for intrusions are currently
> web and email content, which are very hard to inspect properly with
> Snort. At the end of the day, Snort will probably remain to detect
> intrusions after they happened, not while they are happening (meaning,
> watching the HTTP or SMTP content).
>
> However, I still like to be able to see gzipped HTTP content. :)
>
> To really make use of Snort for detection of web based threats, we
> probably need to deploy dedicated sensors for those and configure them
> accordingly. (ie. web-response only rules, flow_depth 0).
>
> Unfortunately, these facts are not often discussed (though they appear
> to be documented).
>
> Cheers,
> Frank



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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