March 28, 2005

Hacker Contests: Why they are Useless

Ok, this bugged me enough that I figured it was worth blogging about.

Recently Symantec released a report in which they said:

"It is now clear that the Mac OS is increasingly becoming a target for the malicious activity that is more commonly associated with Microsoft and various Unix-based operating systems."

In retaliation for such comments Mac and iPod peripheral maker DVForge Inc. sponsored a US$25,000 prize to be awarded to the first hacker who could infect two Macintosh computers owned by the company. Less than a day later the company announced the cancellation of the contest, citing legal concerns.

This is just nuts. Do people live in a vacuum? Absolute security is a myth. It doesn't exist. A determined adversary with enough resources and a reason to compromise a target will do so. Point of fact. The trick is understanding what "enough resources" is. It's probably not the script kiddie next door that a contest like this would attract. But it could be the signal intelligence community of a foreign government. Or a corporation probing for competitive intelligence. Knowing your attacker is the first step in understanding the real risks you are exposed to in the digital divide.

And here is the kicker. When it comes to this level of espionage, the adversary is NOT going to show you it can be done for $25K. Or $500K. Why? Because at this very moment any new vulnerabilities that can be used as an attack vector will stay quiet. The Window of Exposure will continue to impact on the potential attacks until which time someone of a higher interest steps in.

And who would that generally be? A security researcher who wants his name in lights for finding the 'next greatest hole'. He doesn't typically do it for contest money. He does it for fame, in turn giving him access to money. Now don't get me wrong, I think researchers who follow proper disclosure methods are a god send. They are a vital part of the information security industry. And many of them are part of good research teams (like Symantec) who have the authority to talk about such things. So in the end, all Campbell did was drum up some publicity for himself and his company. He did nothing to help the security industry... except maybe to make more people aware that OSX is not immune to vulnerability.

Now, I am not taking side on the OS flameware debate. I could care less. But OSX has a base of BSD. And like all of its sisters, it too has vulnerabilities.

So stop fretting about it and making useless challenges that are meaningless. That not only goes for fans of any particular operating system but for security vendors as well. Just because a security product functions properly does not mean it's secure. Just because no one has shown you to be vulnerable does not mean you are not. (Wow lots of double negatives there). On top of that, as the NSA pointed out years ago, security failures in it's area of interest are due to failures in implementation, not failure in the algorithms or protocols. In other words, the weak link here is the human factor which can make something intended to be secure to be anything but.

So here is a real challenge. Grab yourself a white towel, hack the electronics of my HHGTTG book and I will give you a gargleblaster. That's all contests like this are worth anyways.

Posted by SilverStr at March 28, 2005 11:42 AM | TrackBack
Comments

"The trick is understanding what "enough resources" is."

This really got me thinking. Has anyone done research into where exploits originally come from? Not the copycat viruses and script attacks, but the original 'aha! found a new vuln and its exploit!' moment. Much comes from security researchers as you suggest, but it seems to me that the key to the 'sploit may often be handed over by the vendor who publishes a security patch. If there is enough information in the patch or its description to reverse engineer the vulnerability, someone will do it, and take advantage of those who are slow to patch.

The traditional response has been for vendors to try to get users to patch faster. Maybe another approach would work - make the patch harder to reverse engineer. Encrypt it, release less information about the underlying vuln, put red herrings in the patch, and so on. Yes, I realize this is security by obscurity, and raises serious trust issues as well. I ain't saying there is a panacea ... but it may be worthy of a little more thought. Are there ways to obscure the original vulnerability enough to keep it out of the hands of skript kiddees, yet still disclose enough information to preserve the trust necessary to a strong patch/upgrade pipeline?

Posted by: bryan at March 28, 2005 02:37 PM