• On MovieTome: The final word on Arnold and TERMINATOR!
July 24, 2008 2:09 PM PDT

Kaminsky (finally) provides DNS flaw details

by Robert Vamosi

In his first public comments since his Domain Name System (DNS) cache poisoning flaw was made public, Dan Kaminsky said in a conference call on Thursday he doesn't want to parse who said what when. He just wants everyone to understand that they must patch their systems now.

Speaking during the second pre-Black Hat security conference Webinar, Kaminsky, who's director of penetration testing for IOActive, provided the most information to date about the DNS flaw he found earlier this year but only disclosed in public on July 8. DNS is what translates the common name of a Web site into its numerical IP address, and is therefore a fundamental component to the Internet. His announcement coincided with a massive, multivendor patch release. But he withheld details, hoping that most people would get their systems patched before the bad guys got a hold of it.

Kaminsky said the word is getting out about the patches, but there are still many systems that are vulnerable. From the period of July 8 through July 13, 86 percent of the people testing their system on his Web site were vulnerable. Today it's 52 percent. "Not perfect; not even good enough," he said. But "I'll take 52 any day of week and twice on Sunday."

He started off by saying that he was trying to find a way to do content distribution using DNS when realized the problem. "How much trouble are we in? A lot."

Of the public discussion from individuals within the security community, Kaminsky said Halvar Flake's speculation was the closest. For those who said they knew of flaws in DNS before today, Kaminsky said "you didn't know this one."

Dan Kaminsky

(Credit: Declan McCullagh/CNET News)

Kaminsky described the flaw he's been working on as containing three flaws; two have been known, but one was not. Security researchers always thought it was hard to poison DNS records. He said to think of the process as a race, with a good guy and bad guy each trying to get a secret number transaction ID. "You can get there first," he said, "but you can't cross finish line unless you have the secret number." The good guy will always have it, but the bad guy has a 1 in 65,000 chance of getting it because the transaction ID is based in part on the port number used.

One bug with DNS is that the bad guy can start the race anytime he wants. If he doesn't know the transaction number, he can always guess. Another fundamental flaw is that there will be multiple bad guys trying to guess the transaction number. The flaw Kaminsky found that builds on the first two is that not only can multiple bad guys participate in a single race, but there can also be multiple races. The example he gave was www.blackhat.com. A bad guy shouldn't just try to guess the transaction ID for that address, but also for 1.blackhat.com, 2.blackhat.com, etc.

Everyone thought, he said, if "one sets a long time to live (TTL), say, for one year, that would work." But Kaminsky found that going to look up 1.blackhat.com, 2.blackhat.com, etc, he can find the name server and then guess the transaction ID. Kaminsky said the process of getting a response is about 10 seconds.

"Patch is the way to go; it shuts down the attack vector," said Jerry Dixon, former director of National Cyber Security Division of DHS. This was echoed by Rich Mogul of Securosis, and by Joao Damas, a senior program manager at the Internet Systems Consortium.

Kaminsky said the current patch has made exploits thousands of times harder--one in several hundred million, "not infinity." The bug is core to the design; it's fundamental to the design."

What have we learned? "We learned what needs to be done to fix the Net in the future. I await the security community's judgment on what we've done."

As for the long-term "Where do we go from here?" Kaminsky said there's going to be an awesome debate about that.

On August 6, Kaminsky will present "End of Cache as we know it" at Black Hat in Las Vegas.

As CNET's resident security expert, Robert Vamosi has been interviewed on the BBC, CNN, MSNBC, and other outlets to share his knowledge about the latest online threats and to offer advice on personal and corporate security. Listen to his podcast at securitybites.cnet.com or e-mail Robert with your questions and comments.
advertisement
Click here!
Recent posts from Security
Symantec's Ramzan on solving the antivirus puzzle
Apple fixing iPhone SMS security hole
Waledac worm targeting July 4 spam offensive
ATM vendor gets security talk pulled from conferences
Postini: Google's take on e-mail security
Botnets lead the way for spam
Stallman warns of Mono 'risk'
China delays rule for Net-screening software
Add a Comment (Log in or register) (6 Comments)
  • prev
  • 1
  • next
