Re: Arbor-con

[ned <nd () felinemenace org>]

On Tue, 20 Jul 2004, dave wrote:

> So I was able to shoot to the Arbor-con today and I'm posting my 
> comments here.
>
> Arbor's product (for those of you who haven't seen a demo) is based on 
> the following use case (note: I don't speak for Arbor. I'm just 
> replaying the demo as my misguided brain saw it for you in case you want 
> to read them):
>
> 1. Arbor's network engine sits on various points of your network or 
> recieves netflow data for a while, recording normal traffic
> 2. It corrolates that traffic and models it, so it can say "this host 
> talks to this host on this port". It can group hosts, etc.
> 3. You can use a really slick web-based portal (IE only, I think) to 
> view/search/etc this data (this is pretty cool in and of itself) (parts 
> of the product are python, but I'm not sure what parts)
> 4. If you are getting hit by a worm, you can say:
>    o For service getting hit by worm, make the network look like it did 
> last week (i.e. only hosts that should talk to each other are allowed to 
> talk to each other)
>    o This is done by automatically generating ACLs and shoving them out 
> to your network infrastructure (switches, firewalls, etc)
>    o You can manually review and edit these ACLs, but imo, this is a 
> management nightmare waiting to happen, so most likely you'll just click 
> "go" to make your network start working again as if there was no worm
>    o You can whitelist hosts and say "never block our trading server no 
> matter what"
> 5. They have a learning mode and a learned mode. If a new host pops up, 
> its actions are unrestricted by the host behavior heuristics
> 6. There is also a flow-rate heuristics engine for doing worm detection. 
> The interactions between these two heuristic engines are somewhat lost 
> to me, however, and a likely place for someone to poke at.
> 7. Like any enterprise product, the cost is highly variable. I'm 
> assuming 6-7 figures.
>
> The use case is fairly interesting, and obviously applicable to 
> traditional intrusion detection/prevention. I think there are other 
> avenues that wern't discussed, of course, like automated attack/worm 
> packet signature development and deployment. (hmm. This host A seems 
> infected, it spewed string ABCD at host B. Then host B started doing the 
> same thing. Let's block all packets with string ABCD on that port from 
> any host to any host). I quite like the idea of doing packet-size (or 
> flows of packet sizes) recording as well, and using that as attack 
> signatures, since it's really easy. Sizes are cheap hashes usually.
>
> After Jose talked, and Arbor demonstrated their product, there was a 
> panel discussion with Dug Song (Arbor), Greg Shipley (Neohapsis), and 
> Dave Meltzer (Intrusec).
>
> One other thing I was thinking about is that (as Jose Nazario noted) 
> there are actually very few worms coming out, given the number of 
> wormable exploits that come out every day. In Jose's model 
> "exploitability" comes into play to determine that exploits. I'm not 
> going to debate his model. Any model is fine. But what I would like him, 
> or someone else to do, is to say that for X exploits on Windows last 
> year, we had Y worms. The model should "predict" this, at least 
> reasonably closely. Then all you have to do to predict a post-SP2 world 
> is drive exploitability down a lot. My intuition is a 0-worm world 
> post-SP2 (assuming SP2 gets ported around to the other OS platforms, 
> which it no doubt will.) Of course, getting SP2 (and the chips it needs 
> to run N^X) into significant acceptance is a 5-year job, optimistically.

i would hold off assumptions about SP2 till it actually comes along. the 
fact remains (and you can attest to this) that msrpc is still very, very 
buggy, and those bugs will still remain, regardless of some overflow 
protection. jamie butler showed how easy it was to defeat third party 
overflow protection in the latest phrack, so how can we be sure there's 
not a simple way to bypass SP2 protections. lsd did it with 
2k3...wait...everyone managed to do it with 2k3.

> Linux, of course, is already there. I predict no worms which 
affect 
> Fedora or any host running execshield (a watered down version of PaX, 
> but it comes by default!). You can still write exploits for them, but

i believe your paper was aimed at making a 'smarter' worm. could the 
smartest possible worm be one that defeats execshield? all we need is a 
remote in apache, some __basic__ trickery and a few decent 'missions' 
(great buzzword!) to complete and we have a smart, quick and potent worm.

> worms, as predicted by the model, are unlikely to happen. > 
> When I say worms, of course, I'm not talking about things that need 
> people to click on them, or client side attacks. For that, you'd need 
> grsec-level capabilities, which isn't scheduled until longhorn. Mail 
> worms are easily filtered on the mail server anyways.
>
> Anyways, hopefully this was at least moderately interesting to someone. :>
>
> -dave
> P.S. When worms go, so do IT security budgets. I predict a collapsing 
> market.
>
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://www.immunitysec.com/mailman/listinfo/dailydave

-- 
http://felinemenace.org/~nd

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave