Vulnerability Development mailing list archives
Re: Cons and Security Validation
From: Dan Kaminsky <dankamin () CISCO COM>
Date: Wed, 7 Feb 2001 00:32:03 -0800
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?
Current thread:
- Cons and Security Validation Crispin Cowan (Feb 06)
- Re: Cons and Security Validation Andrew R. Reiter (Feb 06)
- Re: Cons and Security Validation Crispin Cowan (Feb 07)
- Re: Cons and Security Validation Pavel Slavin (Feb 07)
- Re: Cons and Security Validation Crispin Cowan (Feb 07)
- Re: Cons and Security Validation Blue Boar (Feb 06)
- Re: Cons and Security Validation Greg KH (Feb 06)
- Re: Cons and Security Validation Blue Boar (Feb 06)
- Re: Cons and Security Validation Crispin Cowan (Feb 07)
- Re: Cons and Security Validation Dan Kaminsky (Feb 07)
- Re: Cons and Security Validation Matt Barringer (Feb 07)
- Re: Cons and Security Validation H D Moore (Feb 08)
- Re: Cons and Security Validation Crispin Cowan (Feb 10)
- Re: Cons and Security Validation Greg KH (Feb 06)
- Re: Cons and Security Validation Andrew R. Reiter (Feb 06)
- Re: Cons and Security Validation Crispin Cowan (Feb 07)
- Re: Cons and Security Validation Robert A. Seace (Feb 07)
- Re: Cons and Security Validation Blue Boar (Feb 08)
- Re: Cons and Security Validation Michel Kaempf (Feb 08)
- Re: Cons and Security Validation Blue Boar (Feb 08)
- Re: Cons and Security Validation Pavel Kankovsky (Feb 13)