Re: Cons and Security Validation

[Dan Kaminsky <dankamin () CISCO COM>]

> I can't speak for Crispin here, but all of the technical staff at WireX
> are very against hack contests, Crispin being one of the leading
> opponents of them.  That's not what he's talking about here.

I actually greatly enjoyed the Argus Pitbull hack contest, precisely because
it offered me an opportunity to test an environment I'd heard quite a bit
about.  I left the event quite impressed, even if there were a few rather
cheap tricks* that I'd never have been able to verify without a live
environment in front of me.  In contrast, the fact that the system remained
secure *in spite of* a few less than functional security elements was quite
impressive.

The Pitbull machines are now gone, wiped from the net.  Not even DNS
resolves.  I can't help but be saddened.  Compaq allows users to
"test-drive" their high-end servers remotely, and Workspot is devoted to
providing a remote Linux desktop to anyone who wants to try one out.
Obviously those servers needed to disappear; that ISP was likely being
hammered due to the nature of the contest.  But there really *is* value to
having the explicitly granted freedom to attack a supposedly-secure
platform!  Perhaps there's something to be said for allowing remote testing
of secure environments without the accompanying burst of empty hype and
subsequent DoSing that contests spawn?

In simple terms, it's not a test drive if you need to show up at the
dealership with your own chassis and engine block.  :-)  Some work would
need to be done to prevent these test systems from being used as vectors for
DDoS'es--simply blocking outgoing connectivity to any IP that doesn't have
an incoming TCP session works--but these are the same problems that
honeypots have had to fix for some time.

Perhaps this model could be expanded further.  Sourceforge provides compile
farms for verifying the functionality of code; perhaps registered users /
sponsoring companies could request temporary access to a set of machines
that could be arbitrarily imaged across OS'es(Redhat 4.2, Immunix, OBSD,
W2K), Daemons(BIND x.y.z, IIS, SendMail, etc.), or whatnot and subjected to
an arbitrary series of vulnerability exams using the newly developed code.

I have absolutely zero qualms with the recent Trojan posted on Bugtraq
actually getting through moderation.  It should not and must not be the job
of the moderation system to verify the *content* of posts, only the subject
material.  But if most vulnerability announcements came posted with a signed
and detailed vulnerability matrix (like the excellent one done for the
recent BIND vulnerabilities), the few that didn't would stand out as less
trustworthy and more needing of being run in a secure environment.

Of course, attacks that both attacked as advertised *and* posessed a Trojan
element (the Britney EXE's, for example) wouldn't be caught by such a
system, and indeed would become somewhat more dangerous due to added trust
given to an exploit that had gone through the independent audit.  There's
not really an automated way to detect a trojan, though there are several
imperfect methods(tripwire, etc.).  Some might even argue that providing
"training grounds" to script kiddies gives them a safe environment to hone
their skills before attempting a genuine attack; what if it took no effort
to spawn a new server that exactly matched the one you just got a non-root
shell on?  The same barrier to entry that affects the white hats does hold
back black hats as well.

I don't claim that there's a perfect answer.  The empty hype of hacking
contests, coming from the implication that "if nobody hacked it now, nobody
could ever hack it" is annoying.  But being able to go from zero to test
shell simply by typing "ssh webhack () webhack openhack com" went beyond hype
into a genuinely valuable and useful experience.

Oddly enough, all the DoS'ers tended to focus on shell.openhack.com, leaving
webhack alone for those who actually wanted to explore.  Maybe a useful
function of hacking contests is to separate those who just want to abuse the
system from those who actually want to explore it :-)

Yours Truly,

    Dan Kaminsky, CISSP
    Cisco Systems, Inc.
    http://www.doxpara.com

* "ls -lR 2> forbidden" revealed all files and directories the Pitbull code
was specifically restricting access to, the /proc directory listed all
hidden processes by number, and simple bypass measures like "cp
/sbin/ifconfig /tmp/ifconfig; /tmp/ifconfig" worked.  I still wonder if
binding to 0.0.0.0/80 would have worked on the webhack machine...global
binds take precedence over IP-specific binds, ne?