From: Pete Herzog (listsisecom.org)
Date: Wed Jul 16 2008 - 10:16:18 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Makes me wonder what kind of work other people are doing! Wherever I've
worked, security consulting followed penetration testing and in that
consultancy we advised the client. We had little time to test the security
let alone actually exploit anything so that if we couldn't provide a trophy
from some major bump and jump we could still report effectively on how
exposed they were to business losses caused by competitive intelligence, HR
leaks, client leaks, and of course poor use of system controls. The root
shell was nice to have if we could get it but it was not our priority and
it definitely was not what we needed to inform the client of their
problems. And if they chose not to fix them then that is their choice on
how to manage risk. I've seen pen-testers flip out because the client's
tech staff chose not to stop using email address names for extra-net
logins. They felt the risk wasn't there. That's actually their decision to
make because I don't see their balance sheets and I don't know their
business strategy and in the end it's their gamble to make. They have my
report and my notes and my tests. I can't do more.

Isn't our top job to thoroughly audit the security and safety of assets and
properly report. Properly protected infrastructures do not require
patching to maintain security. Therefore we shouldn't do free (for the
development company) Q&A on shrink-wrapped software as part of the job. We
should always assume that shrink-wrapped software, even up to the latest
patch level, will still have holes so we need to make sure that even if
exploited, proper controls assure nothing is lost.

I like the idea of a certification on writing exploit code. I think
there's a lot of q&A jobs where that would be a good fit, even on a
pen-testing team. You should team up with the OSVDB guys to offer
something less vendor-centric though. Of course you could always work with
ISECOM too....

-pete.

Dino A. Dai Zovi wrote:
> 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
> <valsmithoffensivecomputing.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 <tqbfmatasano.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
>>> Dailydavelists.immunitysec.com
>>> http://lists.immunitysec.com/mailman/listinfo/dailydave
>>>
>>
>>
>> --
>> ******************************************
>> * Val Smith
>> * CTO Offensive Computing, LLC
>> * http://www.offensivecomputing.net
>> *******************************************
>> _______________________________________________
>> Dailydave mailing list
>> Dailydavelists.immunitysec.com
>> http://lists.immunitysec.com/mailman/listinfo/dailydave
>>
> _______________________________________________
> Dailydave mailing list
> Dailydavelists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
_______________________________________________
Dailydave mailing list
Dailydavelists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]