DNS Vulnerability Gone Wild: Exclusive Cricket Liu Interview

By Greg Ness
2 Comments

Earlier this week the blogosphere and the press exploded with news about the inadvertent release of an exploit targeting a widely acknowledged vulnerability in about more than 11 million DNS servers. These servers are critical to the security of the Internet, as I mentioned yesterday at: DNS VULNERABILITY NOW IN THE WILD.

I found out about the release yesterday from Cricket Liu, the author of the definitive book on DNS, called DNS and BIND (published by O’Reilly). Cricket was on a DNS Security webcast with Dan Kaminsky a few days ago, and had then just spoken with Dan about the inadvertent release of the DNS vulnerability along with a researchers discovery of how an exploit could be successfully launched.

This of course puts extra pressures on administrators to patch their own DNS servers. If they dont patch they expose users to cache poisoning attacks capable of redirecting them to spoof sites designed to collect personal information. This vulnerability, now in the wild, could turn the Internet into a hackers gold mine of passwords, account numbers and other identity theft resources.

Dan had planned to announce his findings, (discovered six months ago) at an upcoming (August) Black Hat conference, allowing administrators around the world adequate time to patch their DNS servers ahead of his presentation. Since the cat is now out of the bag according to Wired and other sources.

I decided to ask Cricket to get his take:

July 22, 2008 Interview with Cricket Liu

Q: If you were to rank Kaminsky’s recently disclosed DNS vulnerability, how would you rank it?

I assume you’re asking me to rank it among other DNS vulnerabilities. It’s certainly Number 1 today. It’s probably the All-Time Number 1, too, since we’ve always had solutions to address other DNS vulnerabilities. With this one, we have new versions of name servers that make the attacks more difficult to carry out, but no outright solution that’s been agreed on as of yet.

Q) How does it compare to other known vulnerabilities in terms of scope and potential impact and ease of exploit?

Well, the Kashpureff attack, back in July 1997, was easier to exploit. Name servers lacked mechanisms to detect unrelated additional data then, and almost all were open to recursive queries, so Kashpureff really had his pick of targets and could poison their caches almost instantly. It’s fortunate that he did so only to protest unfair business practices, not for his own gain. We didn’t see another exploit of that particular implementation flaw before implementations were fixed and name servers upgraded.

The current vulnerability is much broader in scope. There are many more name servers on the Internet today than there were in 1997, of course. Odds are the vulnerability is now widely known among the hacker community, after being revealed in a couple of security blogs yesterday. And if the anecdotal evidence I’m hearing is correct, many administrators aren’t upgrading their name servers to patched versions.

Q: For anyone who says that this latest DNS vulnerability is “business as usual” what would you tell them?

To dust off their resumes.

Seriously, this is a Big Deal. DNS experts agree that this vulnerability provides a way for a hacker to poison the cache of an unpatched, open recursive name server in less than a minute. Dan Kaminsky did everything he could to buy us time to patch our name servers. The Internet Systems Consortium and a whole lotta vendors—including Infoblox—worked hard to make sure you had patched code available the day of Dan’s announcement. If you stick your head in the sand and ignore the warnings, and a hacker writes code that combs the Internet for vulnerable, open recursive name servers, poisoning the A record for windowsupdate.microsoft.com, say, and you end up with legions of pwned PCs, guess who’ll get the blame.

Q: What is the nature of this vulnerability that makes it noteworthy compared to previous vulnerability and patch announcements?

It’s notable because there are so many hosts affected (from our surveys with The Measurement Factory, there are about 11 million name servers on the Internet) and because the consequences of a successful compromise are so high. If your name server’s cache is poisoned, you could find (but might never notice) that all of your mail to a business partner is re-routed through a mail server-in-the-middle, where it’s copied for later perusal and then sent on to unwitting recipients. Your traffic to critical web sites could be intercepted, and login names, passwords, and credit card numbers sniffed and recorded.

Q: Why do you think some security pros don’t find such a significant vulnerability alarming?

Some aspects of the vulnerability are familiar. We’ve known about attacks involving additional data since 1997. We’ve known the message ID in DNS messages isn’t long enough for a long time, too. But it’s not the components of the attack that are important. It’s that you can assemble them into a very effective attack against recursive name servers. Or a killer robot—your choice.

Q: Why do you think that a number of administrators are hesitating to patch their DNS systems?

Well, it can be a lot of work if you’re running plain vanilla BIND name servers on UNIX or Linux. And Amit Klein of Trusteer found a flaw in the implementation of BIND’s pseudo-random number generator (used to generate message IDs) last year. Some administrators may think that the patches they applied for that vulnerability will protect them from this one. (They won’t.)

NOTE: Cricket also has a DNS Best Practices micro-site at www.infoblox.com.

You can read my disclaimer at: About « ARCHIMEDIUS.

2 Comments »

RSS TrackBack URL

  1. [...] had post on this topic early and then a followup on the firewall problem around transaction id and PAT mode. This conversation [...]

    on August 7, 2008 @ 8:52 am

  2. [...] July 23, 2008 - DNS Gone Wild - Exclusive Interview with Cricket Lui [...]

    on August 7, 2008 @ 12:46 pm

Leave a comment

Broadband Developments - Unified Communications, Virtualization, Security, and Web 2.0 is (c) 2008
Powered by WordPress