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

[ArcSighter Elite <arcsighter () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aarón Mizrachi wrote:
> 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)...

Sorry if my post led to misunderstands, but I've been around pen-testing
for quite a while. Of course, I'm doing a security audit as you probably
are accustomed to do.
What was interesting, and maybe I didn't gave enough importance in my
post, it's that the fact I was dubious about was the responsible and the
ethical issues with the company that requested the pen-test, and the
vendor of the vulnerable software. That's what I asked, and reading your
post some are useful but others assume that I didn't audited properly,
which isn't the case.

Aaron's reply pointed something that was my initial feeling, where he says:

"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)." - already
done, they've based a time-line for releasing a patch -.
"Until you done the disclose you can't DOCUMENT this vulnerability on
any pentesting..."

That's what initially made me post, sorry if I haven't putted this way,
but that's what I'm talking about.

As a said, in the meantime I provided them with updated IDS signatures,
and recommended to switch to another ftp server; based on the fact is
not a very hard service to replace.


Sincerely.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklveBQACgkQH+KgkfcIQ8eyxgCePGzagtpX+sp5g2dMl1NceArl
Rl8AniPBGbcwcY3SkSMSeiQbM33gKkRd
=y/co
-----END PGP SIGNATURE-----