Re: Using 0days as part of pen-test?

[David Howe <DaveHowe.Pentest () googlemail com>]

Aarón Mizrachi wrote:
> El Monday 19 January 2009 10:04:52 escribió:
> > Shenk, Jerry A wrote:
> > > I'm not sure I agree with this statement.  If I'm testing a client's
> > > app and I find a vulnerability, I don't have any ethical requirement
> > > NOT to tell them.  In fact, they are paying me so it seem like the
> > > (to a degree) own the results of my testing.  In fact, I would give
> > > the client the option to determine how the vendor gets notified. I've
> > > typically given the client full information and let them notify the
> > > vendor and call me in if needed.
> > Seconded. You have no legal requirement (although it's Best Practice) to
> > follow the Responsible Disclosure procedures, but you can make a
> > reasonable case that, if you are being paid by your client and not the
> > software vendor, that you have a duty to disclose any or all material
> > vulnerability information (under NDA if appropriate) you discover during
> > your investigation.
>
> ok, i agree with  your legal statement.
>
> The legal issue isn't the disclosure process, you can act as "legal entity" 
> using the company, and "the company" discover the vulnerability... 

> But the ethical issue... it differs between point of views. I think that  
> disclosure process was not made for share "how to exploit" information to 
> others... The disclosure process just are designed to avoid and minimize 
> security threats (security by obscurity) until the vendor release a patch.

  Sure. Responsible Disclosure is a mechanism designed to protect the
customers of the vendors from the Bad Guys. To do this, there is a
careful balance between giving the vendor time to design and release a
patch for the issue, and the ever present threat that you will release
the information anyhow and create a PR nightmare for them as Bad Guys
stomp their customers into dust and they leave en-masse for competing
vendors that treat their security more seriously.

  However, that has nothing to do with your duty to secure, as best you
are able, the customer who is paying your bills.

> There are too many obscure scenarios of information leakage and exploiting... 
> (corporate spy,  sabotage, criminal organizations, etc). Ethically we must 
> follow the Responsible Disclosure procedure to prevent leaks (even if you 
> signed an NDA). 

Sure. However, its up to you how much you disclose to your client, and a
vulnerability that can be reverse-engineered from a NDA patch is a lot
different from posting that where the world can see it.

> On my responsible point of view, i can disclose (to my contractor) sufficient 
> information of the vulnerability to understand risks and howto protect their 
> systems... But, i will not release a full-disclosure until vendor patch's are 
> done. Then, you can sleep deeply thinking that your exploit wont be used in 
> malicious ways and the company are safetly secured.

Which I think was my original point, yes.

> The pentest audit are intended to prove and discover internal vulns,  and our 
> final objetive is to protect. Our duty is to protect. And we are contracted to 
> protect.

Now that's opening a debate that could last for years :)
I would say that the final objective is to perform a security evaluation
and make recommendations to improve the security posture of the client -
 if they take our advice is up to them; if they decide security is too
expensive, we aren't duty bound to make any further effort.

> The problem is how did you find and exploit those vulns? giving to the app a 
> random or predictable test conditions or debugging the app?. 

Doesn't matter. In order to be bound to their EULA, you need to be a
customer, and to agree to it (if even implicitly by using the product).
If EULAs were legally binding on random inbound connections, MS could
make their product 100% secure from pentesters by including "you may not
hack this product or obtain access beyond that given by design" in the EULA.