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

[ArcSighter Elite <arcsighter () gmail com>]

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

David Howe wrote:
>   Do you have a remedial/workaround you can offer them? 

Of course I could develop one custom patch, but as far as I can see the
vulnerability affected several paths of the code, so I might be
missing/introducing bugs with the patch. Developing a really secure
patch will take time, maybe even more time that it will take to the
vendor, who's in posses of the source. Time I normally don't have, by
the way.

> If so, all I can
> suggest is that you document it purely as "vulnerable to undisclosed
> attack <randomly chosen four digit number or embargoed CVE/CERT number>"
> and add the workaround; if they query it, just say that you are
> contractually obliged to not disclose the vulnerability, pending a
> vendor response and patch rollout. It can help if you can imply (without
> stating) that you are licensing undisclosed 0days (would that be a
> -1day?) and hence that your service offers a "deeper" check than you
> could get as a skilled amateur without "contacts" in the field.

It doesn't seem pretty ethical to me the CVE-stuff. But you got a point
of only reporting them they're vulnerable to an undisclosed, but then
how they fix?

>   The real question there though is that, modulo that 0day, could you
> have compromised their network? or did you drop everything else and rush
> in to expand your bridgehead?

My audit hasn't finished, as I said, I skipped over a few things when I
identified the vulnerable software, that's what I was talking about.
But the fact is that even when I finish, it doesn't seem good to me to
omit the 0day.

> Well, you should really eliminate any information you could not have
> gotten some other way, then do a review of their security on that basis;
> Really, the best *anyone* can do in a pentest is "without knowledge of
> vulnerabilities not known in the art (undisclosed 0days) this network is
> secure" and that is *always* true. For any network, however secure,
> there could (and will be) some as yet undocumented vulnerability that
> will render it a decorative bandaid not a security solution.

Pretty interesting. That's exactly how I've approached until I got into
software vulnerability research.

> Your dilemma really is that, on the basis of privileged information
> not available to an average attacker, you *can* compromise their
> network, and you (as a paid consultant) owe a duty of care to that
> customer to block or reduce that exposure as best you can; note that you
> can require (of your customer) that certain parts (or all) of the report
> be treated under NDA (that is routine anyhow) and usually, you can
> phrase the remedial action in a way as to make it hard to
> reverse-engineer the original 0day from it (recommending a substitute
> free ftp product if that is not a special case platform, even if only as
> a temporary solution until the vendor "catches up")

An attacker who knows about the flaw, will get access to the same
information I've gathered. I don't trust the term *average* attacker
these days, IMHO distributed attacks against companies aren't taken down
by script kiddies these days.
Revisiting the patch topic, providing them with a custom mitigating
factor seemed to be the most accessible solution, as far as I can see,
so I will provide them with the so-called custom-patch that fix the
SPECIFIC issue - anyway, I haven't programmed it, right?- and IDS
signatures.





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

iEYEARECAAYFAkls10MACgkQH+KgkfcIQ8c1MACg0dVwcaRoav39+7FqV3g6wAL7
xL0An0BP+MWcWznYE+wK1HtsbO+T7q29
=XaX5
-----END PGP SIGNATURE-----