Monday, April 20, 2009

How do YOU defend against 0day?!


There is an interesting thread over on DailyDave about 0day and what you can do about it.

Its far from complete, so go read the thread and come back...

http://lists.immunitysec.com/pipermail/dailydave/2009-April/thread.html#5673

Thus far Ron Gula's response is the best.

My thoughts on this is that it really depends a lot on the maturity of the environment. Most environments wouldn't stand a chance against even a crappy targeted client-side attack with public vulnerabilities. If you throw in 0day...forget about it But assuming a mature environment, I think you use 0day to test your defenses to targeted and 0day attacks.

Does one 0day totally own your network?

I think using 0day allows you to test:
Are things segregated properly enough that someone popping a shell on a workstation cant get access to "what makes you money"?
Does you HIPS/HIDS stop that stack/heap overflow? Does it stop you from putting new binaries on the box for post exploitation?
Is your AV worth anything? How long before 0day(that eventually becomes public) becomes an AV alert?
Does your network IPS/IDS detect or block the exploit traffic?
Can you detect the outbound traffic? and RESPOND?!
Are your users running with elevated privileges or are your admins doing their regular work with their admin accounts?

that sort of thing...thoughts?
CG

3 comments:

Matthew Wollenweber said...

A good 0day properly used will almost always own a network -- then again recent public exploits will also own most networks.

The first part of Ron's reply is that simplicity is a key to securing a network. That's partially true. Complex things will be done wrong and lead to vulnerabilities. But, say you have a 0day against OWA. You'd be defended if you require a VPN to get to the server. That's added complexity with possibly more security (though quite the opposite if the 0day is for the VPN instead).

The only HIPS that's ever really given me problems is Entercept. Other systems AV/IDS/etc have caused problems but simple enough code changes removed the snags.

Egress filtering can be a problem with proxies, approved internet connected apps, etc. Injecting into one of them is usually enough to open up outbound traffic. I've never seen a DMZ with only the outbound connectivity that it needs.

Finally you ask "Are your users running with elevated privileges or are your admins doing their regular work with their admin account?" I love that question. If I've owned a box and am having problems escalating to anything of value in AD I'll try to be noisy. Usually a domain admin will then remotely log into the box -- so I steal the token and celebrate.

The only "real" solution I've seen to mitigate 0day have been complicated threat model and risk analysis projects. Unfortunately when you start to dig into those things unravel as well.

jcran said...

i was also following this thread quite closely. in my opinion, halvar flake summed it up best:

[paraphrasing here - you should read the original post linked below]

in this order:

1) insure if possible
2) understand there is no perfect protection, and choose protections that are sufficient.
3) minimize attack surface,
understand attack methods, and monitor the systems

http://lists.immunitysec.com/pipermail/dailydave/2009-April/005680.html

v3n0m said...

just one, turn your network off, lolz