Is Kaminsky's DNS flaw public?

Thirteen days after Dan Kaminsky asked his fellow security researchers not to speculate on the details of his DNS flaw, a fellow Black Hat researcher published his own speculation, and apparently got it right.

On July 8, IOActive researcher Kaminsky disclosed a flaw in the Domain Name System (DNS), but would not provide the details until all the affected vendors had released patches and all the systems worldwide could be patched. He figured it would take about 30 days for that to happen. The 30-day mark also just happened to coincide with his speaking engagement at Black Hat in Las Vegas on August 6.

Kaminsky has worked for about 6 months with major vendors, coordinating a massive synchronized release of patches. It was an effort at responsible disclosure. However, in an interview with CNET News, Kaminsky suggested, in retrospect, he should have been more candid with more of his peers.

Those he did confide in appeared to be won over.

Writing on Monday in his blog, Halvar Flake first attacks the very idea that a security flaw such as this could be kept a secret, then proceeds to lay out what he thinks the flaw is:

"Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244.

"Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com."

Flake's entire speculation can be found here.

In response, Dan Kaminsky wrote Monday afternoon on his blog "Patch. Today. Now. Yes, stay late," suggesting that Flake has either guessed correctly or is very close.

[n3td3v]

yes, exploit code will appear on the mailing lists within days.

[thedreaming]

Someone, for once, wanted to do the right thing and actually fix the problem before 'they' get a hold of it and some idiot screams out, "I figured it out, want to see?"

[Penguinisto]

I'm just surprised that it has stayed quiet for this long.

The good news is, by the time it becomes workable malware, it'll likely be of a far more limited effect than it otherwise would have.

[Seaspray0]

Many sites also use SSL to secure their webpages. Even if you can redirect the client, there is still the issue of the certificate used to encrypt the website. That certificate is issued by a root Certificate Authority to the real website. A fake website will not have that.

[Penguinisto]

Yes and no... a hijacked website means that you can park an IFRAME in the hijacked site, keep their known-good cert, but have the victim get your content.

Also, a site whose job it is to dump malware on your system can simply take you to the fake page, dump the malware (assuming the flaw(s) they're exploiting are present), then quickly redirect you to the real site, with the malware (esp. a keylogger) up and running by then. A typical user would never know the diff.

A really elegant malware trap (if set up right) could simply dump the real site into a page frame and use its fake site as a transparent proxy, with one ginormous frame for the real site to go through, and the other 0px tall (but containing a shedload of malware, keyloggers, whatever). The user still sees the good cert info, and the malware author gets to dump/keylog/etc. to his heart's content.