At Black Hat, Kaminsky details DNS flaw

Security researcher describes how a successful cache poisoning attack could be launched by taking advantage of a recently disclosed flaw in the Domain Name System.

Security researcher Dan Kaminsky has offered more details about a fundamental flaw in the Domain Name System and the extent of the vulnerability.

In a presentation at the Black Hat security conference in Las Vegas on Wednesday, Kaminsky gave details of how a successful DNS cache poisoning attack could be launched by taking advantage of the flaw.

Kaminsky explained that transaction IDs, which are supposed to prevent "bad guys" from assigning their own IP address numbers to any domain, are ineffective as security measures. An attacker could flood a DNS server with multiple, slightly varied requests for a domain, such as "" or "" As transaction IDs can only be a number between 0 and 65535, and the attacker can launch multiple requests, eventually the attacker could spoof a domain by matching the ID through chance.

Once this domain is spoofed, the attacker can flood a name server with spoofed replies to poison its cache for the domain being attacked--for example, "" Requests for would direct a user to a site of the attacker's choosing.

Dan Kaminsky Declan McCullagh/CNET News

This vulnerability can be exploited by using multiple vectors of attack, according to Kaminsky. Web browsers can be forced to look up what the attacker wants, as links, images, and ads can cause a DNS look-up. Mail servers will look up what an attacker wants when performing functions such as a spam check, or when trying to deliver a bounce, newsletter, or bona fide e-mail response.

Kaminsky warned that it is also possible to pollute top-level domains such as .com, .net and .org.

"When the bad guy poisons .com, he gets all requests, even requests he didn't know in advance he wanted," Kaminsky said in his presentation. "He gets to decide what he'll poison forever."

Using encryption such as SSL can mitigate the risks posed by the DNS flaw , according to Kaminsky. However, he warned that SSL only has limited implementation at present and brings its own certification issues. People still log onto sites even if its SSL certificate has expired, he said.

Multiple vendors have brought out patches for their products to mitigate the risks associated with the flaw, mainly based around randomizing port numbers. Kaminsky said this had been effective. Nominum has been patched, Bind implementations have been patched, and Microsoft automatic updates have "swept through lots and lots of users."

Kaminsky said that 70 percent of Fortune 500 companies have tested and patched mail servers successfully, while 61 percent have patched nonmail servers.

However, Cambridge University security expert Richard Clayton told ZDNet UK that patching and randomization are effective only up to a point.

"You can randomize the identifier for the packet, and you can randomize the port number, but the bad news about randomization is the birthday paradox," Clayton said. "If you have 20 people in a room, the chances are that two of them will share the same birthday. That's the problem, if you're choosing at random and an attacker is choosing at random. If you are using two-to-the-sixteen (65536) samples, and an attacker is sending samples at the rate of the square root of two to the sixteen, which is two to the eight (256), the attacker has a 50 percent chance of success."

While randomization mitigates the problem, essentially it just "(puts) off the dreadful day when the attacker can send packets fast enough to overcome entropy", Clayton said.

Clayton said that a "real" fix would be to have the server notice when it was receiving a lot of requests which were not quite correct, become "suspicious," and only communicate using TCP, which can't be spoofed. A further fix would be to have carriers communicate using DNSSEC, a form of DNS which is encrypted, Clayton said.

Tom Espiner reports for ZDNet UK.

Click here for full coverage of Black Hat 2008.


Discuss At Black Hat, Kaminsky details DNS flaw

Conversation powered by Livefyre

Show Comments Hide Comments