Snort mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: Joel Esler <joel.esler () me com>
Date: Tue, 23 Mar 2010 21:57:17 -0400
Mike,

Snort 2.8.6 uncompresses the compressed data (gzip/deflate) in a HTTP response.  You can also specify using 
"compress_depth" and "decompress_depth":  the maximum amount of packet payload to decompress and the maximum amount of 
decompressed data to obtain from the compressed packet payload respectively.

http_inspect supports the "Z" and "gzip" formats.  The gzip compressed data will be decompressed into a buffer, and a 
pointer to the decompressed data is available to perform detection on the decompressed data.  This allows you to use 
the "content", "pcre" and "byte_test/byte_jump" keywords with the compressed data for detection.

Apologize for my short response earlier, perhaps it didn't convey what it needed to.  My point is that this *is* CPU 
intensive.  It's something we didn't do before, we do it now.  We're making (and have been making) great strides at 
non-evasion.  Take a look at frag3, stream5, etc.

That all being said,  all of this is downloadable and found in the information in the 2.8.5.rc on snort.org.  This is 
one of the many reasons why we ask people to test the betas, is to provide feedback on information in the new builds.  
I'm not saying this to say "oh you should have downloaded the beta and found this out!" (Just so no one thinks i'm 
doing that)  I'm saying this to say "this is where the information and code is, so that you can read it yourself as 
well and understand it"

Another keyword that I forgot to mention is "file_data".


From the Snort Manual with 2.8.6, it says:

"This option is used to place the cursor (used to walk the packet payload in rules processing) at the beginning of 
either the entity body of a HTTP response or the SMTP body data."

I am sure we can find some uses for that keyword as well.

Joel


On Mar 23, 2010, at 9:12 PM, Mike Cox wrote:


god if it is true that snort doesn't decode gzip (before v2.5/6) then I might be sick ... I'm missing detecting tons 
of stuff.  Does suricata support matching on un-gzipped data? I could have sworn I saw daemonlogger gzip pcaps and 
then looked and saw gzip decoded snort logs on alerts.  Am I wrong?  Say it isn't so!

-Mike Cox

On Tue, Mar 23, 2010 at 6:49 PM, Joel Esler <joel.esler () me com> 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> 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





--
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
Previous By Date Next
Previous By Thread Next

Current thread: