Snort mailing list archives
Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17
From: "evilghost () packetmail net" <evilghost () packetmail net>
Date: Tue, 23 Mar 2010 19:58:07 -0500
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® 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® 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® 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® 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
Current thread:
- Sourcefire VRT Certified Snort Rules Update 2010-03-17 Research (Mar 17)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 17)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Alex Kirk (Mar 17)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Seth Art (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Sethsec (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 L0rd Ch0de1m0rt (Mar 24)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Frank Knobbe (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Frank Knobbe (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 17)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Seth Art (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)