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

[ArcSighter Elite <arcsighter () gmail com>]

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

Rikard Carlsson wrote:
> Hi!
>
> I have done the same many times. I don't think that you have done
> anything wrong,
> but that you ask the wrong questions. But it all depends of what kind of
> service 
> you have marketed yourself as and sold IMHO. If you market your services
> as a 
> penetration test and that you should check the customers network (or
> segment) you
> SHOULD try to get access. Doesn't really matter how. If you succeed,
> then the 
> customer is vulnerable. I used to work for a company that marketed it's
> services 
> as penetration test and that we would identify all known vulnerabilities
> (yeah, 
> it's a bold statement that is hard to fulfill, but marketing guys....).
> I or we 
> used to find new vulnerabilities during engagements. We used to do like
> this, we 
> told the customer that they were vulnerable to a "new", previously
> unknown, 
> vulnerability. We told them that because of that, there are no public
> patches and 
> we used to try to provide them with either custom patches or
> workarounds. We would 
> then contact the vendor and provide them with all the information and
> RFP's policy 
> etc. Of course, we told our customers that we would contact the vendor
> and provide 
> them with more information ASAP.
>
> What would happen if you didn't use you knowledge and didn't use the
> "new" vulnerability?
> Would you have done a proper Penetration test? IMHO no. I know that some
> companies 
> and some shady agencies offer penetration tests but doesn't inform the
> customer if 
> they find a 0-day or if the customer is vulnerable to a 0-day. But have
> the customer
> received what they pay you for then? The customer engage you to find
> vulnerabilities 
> (if you do pentests) and then they should get the info. Should you let
> your customer 
> Be exposed to a vulnerability without knowing it? If you find it someone
> else might.
>
> My 2 cents
>
> /Rikard
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> On Behalf Of ArcSighter Elite
> Sent: den 12 januari 2009 14:32
> To: pen-test list
> Subject: Using 0days as part of pen-test?
>
> * PGP Signed by an unverified key: 01/12/09 at 14:32:02
>
> 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.
>
> * ArcSighter Elite (ArcSighter's PGP Key) <arcsighter () gmail com>
> * 0xF70843C7 - Unverified(L)

What is was asking for is the most ethical way to proceed in here.
Because the flaw isn't public, I think most pen-testers won't find
anything on that host, but the host is in fact vulnerable.
If I report the client I will break the vendor's contact. If I don't,
I'm not feeling well with it, and eventually they could be attacked.
So, providing a mitigating factor was the issue in here.
As far as I can see, although is vulnerability-specific, the flaw
affects several parts of the code, so providing a custom patch, well,
first, isn't my work, and secondly, it will never have the quality of a
vendor-deployed patch, because they have access to the source.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklsqUIACgkQH+KgkfcIQ8fBTQCZAW+HpjdyHsDay/3MJ7kSosoE
IucAoO6DYGttT02bK0farOnKj0qOW0JL
=4klS
-----END PGP SIGNATURE-----