Lessons Learned: Limited, Targeted, Collaborative Disclosure And Multi-Organizational Cooperation presented at SOURCE Boston 2009

by Dan Kaminsky,

Tags: Security

Summary : The DNS bug should not have mattered. For all the noise, it was really a simple, painfully obvious flaw, the effects of which should have been blunted by widespread strong cryptographic authentication. And yet, even a cursory examination of the real world of deployed systems reveals widespread if subtle security dependency on DNS. Why?
DNS offers a reliable and federated mechanism for locating services across organization boundaries, and this one task is so difficult and necessary that everything, from email to the web, from SSL certificate acquisition to Forgot My Password credential repair systems, has been build on top of it. It's not secure. But between not working, and not working securely, the Internet has chosen not working securely as the lesser evil.
So a lot broke when DNS was found wanting, even by its limited standards -- and bad guys are taking advantage of this, having attacked at least one to three percent of the remaining unpatched servers. But we need to do better. DNS has only barely been fixed, and other attacks (like BGP and WPA) offer some of the same MITM capabilities that made DNS attacks so dangerous. DNSSEC offers the potential of trust that scales as well, cross organizationally, as the name-to-IP services we take for granted today. There are deployment headaches, of course, but these can be managed -- and not by training admins, but by automating the servers so that DNSSEC is a patch only on the order of the Source Port Randomization patch deployed last year.
We will talk about what fixing DNSSEC -- and thus, the deployment of trust for all the applications people build, will take. And, just to keep things technical, we'll talk about a few obscure elements of BIND that have made the code in Metasploit not as effective as it might otherwise be.