Followers

Wednesday, July 30, 2008

New DNS exploit now in the wild and having a blast

By Joel Hruska

About two weeks ago, we covered the release of a DNS security fix meant to patch a vulnerability in the system that matches domain names with IP addresses. The flaw had been discovered by security researcher Dan Kaminsky some months earlier but, at the time, details on the exploit were being kept secret. That information has since leaked thanks to an accidental blog post by someone at Matasano Security. Fast forward four days, and hackers, enterprising little children that they are, have released an exploit aimed squarely at the vulnerability.

This would be less of an issue if the widely released patch from two weeks ago had been fully deployed, but a number of companies or ISPs don't seem to have gotten the memo. Accordingly to Kaminsky, some 52 percent of DNS servers are still vulnerable to the attack. This is a marked improvement from the 86 percent vulnerability rate in the days immediately following the patch's release, but it's still far too high, especially with dangerous code now squirreling its way across the Internet. Patch deployment is not an instant process, even if the company is on the ball, but we'll hopefully see the number of patched DNS servers skyrocket in the next few days.

Some publications have dubbed the attack Metasploit, but that term refers to the open-source Metasploit Framework that was used to develop it. As for the exploit itself, it's a new variation on a classic DNS poisoning theme. It disrupts the normal translation functions of a DNS server, causing it to redirect users to websites other than the ones they intended to visit. A poisoned DNS server, for example, could send someone to www.RussianMalware.com when they had actually typed www.google.com into the address bar. DNS poisoning isn't new—vulnerabilities have existed for over a decade—but the one Kaminsky discovered increases the power of a successful attack.

Kaminsky has now detailed the methodology of a standard DNS poisoning attack and provides additional information on the vulnerability he discovered. As he describes it, a DNS lookup request is essentially a race between a good guy and a bad guy, each of whom possess certain advantages. The good guy knows when the race begins, and he knows the secret code that's been sent along with that request in order to verify that the response coming back is actually authentic. The bad guy doesn't have this code, but he actually decides when the request goes out, and he knows about the request before the good guy does.

Normally, the good guy wins the vast majority of these races, and the bad guy is forced to race again and again in an attempt to guess the right authentication value before the good guy provides correct information. What Kaminsky discovered, and what the new hack exploits, is a vulnerability in the recursive nature of the DNS system. DNS is designed to "bump" your request along until it reaches a server that can answer the client's request. If you ask www.DNSTarget.com for a location it doesn't know, DNSTarget.com can refer you to A.DNSTarget.com, B.DNSTarget.com, and so on, until it finds the requisite information. A.DNSTarget.com is what's called an "in-bailiwick" relative to DNSTarget.com—the information that comes back from that server is automatically trusted and passed on.

Therein lies the problem. Instead of launching an attack straight at www.dnstarget.com and losing 99 percent of the time, the bad guy attacks one of the recursive in-bailiwick servers and then feeds it false information. The in-bailiwick server communicates that data back to DNSTarget.com, which then caches the response—that way, it doesn't need to look the information up again. Problem is, the server has cached poisoned information and doesn't know it. Until that information drops out of the server's cache, the bad guy has effectively won the race.

Moving to the more DNSSEC system would have solved this problem, and that idea was apparently floated, but it was dismissed on account of the tremendous overhead required by this protocol. The patch that currently exists is not a foolproof solution, but it minimizes the chances that the attack will succeed. "The exploit is now tens of thousands of times harder, but still possible," Kaminsky stated during his Black Hat webcast. "one in several hundred million to one in a couple billion."

Original here

No comments: