Snort mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17

From: Sethsec <sethsec () gmail com>
Date: Tue, 23 Mar 2010 21:50:40 -0400
Evilghost,

To Sourcefires defense, I can't imagine that any of the IDS vendors  
can do any better on the gzip side. It is an industry wide issue.   
Gzip, and client side in general.

Trust me, I was just as suprised when I first learned this myself.

It just took me a while to set up a virtual test environment to be  
able to see it first hand. Try running a fast track mass client side  
attack on a vulnerable xp client.

Something like 80 exploits and barely any detection from any IDS :(

If the 2.8.6 code can do a better job here we can ALL sleep a lot  
better moving forward.

-Seth

Sent from my iPhone


On Mar 23, 2010, at 8:58 PM, "evilghost () packetmail net" <evilghost () packetmail net 

wrote:



Judging from Joel's response evidently Mike is spot-on, which just
caused my jaw to drop.  Are you serious?  You seriously didn't support
gzip encoded data until 2.8.6?  I'm really trying to refrain from  
using
profanity here.  The deeper and deeper the community digs the more and
more Sourcefire gets exposed as the snake-oil salesmen they really  
are.

I'm sure that statement will ruffle your feathers but take a step  
back.
How the heck can you claim to protect this, lead this, #1 this, look  
the
security community in the eye and peddle your product, and not handle
HTTP/1.1 gzip encoding?!? (look, you even caused me to use excessive
punctuation)

That's fscking pathetic.  Modern HTTPDs don't seem to have issues
managing gzip encoding.  "Processing power" being the excuse for not
implementing this is equally as pathetic.  I really hope Joel is  
wrong here.

I'm sure some of you SF guys are gnashing your teeth and shaking your
fists but take a step back and think about this.  Not supporting gzip
encoding?  Seriously?  Since I've grown acustom to the dangling  
carrots
which tend to rot how about a new feature in the upcoming "Wiki"  
titled
"Glaring Limitations You Should Be Aware Of".  We'll add SMP support,
gzip encoding (pre 2.8.6), and more.

Label me as a troll if you wish but when your bridge is made out of
straw it's pretty easy to get eaten.  Be sure to tell me you're an  
Open
Source/Community friendly solution too.  I'm not sure who I really  
need
to protect my network from, Sourcefire or the attackers.

-evilghost

Joel Esler wrote:

This is a difficult thing to do, as it requires some good processing
power to be able to do this.

--
Joel Esler
Sent from my iPhone

On Mar 23, 2010, at 6:41 PM, Mike Cox <mike.cox52 () gmail com
<mailto:mike.cox52 () gmail com>> wrote:


Wait ... the http_inspect preprocessor didn't decode gzip and match
against the unzipped data until 2.8.6 (and/or 2.8.5)?  If so, this
should have been put in 5+ years ago.  I could be making a false
assumption here which I probably am because I can't imagine that
snort didn't do this before now....

-Mike Cox

On Tue, Mar 23, 2010 at 5:27 PM, Joel Esler <joel.esler () me com
<mailto:joel.esler () me com>> wrote:

   Will,

   I'm not saying that 2.8.6 will solve these problems, but it
   definitely will help.  For example the following is new
   functionality (and/or keywords) either in recent versions of
   2.8.5 or within Snort 2.8.6.

   (This information comes out of the Snort Manual)

   http_client_body -- The http client body keyword is a content
   modifier that restricts the search to the body of an HTTP client
   request.
   http_cookie -- The http cookie keyword is a content modifier that
   restricts the search to the extracted Cookie Header field of a
   HTTP client request or a HTTP server response
   http_raw_cookie -- The http raw cookie keyword is a content
   modifier that restricts the search to the extracted UNNORMALIZED
   Cookie Header field of a HTTP client request or a HTTP server
   response
   http_header -- The http header keyword is a content modifier that
   restricts the search to the extracted Header fields of a HTTP
   client request or a HTTP server response
   http_raw_header -- The http raw header keyword is a content
   modifier that restricts the search to the extracted UNNORMALIZED
   Header fields of a HTTP client request or a HTTP server response
   http_method -- The http method keyword is a content modifier that
   restricts the search to the extracted Method from a HTTP client
   request.
   http_uri -- The http uri keyword is a content modifier that
   restricts the search to the NORMALIZED request URI field . Using
   a content rule option followed by a http uri modifier is the same
   as using a uricontent by itself
   http_raw_uri -- The http raw uri keyword is a content modifier
   that restricts the search to the UNNORMALIZED request URI field
   http_stat_code -- The http stat code keyword is a content
   modifier that restricts the search to the extracted Status code
   field from a HTTP server response.
   http_stat_msg -- The http stat msg keyword is a content modifier
   that restricts the search to the extracted Status Message field
   from a HTTP server response.
   http_encode -- The http encode keyword will enable alerting based
   on encoding type present in a HTTP client request or a HTTP
   server response

   We also have the ability to uncompress the compressed data in
   gzip in http_inspect now:
   inspect_gzip: This option specifies the HTTP inspect module to
   uncompress the compressed data (gzip/deflate) in HTTP response.

   Just some of the new options.

   Joel

   On Mar 23, 2010, at 6:16 PM, Will Metcalf wrote:


Joel,

What of these potential evasions are addressed specifically by

   2.8.6?

Unless snort has made fundamental changes to the way it operates I
think these issues will be very difficult to overcome but as I

   said,

these are not snort specific issues. There is a reason why most

   NIDS's

commercial or otherwise are blind to this stuff, it's because
client-side is a really freaking hard problem to solve.  This is
especially true at multi-gigabit speeds, even if you are sporting
latest 32 core xeon 55xx server or something.

Regards,

Will
On Tue, Mar 23, 2010 at 4:51 PM, Joel Esler <joel.esler () me com

   <mailto:joel.esler () me com>> wrote:

I would encourage a look at the new http_inspect in 2.8.6.

--
Joel Esler
Sent from my iPhone

On Mar 23, 2010, at 5:11 PM, Will Metcalf

   <william.metcalf () gmail com <mailto:william.metcalf () gmail com>>  
wrote:



1) sid:15013 will only set the flowbit if I download the PDF

   from a