by nachurboy July 24, 2008 3:01 PM PDT
Either I didn't understand the description of the flow or the grammar of this article was too hard to understand.

"Everyone thought, he said, if "one sets a long time to live (TTL), say, for one year, that would work." But Kaminsky found that going to look up 1.blackhat.com, 2.blackhat.com, etc, he can find the name server and then take over that domain. Kaminsky said the process of getting a response is about 10 seconds. " What does this mean?

"Where go from here?" Is that a sentence?
Reply to this comment
by AdeBarkah July 27, 2008 9:16 AM PDT
A caching nameserver "remembers" valid domain records for the duration of the TTL value. Until the TTL expires, the nameserver will simply return the cached record instead of performing a recursive query. Since no query is performed by the server, an attacker can't poison it during this period.

In the example given, if the TTL is one year, then an attacker would have to wait one year (until the TTL expires) before he can successfully poison the nameserver. Even then his odds of succeeding is relatively low, and if he fails, he'd have to wait another year before the next attack. Even a relatively short TTL value (a couple of hours) could effectively thwart a DNS poisoning attack.

Or so we thought.

Dan found a way to "bypass" this TTL limit by forcing the nameserver to query for closely-related domain names. e.g., 1.blackhat.com, 2.blackhat.com, etc., instead of www.blackhat.com. These so-called "in-bailiwick" domains will trigger DNS queries, which can then be attacked.

Using this method an attacker can force a caching nameserver to make an arbitrary number of queries (thousands per second), essentially guaranteeing a successful attack.
by sundance808 July 24, 2008 5:19 PM PDT
it means nobody has an idea what it means
Reply to this comment
by Mteicher July 25, 2008 3:01 AM PDT
How is Kaminsky going about solving the issue versus providing detailed information about the issue in order for his hacker buddies to develop exploits to attack the DNS Servers. Content distribution, have you heard of Napster or Limewire, or how about Multi-cast. Your buddy Tom P already did this with Sonicity years and years ago. How about providing the community with something useful instead of talking about doom and gloom.
Reply to this comment
by nocake July 25, 2008 5:50 AM PDT
Ridiculous! Do you have any idea how lucky we are that Kaminsky disclosed this responsibly? What if some rogue entity ended up with it instead and silently exploited the web? Do you have a clue as to the damage that could be done?
Kaminsky has done the right thing by everyone: he notified the vendors, gave them time to patch (this is a big bug), and kept the exploit to himself.
Additionally, why is Kaminsky's responsibility to fix it? is he in charge of the BIND project now? Should he have asked miscrosoft for their source so he could personally patch and recompile Windows without the DNS glitch? What nonsense. Show some respect.
by ghostwalkers12 August 8, 2008 9:12 PM PDT
Kaminsky discovered nothing not known to people very familiar with the IP suite of algorithms, and with DNS. The process of discovering (for removal of defects) is covered by combinatorial testing. But given the conventions of development in software industry, such is a novel concept in itself to most. The only certain way to avoid the cache poisoning exercises of script kiddies is to assure that the DNS does not query over the client facing NIC. Patching the DNS server does not resolve the problem. It continues to exist, easily exploited in less than 10 seconds. If motivated your DNS is gone in under a second.
Reply to this comment
(6 Comments)
  • prev
  • 1
  • next
advertisement

Making sense of Windows 7 upgrades

faq The basics and the fine print on Microsoft's options for those eyeing the next operating system from Redmond.
• Full Windows 7 coverage

Road Trip 2009: Big Sky Country

CNET News reporter Daniel Terdiman takes his car full of gadgets to the Rockies and the Great Plains in search of tech, science, nature, and more.
• America's Fortress: Cheyenne Mountain

About Security

Online security is threatened by more than hacking and phishing attempts. Check here for the latest updates on software vulnerabilities, data leaks, and rapidly spreading viruses--and learn how to protect your systems.

Add this feed to your online news reader

Security topics

advertisement
advertisement

Inside CNET News

Scroll Left Scroll Right