DNS at Risk From Multivendor Cache Poisoning

It’s not often that multiple vendors are involved in a single security patch.

Then again few technologies are as widely used or as critical as Domain Name System, or DNS (define), the core Internet protocol that translates domain names into IP addresses.

Security researchers today sounded the alarm, warning DNS server users to update to new patched versions from their vendors to protect against a critical security issue.

Microsoft, Cisco, Juniper and Sun are among the vendors providing patches for their users. All Linux distributions and the Internet Systems Consortium (ISC) are also at risk.

If left unpatched the DNS issue could allow an attacker to “poison” the server and allow it to redirect traffic to an arbitrary location. Such a flaw could reap havoc on the Internet as a whole if exploited.

“I found that there is an issue with DNS, a fundamental issue based on design,” Dan Kaminsky, director of penetration testing for IOactive, said on a multivendor conference call announcing the vulnerability.

Said Kaminsky, “Design bugs are interesting because they don’t just constrain themselves to an individual company or implementation.”

He says the same bug appears in vendor after vendor. “This one flaw I had found affected not just Microsoft, not just ISC BIND or Cisco but everybody,” he said.

Microsoft (NASDAQ: MSFT) and Cisco (NASDAQ: CSCO) each have implementations for DNS. Unix and Linux distributions widely use the open source BIND DNS server, which ISC manages.

Kaminsky, who takes credit for discovering the flaw, noted that he was unaware of any current attacks that exploit the flaw in DNS.

“Usually any security fix will document what the core vulnerability was,” Kaminsky said. “Because this is a design flaw we didn’t do that in this case.”

Kaminsky explained that the nature of the fix is to improve port randomization. The general idea is to expand randomization in DNS from 16 bits to between 27 and 30 bits.

“This is not enough information to reverse engineer the flaw,” Kaminsky commented.

His fear was that by potentially giving out too much information about the flaw that hackers could use it to attack unpatched servers before IT administrator have the chance to protect their networks.

Kaminsky noted that he plans on releasing full details of the flaw in 30 days.

That said in response to a question, Kaminsky did narrow down the area in which the DNS design flaw exists.

He explained that every DNS response includes a transaction ID that is one of 65,000 random values. Every DNS query has a transaction ID, and the reply must contain the correct ID to route the Internet traffic to the correct address. What Kaminsky discovered is that 65,000 random transaction IDs are not enough and that more randomness is actually required for DNS to be secure.

“After the patch is applied the transaction ID must also have the correct ID and correct source port,” Kaminsky explained. “The source port is a random identifier at a different layer in the IP packet.”

As a metaphor to explain the situation, Kaminsky said that the new patch is the equivalent to sending a letter and signing both the letter inside as well as the outside of the envelope.

A more viable, long-term solution to improving DNS security is called DNS security extensions, or DNSSEC. These extensions have been available on the BIND DNS server for several years
though DNSSEC is not widely used or deployed yet.

“We at ISC hope that this issue will draw attention to DNSSEC, which in the end will only be the real solution to these sort of attacks in the future,” Joao Damas, senior programming manager, ISC said on the same conference call. “DNSSEC enables you to verify that the data was published by the originator.”

Kaminsky agreed with Damas that DNSSEC would be the correct long-term solution, though he was quick to point out that it was not the immediate solution. DNSSEC is an approach that includes integrity and authentication checks against DNS data. According to a 2007 study only 0.002 percent of DNS servers have DNSsec running.

Kaminsky argued that running DNSSEC today in a local network isn’t enough to protect users broadly across the Internet as a whole.

“DNSSEC only protects you if you are resolving against a DNSSEC-protected zone,” Kaminsky said. “Right now the infrastructure required for all names to be DNSSEC signed just isn’t there. So if you happen to be using a particular zone that is DNSSEC protected then yes you might be ok but unfortunately it’s exceeding rare at this time.”

Damas responded that he is seeing a trend towards top level domains (TLDs) deploying DNSSEC, including the .se domain in Sweden and the .org TLD.

“People can protect themselves or at least learn and be familiar and confident that it {DNSSEC} can be done and it is the solution to spoofing attacks,” Damas said.

Article courtesy of InternetNews.com

Latest Articles

Follow Us On Social Media

Explore More