Kaminsky's DNS Issue Accidentally Leaked?

[Update 2: Thomas Ptacek of Matasano has since posted a public apology to Dan et al for the accidental postage. Regarding The Post On Chargen Earlier Today.]

[Update 1: Upon re-reading Halvar's explanation, it appears he got it closer than I originally thought, missing only the part about "bailiwick checking", which prevents a request for arbitrary.invisibledenizen.org from poisoning ns1.google.com. Halvar's solution, as written, would fail as I understand it. But one minor change (to using subdomains) makes it all function.]

It appears matasano posted an explanation of Dan Kaminsky's DNS issue to their blog today, but looks like it may have been yanked back down. My google reader account nabbed it via the RSS feed while it was up.

It looks like maybe they had this typed up, ready to hit "post" as soon as someone else figured it out? They had advance knowledge of the issue via conference calls with Kaminsky, and when Halvar Flake posted some speculation on what the issue was, they referred to Halvar's post and their explanation hit the matasano blog. But Halvar's speculation was not the full issue; only a re-hash of previously known issues. Halvar's ideas were close, but incomplete. Matasano filled in the missing details, possibly by accident. :)

Rather than re-post their entire section and get crossways with copyright complaints, here's a summary of their explanation:

1. There's a general principle of cryptography that says if you have to guess Variable A, it's incredibly helpful to be able to make as many iterations of variable A as possible. (See wikipedia's entry on "birthday attack" or google for more details.)
   
2. DNS only uses a random 16-bit transaction ID that must be guessed in order to poison a DNS server's cache, and it must be guessed before the legitimate answer comes back. This is difficult to do on any individual requests scale.
   
3. If you can slam a server with tons of requests, Point 1 above comes into play and allows you to reliably and quickly get at least 1 DNS cache poisoning packet to match the transaction ID. (Halvar's guess said this: force requests for random0000001.com, random0000002.com, etc, to generate a large amount of Variable A's. Eventually you'll guess one right.)
4. This is obviously not very helpful. So what if I can poison bankofamerica349543.com.
5. OK, so what about DNS wildcards? If you are able to poison random00001.invisibledenizen.org, what does that get you? Enter the additional RR set field. This allows you to piggy back additional DNS responses in addition to what was requested. For security reasons, you can only respond with additional answers for addresses that match the same domain. (E.g., if I submit a request for arbitrary.domain.com, the additional response section can only return info for domain.com sub-domains.)
   
6. So the attack is this: do the above to cache poison randomXXXX.invisibledenizen.org, and in each packet have the additional RR return answers for ns1.invisibledenizen.org. Whenever random42156.invisibledenizen.org is the magical response that finds the transaction ID and poisons the cache, it will also poison the record for my nameserver, ns1.invisibledenizen.org.

Matasona stated this attack could occur in "less than 10 seconds" with current internet speeds.

Anyone want to throw together a metasploit aux module for this?

:)

-N