The Backstory of the Kaminsky Bug

Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.

Re:Slashdotted

[Effugas]

The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.

Re:Do I not understand?

[cleatsupkeep]

They have to update their cache at some point.

Re:Do I not understand?

[cencithomas]

Basically right. The attacker forces a cache miss by using a bogus subdomain.example.com that is guaranteed not to exist in the ISP's DNS cache, and then tries to get his own response in before the real response comes in. If he succeeds, the the ISP will cache his spoofed packets as real, and his packets will include new NS1.example.com server IP info, causing the ISP to automatically go to his servers for any future request for example.com. He puts a TTL field with a super-long expiration date and voila! The cache doesn't expire and the ISP won't be asking for new DNS updates for that domain.

Re:Do I not understand?

[Anonymous Coward]

You got most of it...except for a couple of important bits.

The attack involves asking for *multiple, changing* nonexistent subdomains. That is important because the NXDOMAIN response might be cached, depending on the DNS server you are attacking.

You then blast the server with responses for the non-existent record, also including the RRs you want to hijack in the glue section of your forged response. That additional RR is in-bailiwick, and therefore put into the cache and treated as true.

Now, your important question: What's the point of glue records at all?

Glue records help solve a chicken-and-egg problem that is at the core of DNS. Say I want to resolve www.example.com. How does that DNS transaction go with glue?

(The following assumes TLD servers are not cached for illustrative purposes)

local -> root nameserver: "Who has www.example.com?"
root -> local: "list of .com NS records along with glue A records"
local -> .com servers @ IPs listed in glue: "who has www.example.com?" .com servers -> local: "list of NS records for the example.com domain w/ glue"
local -> example.com servers @ glue IPs: "who has www.example.com?"
example.com -> local: "www CNAME whatever, glue whatever A 1.2.3.4"

Without glue:
local -> root: "who has www.example.com?"
root -> local: "list of NS records for .com servers"

NOTE: now we need to resolve A.GTLD-SERVERS.NET (a .com server)

local -> root: "Who has A.GTLD-SERVERS.NET?"
root -> local: "list of .net NS RRs"

NOTE: the list of .net servers is the same as the list of .com servers, but it wouldn't matter if it was different. The point is, NS records have to reference a NAME, not an IP. TCP/IP requires an IP, not a name. chicken and egg. Glue solves that problem. Why do NS records require a name? Heck if I know, ask someone smarter.

I can see someone thinking: Ok, well what if we only accepted glue records from TLD servers? Two problems: First, this attack could be used to hijack the DNS entry of a TLD server just as easy as for any other. Second, you'd probably at least double the DNS transaction volume for other authoritative DNS servers. Probably more, actually (without glue, that CNAME we returned at the end of the first query would result in ANOTHER transaction to resolve whatever.example.com).

So glue is useful for a number of reasons.

Re:Do I not understand?

[ArsenneLupin]

So, uh... why not just turn off caching of everything besides the *ACTUAL* request?

Actually, as far as I understood, the attack is making the information "appear" to be relevant. For instance, DNS may contain aliases (CNAMEs) that do not directly resolve in an IP address, but rather into another name.

So, www.yourcompany.com may point to houdini.yourcompany.com, which itself resolves into 137.142.13.14.

When a client queries for www.yourcompany.com, the DNS server not only answers that query, but "helpfully" supplies the second leg, in order to save one round-trip.

Same thing with NS queries.

So, all the perp has to do is have nothere.domain.com pretend to be a CNAME for www.domain.com, and "helpfully" supply a mapping from www.domain.com to an IP under your control. Because the "unsolicited" mapping appears to be relevant, the client DNS server will cache it.

Re:Slashdotted

[tepples]

Right... but somebody MITM's both the CA and PayPal

They would have to MITM Mozilla and Opera first, as the CAs' root certificates get distributed with the browser.

Powerpoint

[mr100percent]

Here's Kaminsky's powerpoint [doxpara.com] given at the Black Hat conference. (106 slides but thorough) This Wired article and the powerpoint is enough to make me panic. He literally broke the internet; unlock any website and spoof any logs. Now I see why there was so much panic in the article.

Re:Why not use 64-bit key?

[Anonymous Coward]

Because they didn't increase the the key. They decreased the likelihood of success of the attack through other means, and they did so by enforcing source-port randomization. Now, not only does the attacker have to guess or know the TXID, they have to guess or know the source port of the request.

At least, that's my understanding of it.