Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17

[Joel Esler <joel.esler () me com>]

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> 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> 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>  
> 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 
> > 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
> >>>
> >>> 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
> >>> 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
> 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