" like stuxnet which is
the direction the cool work seems to be going"

i'm giving a talk about stuxnet next week here in Tehran which a part of it
is the Story of how CIA exploited and implanted backdoors into Soviet gas
pipe-lines and cause massive explosion in 80s , openly admitted by CIA and
U.S Army seniors at the time , all public info . this is actually not a cool
work . its old news . surprises are for those who do not read history , the
ones who doomed to make the same mistakes . all respect to Dave , i do not
think exploits are that important . its "the stupidity" that's important .
its not vulns that are essential to find and turn into exploits, its
commercial , its going on for many years on different forms yet same idea .
its the stupidity we should root out . that's hard , really . putting a
bunch of 0days is not .

-mh



On Thu, May 12, 2011 at 2:45 AM, Val Smith <[email protected]>wrote:

> > it comes down to this: Exploits are important.
>
> For sure, I def use them, and if your doing things like stuxnet which is
> the direction the cool work seems to be going imo vs PCI audits, you
> need something at least exploit-like.
>
> > But that doesn't challenge an organization's assumptions. People
> > expect to get lied to. And they expect misconfiguration and lacking IT
> > management.
>
> IDK about this, in my experience every company I have done work for
> expects someone to throw a buffer overflow at them and so they put a ton
> of resources into IDS & overflow signatures as well as firewalling off
> services. Except that when I do IR for them, this is almost never how I
> see them get hacked. (with the exception of browser bugs) When I talk to
> them about other methods they are usually mystified.
>
> > Exploits provide 3 major assumptions to attackers:
> >
> > 1. The attacker is ring0 on any machine they can execute binary code on
> > 2. The attacker can execute binary code on any machine they can
> > convince to connect to them (say, a browser)
> > 3. The attacker can execute binary code on any machine they can get to
> > execute interpreted bytecode (say, a PHP interpreter, or Python on
> > Google App Engine, or Adobe Reader)
>
> 100% agree with above, very well put and very true.
>
> > So yes, even though as Val Smith say, learning a complex toolset like
> > an attack framework requires significant time investment, if it can
> > get you root once, when otherwise you'd have to fiddle around guessing
> > passwords and leaving logs, it's well worth it. :>
>
> I can't speak to what Mitnick does but a couple of things:
>
> - I wonder how many blackhats are using frameworks? And I don't mean
> specific custom toolsets that they write themselves, because I do that.
> In my experience none unless  they want to look like a pen tester. Note
> that frameworks != exploits. I use exploits all the time, especially
> 0day but in very specific ways and as a part of a larger activity.
>
> - As far as leaving logs, I've only ever been detected once that I know
> of, and it wasn't via a log but by a monitored egress port, my bad.
>
> - Fiddling around guessing passwords is something I mostly do for school
> competitions like nccdc. Gotta give the kids a chance you know ;)
>
> - Generally our engagements involve a lot of deep learning some
> proprietary system better than its developers know it, reverse
> engineering, reading code, system integration, development, protocol
> stuff, traffic analysis and P.I. like leg work. But we are definitely
> involved in a different class of "testing" than regular "coverage"
> pen-tests (as jcran so succinctly put it) where frameworks are totally
> appropriate.
>
> - A large portion of the time I don't care about root, I care about
> data, and usually its a regular user account (which is less monitored)
> that has access to it.
>
> So don't mis-understand; exploits and frameworks are important and
> useful, just less so for the type of stuff I do than they used to be.
>
> V.
>
> _______________________________________________
> Dailydave mailing list
> [email protected]
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
_______________________________________________
Dailydave mailing list
[email protected]
https://lists.immunityinc.com/mailman/listinfo/dailydave

Reply via email to