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

[David Howe <DaveHowe.Pentest () googlemail com>]

ArcSighter Elite wrote:
> 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.

I wasn't really suggesting that you do the vendor's work for them - I
obviously don't know what functionality you would need to block or
disable in order to render the ftp server less vulnerable to attack.

however, remedial or workaround doesn't' have to mean fixing the
problem. Is the ftp server actually required to be open to the whole
internet? can it be disabled for a few weeks while the vendor gets their
act together, temporarily substituted with another (possibly less
capable) one for a while, or restricted to a predetermined ip list of
customers who *need* access?


> > 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?
You can disclose the vulnerability is in the ftp server, without stating
what it is vulnerable to - see comments above regarding remedial/workaround.

> >   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.

Not suggesting you omit it - just suggesting that an attack not yet
known to the internet at large might not be a fair test of good practice
in their defence - reporting that a network "is insecure" is a far cry
from the more appropriate (obviously, in my opinion :) "Secure against
publicly known attacks, but vulnerable to at least one as yet
unpublished attack that uses <name of ftp server> as a vector" - ok, the
position of the interior is always hard, but if you have to assume that
all packages (even if given a clean bill of health a week ago) cannot be
exposed to the internet because it *might* have an undisclosed
vulnerability, then all you can do is cut the wires, pull up the
blankets over your head and run one, airgapped webserver and mailserver
that you sneakernet files and mail to and from on floppies.

Perhaps you could make two reports - one a generic "your network is
secure against all currently active exploits, unless this report is
accompanied by one or more exception reports under NDA" and a second
"there is an undesclosed vulnerability in ftp package x - you should pay
special attention to package x and its logfiles, increase logging, and
consider using a substitute or restricting access until an official
vendor patch for <cve no> is issued"

> > 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.

Sure. its all you *can* do. However, a security report is even more of a
band-aid - you really, really need to have a security *framework* in
place - so many sites go to sleep behind an expensive firewall solution,
then look really surprised when their certified, pentested,
four-layer-dmz and token-only vpn access outer wall is defeated by
someone handing out free pendrives at the door that install a BHO via
autoexec.inf

> > 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.

The downside there is - The attacker who knows what you know, will get
access to the same information. The attacker who doesn't know what you
know, but knows about a different vulnerability in a different package
of which you know nothing - may well get the same information; you can't
guard against that by locking out every package that faces the web -
that way lies madness. But equally, you can make things more difficult
for an attacker to exploit a breach and spread the initial breakin
outwards; much of this is white box though - reviewing anything with an
open port to ensure it runs with least privilege required, that boxes do
not share a common password (or heaven forbid, that an ftp server
account uses the same password as something more secure, or that ftp
accounts in general don't give access to anything other than ftp) and so
forth. oh, and log *everything* - particularly program crashes, and
whatever access logging is possible - to a secure server that is (from
the POV of the dmz) write only.

That said, most logs are write only. Glod knows, they don't get read....

> 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.

Sure. there is a tradeoff there, and remember, you can always *offer*
such under NDA, and give them the chance to refuse; your duty of care
extends to offering - if they choose not to accept then you can't be
duty bound to force it on them.

But as (on the whole) a consumer of pentesting services rather than a
provider of such, I would take such an offer with both hands, and *then*
ask if the vendor has given a date for an official patch yet.