I understand the issue of using 0-day in a penetration test. I've come
across the same issue a couple of times. Including finding 0-day exploits
whilst performing a test. In most cases I've gone ahead with exploitation
of the system using the undocumented exploit and gone on to check the
security of systems beyond that point. In the final report (the most
important part of the test) I make sure to detail the fact that the
exploit was not yet publicly known (and any available mitigation
information). This should depend on the client however, as if it's not a
publicly patched exploit, then you should ensure an NDA is in place before
revealing the details. If no NDA is in place, then I would give brief
detail, but not specifics (shellcode, etc...).
It's important to let clients know that defense in depth is the only real
way to protect from 0-day exploits. If the security of the network you
tested was well planned, then your exploitation of the FTP server would
only have provided you access to selected systems (contained in the DMZ).
A penetration test is all about layers of defense, and if a single exploit
can bring down the entire network, then even if this exploit isn't public
(as far as you're aware) then the company needs to know where the security
falls down.
Personally I'm a big fan of testing different scenarios, instead of always
relying on the "outside in" model of classic penetration testing. I'm
willing to bet that 75% of companies are relying on the perimeter security
(be that firewall or DMZ systems) to protect the entire network. Once
you've passed that boundary (exploit a server in the DMZ, crack a VPN
password, insert other attack vector here) then you have full access to
the internal network.
Just my 2 cents.
Chris John Riley
listbounce_at_securityfocus.com_at_inet wrote on 13.01.2009 06:52:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJa0ZSH+KgkfcIQ8cRArj7AKD7hZCFOk+GBdkQ+v271wckKA8ECACgjWqR
> U1rhxUzEw6Z+Q7P7Vxwe9mc=
> =5m9Z
> -----END PGP SIGNATURE-----
>
>
----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, DVR 0486809, UID ATU 16351908
Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden.
Correspondence with above mentioned sender via e-mail is only for information purposes. This medium may not be used for exchange of legally-binding communications.
----------------------------------------
Received on Jan 13 2009
Intro
