Re: Immunity Certified Network Offense Professional

["Dino A. Dai Zovi" <ddz () theta44 org>]

Believe it or not, there are still operations people in this world who
will not properly prioritize a security vulnerability unless they are
properly shown its ramifications.  Telling someone that a three tier
architecture with the web tier on the DMZ and the application tier on
the internal network is risky may not be enough to drive the point
home.

Finding and exploiting an 0day vuln in the app server and being able
to call the admin up and tell him that you have a remote SYSTEM shell
on it from the Internet makes the point much better.  After they pick
the phone back up, they usually start doing whatever it takes to fix
the problem as soon as possible.

Without vulnerability exploitation skills, effecting that change would
have required a political battle and I'm distinctly better at
exploitation than politics.

-Dino

On Tue, Jul 15, 2008 at 2:38 PM, val smith
<valsmith () offensivecomputing net> wrote:
> I'm going to have to award the point to Thomas here. The scenarios he
> presented are very often what I get myself. Super compressed time
> frame, unlikely to achieve goal so any time I spend developing tools
> or exploits is time I lose achieving the goal.
>
> I've also recently had an app test where I had something like 6 hours.
> There was no way (for me cause I suck) to come up with working exploit
> in that time, but I was able to find half a dozen bugs and report
> them. In this case knowing how to write an exploit wouldn't do me much
> good.
>
> However I'll have to say i've run into maybe 1 place in the world
> where getting access to 1 host didn't get me much. (mac locking on
> ports, 1 time passwords everywhere, no shared admin accounts, or admin
> from console only, lots of vlanning, etc.)
>
> Cheating is what its all about. I have this think I call the cooking
> show hack. You know in a cooking show how they make the food and put
> it in the oven then pull one out already cooked and try it. Same thing
> but with rootshell :)
>
> Fuzzy kiddies just sounds wrong man, just wrong.
>
> V.
>
> On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek <tqbf () matasano com> wrote:
> > >  Anyone can fire a fuzer, find a bug and tell their client about how
> > >  exploitable it is.
> > >  People then will talk about ret-to-libc and malloc tricks that really
> > >  don't work anymore in modern systems.
> >
> > This is NO DOUBT true. It is obviously much HARDER to exploit modern
> > memory corruption flaws than it is to find them. Respect, yo. S'all
> > love in here.
> >
> > The problem is, it is not MORE VALUABLE to exploit memory corruption
> > flaws than it is to find them. Consider two scenarios:
> >
> > (1) A shrink-wrap software pen test, for a vendor or a customer ---
> > the target is one application. You have 5 days. Unless you think you
> > can sweep 500,000 lines of C code clean of vulnerabilities in 40
> > hours, an hour spent on exploit dev is an hour not spent finding
> > vulnerabilities.
> >
> > (2) A network penetration test. You have 5 days. Unless you have found
> > the zero enterprises in the world where access to their network
> > doesn't immediately offer up 30 different mass casualty scenarios, an
> > hour spent on exploit dev is an hour not spent breaking into systems.
> >
> > We could go back and forth on (2) --- no doubt there are NPT's where
> > being able to bust CreateProcess in some sleazy Windows backup
> > software is going to win the game for you (there are also NPTs where
> > the client says, "tell me about the zero-day mass casualty exploits
> > you could have run, but don't stop testing until you get in without
> > cheating").
> >
> > And another thing: we all know about the "fuzz kiddies", but that
> > doesn't make all vulnerability research a matter of aiming /dev/random
> > at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx]
> > findings. Plenty of people cheat at writing exploits too.
> > _______________________________________________
> > Dailydave mailing list
> > Dailydave () lists immunitysec com
> > http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
>
> --
> ******************************************
> * Val Smith
> * CTO Offensive Computing, LLC
> * http://www.offensivecomputing.net
> *******************************************
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave