The Day The Internet Almost Died, No Really!

Had someone with ill intent been as smart or as lucky as security engineer Dan Kaminsky, the entire Internet could have been rendered mostly inoperative. The extent of just how big a fix he implemented, is only now being realized.

There is an entire subculture that has developed around the notion of deconstructing information technology. And like those who prefer to fish in pre-stocked ponds, the people who populate this subculture are not, for the most part, particularly clever. They may be adept with their tools, but they don't construct exploitation strategies for themselves. Rather, they wait until someone smarter can do it for them.

In fact, that's the whole principle behind the "zero-day exploit," which is a bit like hyenas celebrating the availability of low-hanging fruit. Today, it's security engineers who discover the most clever possible exploits in IT systems and software. But it's typically the way those engineers alert software companies and their customers to the existence of the problem, that in and of itself causes the greatest security risk. When the smarter birds of prey can detect from a high vantage point where the ripest fruit has fallen from the trees, the hyenas can easily track them on their way to dinner.

This was the problem with respect to the implementation of one of the largest-scale fixes in the history of the Internet last month: Since 2002, it's been generally known among network engineers that there was probably a way to pollute Domain Name Server caches, using a trick of accurately guessing the source port from which a DNS name resolution would come, and then spoofing that port with a false response that could redirect users to completely different Web sites without their knowledge.

If the spoofed site was a bank, the spoof could ask for and receive user IDs without them knowing it wasn't that bank. If the spoofed site was a customer service site, users would blithely give them their support ticket numbers and license IDs. There was no telling how far this could have gone.

Maybe, just maybe, some users would have spotted the fact that the certificate sent by the spoofing site didn't match the one that was spoofed. But how many users get those certificate warnings every day, from legitimate sites that simply haven't updated their certificate or are deploying it incorrectly? Users may be growing accustomed to simply clicking on "Allow."

A few months ago, Doxpara Research security engineer Dan Kaminsky -- who had been sounding alarms about this problem for at least six years -- decided he would help manufacturers implement a patch to the DNS deficiency, one which would not only randomize the source port but exponentially increase the size of the pool from which those port numbers are chosen. Both DNS servers and clients (i.e., any computer that uses DNS to resolve a URL with an IP address) would need to implement this patch.

But if Microsoft or Cisco or any one single company simply reacted to his warning by issuing a patch, that could trigger what we now know as the "zero-day effect:" Malicious users could disseminate not only the severity of the potential problem but the dynamics of it, simply by reverse-engineering the fix. Then they could potentially exploit all the other unpatched portions of the Internet, from manufacturers that had not yet caught up.

Wolfgang Kandek is the chief technology officer for Qualys, a vulnerability management company that works with enterprises to devise security policies and implement more secure software. Kandek is personally familiar with Kaminsky's work, and has surmised the huge problem he faced down.