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

[Seth Art <sethsec () gmail com>]

On Tue, 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 ;-).

I hear you on the client side exploits.  That is what I am trying to
get at.    And believe me I am NOT pointing the finger and snort or
VRT for this.  IMHO they are farther ahead that most of the vendors,
but the fact is that client side exploits are "it" right now and have
been for too long.  Either the IDS's need to figure out HOW to handle
these better (As Joel points out snort/Sourcefire is trying to do this
with 2.8.6), OR we need to start doing a much better job educating
people that NIDS and NIPS are not helping much here.

My question to you: What IS the tool to do this.    Will it be the
next round of snort, or does anyone have a better way to DETECT client
side attacks.  I really think that since these are network based
attacks, the industry needs to be a lot more effort into detecting
these with NIDS.



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

Well I am not doing any of these, as I work at an MSSP.    But yes,
lets take some of these to task:

Filtering egress traffic: Easily bypassed in most locations by having
the PDF connect outbound on port 443 or 25.

Protocol enforcement: From the experience I have with protocol
enforcing gateways or inline proxies, they make me want to throw them
out the window.  Also, as you mentioned, this particular exploit could
have easily been configured to connect back on 443 encrypted.

ASLR/buffer overflow protection: I personally do not have any
experience with any of these types of products... You have any names?

HIDS/HIPS -- Can certainly help detect certain things that a NIDS will
miss (encrypted traffic post decryption, right?), but can only detect
again


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

EMET -- Also new to me.   Thanks for the link.   I'll have to look into this.

> 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