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

[Aarón Mizrachi <unmanarc () gmail com>]

El Monday 12 January 2009 09:02:02 ArcSighter Elite escribió:
> Hi list.
> I'm rather new to responsible disclosure, so experts may found silly my
> question, but I've founded pretty interesting, so please keep reading.
>
> A few days ago, I've identified a vulnerability in some closed-source
> vendor's ftp server.
> Then, days later I was requested to do pen-test against a company. While
> I was information gathering, I've managed to identify that third-party
> ftp daemon in one of the company's external hosts.
> I wasn't pretty sure how to proceed in such a situation, but I've fal to
> the temptation and exploited the flaw. That led to a 20-mins entire
> network compromise, and of course proved that the network was vulnerable.
> After doing that, and thinking about what I've done; I wasn't that happy
> about my results.
> First, I got the issue of how to report this vulnerability to the
> company, without breaking the -intermediary- vendor contact and
> agreement; because the vulnerability exists and its exploitable as I've
> proved, but it wasn't general public knowledge the flaw is present.
>
> I know I've braked a lot of phases of any pen-test framework, but IMHO a
> blackhat will proceed exactly this way: they'll exploit the network
> through its weakest link, and is my task to protect the company from the
> blackhat, not from pen-testers (at least not the evil ones).
>
> Secondly, the flaw provided me with enough information that otherwise
> will take me a lot longer to achieve; so I felt the audit process has
> been somehow compromised.
>
> I think I've been clear enough, if I haven't just ask for more info.
>
> What's the most ethical way to proceed in such a situation?
>
> Sincerely.


On pentesting there is no more one or zero (penetrated or not penetrated), you 
must also include non-success attemps and the risk evaluation of everything 
that you see, including "future vulnerabilities". That could help you to make 
a better security plan.

Just imagine that you are a auditor and you dont know this vuln (and many 
others). Your objetive is to protect the system against known and unknown 
vulnerabilities... That could be reached even if you dont know about new zero 
days. You may use confined enviroments, network perimeter, user policies, 
assuming that every service is potentially vulnerable.

I dont know the license of this ftp software, and how you have discovered that 
vuln. I think that you must follow the legal way to disclose the vuln (inform 
to vendor, wait, and disclose). Until you done the disclose you can't DOCUMENT 
this vulnerability on any pentesting...

But, document it doesnt mean "use it"... I agree to use this vuln on 
pentesting. 

Why? 
_____
Every service have unknown vulnerabilities and zero days in third party hands, 
then a weak system aren't only a system that have known vulns, the system must 
have extra protections and containters for every service provided... specially 
if this is a public service.


The pentesting need to have well documentend and reproducible scenario... ?
_________________________________________________________________________

That is a good premise for common tech documentation, but, ethically you can't 
release any further information of the vulnerability until you complete the 
disclosure proccess (it's a delay, sometimes unacceptable delay).

Personally i think that you can release the document without detailed 
information about explotation of that particular service, including a promise 
of document upgrade when the disclosure proccess ends. Then you can focus the 
protection view and weakness evaluation on general service hardening "howto" 
(networking permiter, user perimeter, enviroment perimeter, stack protection, 
crypto, etc)...