webserver (alert tcp $HOME_NET any -> $EXTERNAL_NET

   $HTTP_PORTS).

What if the malicious pdf is sent via email -- or another

   method?

16490 will never even run because the flowbit is not set.

   Right?


2) From sid:16490, I gather that it will only trigger if the

   malicious

PDF communicates with an external webserver on an HTTP_PORT

   and the

exploit is then sent from that server (alert tcp $EXTERNAL_NET
$HTTP_PORTS -> $HOME_NET any -- flow to server).  Is that

   correct?

What if the malicious PDF is configured to communicate on a non
HTTP_PORT with the malicious webserver.


Or if encryption is used, or if the client side exploit isn't
contained within the first x bytes of the payload you have

   configured

for flow_depth, or if the client side exploit can be encoded in
javascript, etc. etc. etc.  This isn't a snort specific

   problem all

network based IDS's suck at detecting client-side exploits.

    They just

aren't the right tool for the job, despite what your vendor

   my share

with you via their marketing slides ;-).


This brings me to a question.   What are most of you doing for
443/tcp.  Do you include it in your HTTP_PORTS variable or

   not?   By

default I believe it is NOT included.   Wouldn't this mean that
another really easy way to avoid detection of this particular
vulnerability being exploited would be to have your

   malicious pdf

connect to port 443 instead of 80 outbound?  (In metasploit,

   setting

LPORT to anything aside from 80?)


But you are filtering egress traffic right?  And using a proxy to
enforce protocol behavior right? Also you have sort of

   ASLR/buffer

overflow type protection on your clients right? Via some Host IPS
product or something like EMET?




   http://www.microsoft.com/downloads/details.aspx?FamilyID=4a2346ac-b772-4d40-a750-9046542f343d&displaylang=en
   <http://www.microsoft.com/downloads/details.aspx?FamilyID=4a2346ac-b772-4d40-a750-9046542f343d&displaylang=en 




Regards,

Will




    
--- 
--- 
--- 
--- 
------------------------------------------------------------------

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-sigs mailing list
Snort-sigs () lists sourceforge net

   <mailto:Snort-sigs () lists sourceforge net>

https://lists.sourceforge.net/lists/listinfo/snort-sigs




   --
   Joel Esler
   http://blog.joelesler.net



    
--- 
--- 
--- 
--- 
------------------------------------------------------------------
   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-sigs mailing list
   Snort-sigs () lists sourceforge net
   <mailto:Snort-sigs () lists sourceforge net>
   https://lists.sourceforge.net/lists/listinfo/snort-sigs



--- 
---------------------------------------------------------------------

--- 
--- 
--- 
---------------------------------------------------------------------
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-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs



------------------------------------------------------------------------------
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-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
Previous By Date Next
Previous By Thread Next

Current thread: