DNS and the Cyber TARDIS Problem

It's been 16 days since I responded to public notification of DNS problems in Thoughts on Latest Kaminsky DNS Issue, and 4 days since Halvar Flake's post On Dan's request for "no speculation please". Apparently the tubes are still working, since I presume you're reading this post via the Internet and not carrier pigeon. It's still been a remarkable period, characterized by the acronymn in the title of this post.

I'm not referring to the TARDIS of Doctor Who, although centrality of "Time" is the reason I used the TARDIS theme. I mean Time and Relative Data in Security. Time and Relative Data were the key issues in the DNS issue. Who knew more about the problem, and when? Halvar understood this in his post, when he estimated that a savvy attacker would need 1/4 the time of a normal security person to understand the nature of the DNS problem, given the same starting point.

Since Halvar's speculation, Matasano's confirmation, Metasploit's weaponization, and Dan's elaboration, there's been a flurry of offensive and defensive activity. It reminds me somewhat of Y2k: am I still able to use the Internet because DNS administrators have been patching, or are not enough bad guys trying to bother me? It would be nice to see some academics query whatever data (hint) they can find on recent DNS activity to produce some practical research, rather than trying to decipher five year old worm data or yet another port scan. According to this Arbor Networks Blog post by Jose Nazario, his group might have some data to share soon.

I'd like to highlight some of my favorite thoughts from the past few days. I liked FX's post Perception of Vulnerabilities:

The Kaminsky DNS attack is definitively regarded as the most important vulnerability this year. This, I find highly interesting , as we have seen two other gigantic security failures already in 2008. Debian's NRNG (non-random number generator) is most certainly one of them. But honestly, raise your hands if you have even noticed SNMPv3... SNMPv3 is used to manage routers - the routers that forward all your traffic around the world, including your DNS queries. Managing a router means being able to configure it; a.k.a. super user access. Attackers who can configure a router in your path can redirect everything, without you knowing, not just traffic that relies on name resolution.

The weaponization discussion has been great. On one side are people like Hoff and Rich Mogull, who believe the Metasploit team was wrong to weaponize the exploit. I place myself on the other side. I agree with a lot of Andre Gironda's argument in comments on Rich Mogull's post. I think it's important to be able to test if your DNS implementation is vulnerable, as noted by Ron Gula in But I patched our DNS servers ....

With the growing importance of the cloud, and the customer's increasingly reliance on software he/she doesn't control, are we to be satisifed with promises of applied patches, or even the effectiveness of said patches? If you always believe your vendor (i.e., you're naive), answer yes. If you trust but verify, answer no -- and start testing. Metasploit (exercised via a pre-existing, contractual agreement that permits such customer testing) is one way to see if your vendor really is as safe as it claims to be.

People who care about reality -- facts on the ground -- care about testing. Such people also care about monitoring. Prior to Halvar's speculation, probably the best place to try to figure out how to detect what "might" be coming was the Daily Dave mailing list. Since Halvar's post, there's been a lot of monitoring discussions on Emerging-Threats. Monitoring types have been trying to work around implementation challenges in popular tools like Snort, with alternatives like Bro getting more attention. Some historical articles on DNS intracies have helped people understand DNS better, now that we know exactly what to observe.

I believe the actions of the past week have been for the better. Sure, the bad guys have a tool now, but as Druid noted in the Metasplot blog:

I was personally aware of multiple exploits in various levels of development before, during, and after HD and I wrote ours, so we felt at this point publishing working exploit code was fair game.

Poke around for five minutes and you'll find other implementations of exploit code beyond Metasploit anyway, never mind the private ones.

Public speculation followed by weaponization has elevated the issue for those who had to produce "proof" in order to justify patching, as well as helping level the knowledge field. Those of you who object have got to understand this point: real bad guys always win in the Time and Relative Data arena. Their paid job is to find ways to exploit targets. They have the time and knowledge to identify vulnerabilities in DNS regardless of what Dan Kaminsky says or doesn't say. I know whole teams of people who avoid the most elite public conferences because they don't learn anything new.

Defensive-minded security person -- how do you spend your time? Are you like me, balancing operations, planning, meetings, family, and so on, across thousands of systems, with hundreds of classes of vulnerabilities, and nowhere near enough time or resources to mitigate them? Do you know as much about the latest attacks and defenses as the people who discover and exploit them, for a living? Probably not.

Even assuming such adversaries do not know about the DNS problem prior to Dan's disclosure, as soon as they acquire the scent that problems exist (and especially if patches are released), they point their collective noses at the newest victim and tear into it. Halvar's N/4 estimate was very conservative, although he recognized real bad guys probably work a lot faster than that.

I think Dave Aitel put it best:

The motto of the week is that you can't hint at bugs or people will just find them. Either full disclosure or no-disclosure wins, because there's no point doing anything else.