DNS remains vulnerable one year after Kaminsky bug

A year has passed since security researcher Dan Kaminsky disclosed a serious flaw in the DNS that makes it possible for hackers to launch cache poisoning attacks, where traffic is redirected from a legitimate Web site to a fake one without the Web site operator or end user knowing.

Kaminsky's disclosure was a wake-up call to network vendors and ISPs about the inherent weaknesses in DNS, the foundational Internet standard that matches IP addresses with domain names.

The hype around Kaminsky's discovery also gave a much-needed boost to DNS Security Extensions (DNSSEC), an add-on security mechanism that had been languishing due to a lack of demand by network managers.

Kaminsky "helped raise awareness of the DNS vulnerability but also of Internet security in general and how dependent we are on protocols that don't have security built in," says Scott Rose, a computer scientist with the National Institutes of Standards and Technology and an expert in DNS security.

"There was discussion always in the protocol community about the vulnerability of DNS and the need for DNSSEC deployment, but the issue did get a big boost from the outside" thanks to Kaminsky, Rose said. "He raised the issue of what can happen when you attack the DNS. It's not just about redirecting browsers but subverting e-mail. All the other attacks that Kaminsky outlined brought the issue to the forefront."

Experts say more has been done to bolster the security of the DNS in the past 12 months than in the previous decade, thanks to Kaminsky's discovery. Yet, the DNS remains as vulnerable as ever to cache poisoning attacks.

The Kaminsky bug "was a big deal for the Internet community at large," says Joe Gersch, Chief Operating Officer at Secure64, which sells DNS server software and automated tools for migrating to DNSSEC. Gersch was at the Black Hat conference last summer when Kaminsky detailed the DNS cache poisoning threat in front of a standing-room-only crowd.

"It took 20 minutes for Kaminsky to explain how it works, and then he went through case after case of how it could be exploited for another hour and a half," Gersch says. "He showed how once you own the DNS, you own everything. And he showed how insidious the flaw is so that you don't even know you've been compromised. Jaws were dropping."

Gersch says Kaminsky did more than raise awareness of the inherent lack of security in DNS. "It was a pretty big call to action, first for the patch and then for ... DNSSEC deployment," Gersch says.

Since then, most -- but not all -- network engineers have patched their DNS servers against the Kaminsky bug. Patching is what Kaminsky recommends as a short-term fix to this vulnerability.

The long-term fix for Kaminsky-style attacks is DNSSEC, which prevents cache poisoning attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption.

The problem is that DNSSEC works best when it is fully deployed across the Internet: from the root zone at the top of the DNS heirarchy, to individual top-level domains such as .com and .net, down to individual domain names. Until that happens, Web sites remain vulnerable to Kaminsky-style attacks.

The Kaminsky flaw is "the prime driver for DNSSEC," says Rodney Joffe, senior vice president and senior technologist with NeuStar, which sells managed DNS services and an interim fix to cache poisoning attacks called Cache Defender. The problem, Joffe says, is that "we're still a year or more away from DNSSEC deployment."

Page Break

In the meantime, ISPs and Web site operators are seeing a growing number of cache poisoning attacks, although few of them are publicly disclosed.

On July 17, Irish ISP Eircom reported that it was a victim of a cache poisoning attack, which resulted in two major outages and customers being re-directed from popular Web sites such as Facebook to bogus Web sites.

In April, Brazilian bank Bradesco confirmed that some of its customers were redirected to Web sites that tried to steal their passwords because its ISP, Net Virtua, was the victim of a cache poisoning attack.

``We see evidence of cache poisoning attacks because we monitor open recursive servers, and we see it occurring on an ongoing basis,’’ Joffe said. ``A year ago, it was a theoretical threat. Today, it's occurring.’’

The risk of cache poisoning attacks is actually greater than it was a year ago because the Kaminsky flaw is well known in the hacking community.

"The incidence of cache poisoning attacks on the rise, and people are scared because they’re insidious little beasts," Gersch says, pointing out that companies often don't realize they are victims of a cache poisoning attack. "We want to get to DNSSEC, but the industry is working on creative methods to work around the problem until DNSSEC is deployed."

Significant progress has been made in DNSSEC deployment in the last year.

The U.S. federal government mandated that DNSSEC be deployed across its .gov domain by the end of 2009, and it is taking steps to ensure that the DNS root servers are signed during the same time frame. By June 2010, federal agencies will be required to deploy DNSSEC on their internally facing DNS servers, too.

"Around 70 delegations under .gov are signed," Rose said, pointing out that www.nist.gov is one of the early adopters of DNSSEC.

The .org domain supports DNSSEC, as does country code top-level domains operated by Sweden, Brazil, Puerto Rico, Bulgaria and the Czech Republic. Most significant is VeriSign’s plan to deploy DNSSEC on .com and .net, which it says will be accomplished by 2011.

"This certainly has been the year of DNSSEC," Joffe said. "We’ve been at it for 13 years, but this is the year DNSSEC became real."

Some technical glitches remain with DNSSEC, and experts warn that Web sites may be unavailable when their domains switch to the new security protocol because of configuration problems.

"The largest operational hurdles that we’ve seen have been some small home routers and some intrusion detection systems and firewalls with default configurations that have trouble with DNSSEC," Rose said. "Users have to go back and reconfigure those systems for larger responses to handle the keys and signatures that come with DNSSEC."