how to protect name servers against cache corruption (fwd)

Thomas H. Ptacek tqbf at enteract.com
Thu Jul 31 00:54:19 UTC 1997


> Yes.  But that something shouldn't include sending _anything_ off the
> machine, which is what you suggested.  If I didn't send a query to
> begin with, I sure in hell ought not to "re-send one" because I got a

I think you are confused here. Let me clarify.

I want the A record for HOME.NETSCAPE.COM. I send a query for it to
NS.MCI.NET, with the query ID "10".

Immediately thereafter, I receive 15 responses, forged to appear to come
from NS.MCI.NET, with IDs ranging from "20" to "65500". None of them can
possibly be valid, and there's no legitimate reason that I should be
receiving these responses. I (nameserver) therefore make the determination
that I am under attack.

At this point, I can either log the fact and ignore what's happening, in
which case the attacker will simply continue to send forged responses
until one of them happens to bear the query ID "10", or I can decide "hey,
I'm going to ignore even a valid response from NS.MCI.NET at this point,
because I have no way to tell that it isn't forged".

The problem with this is that it allows a trivial denial of service
attack. I'm Karl Kashpureff, and I want to prevent anyone at Netcom from
being able to resolve WWW.NETSOL.COM. All I do is send a consistant stream
of forged responses from the listed authority servers for NETSOL.COM to
Netcom's nameservers. They will no longer be able to resolve NETSOL.COM,
since every query they open up will be immediately invalidated by a fake
response.

What I'm saying probably makes the ID guessing attack look much simpler
than it really is. This is because, in the real world, there are actual
authority servers that actually receive the sent query. Even in the
absence of countermeasures such as the one outlined above, brute-force ID
guessing attacks are extremely difficult, since the correct ID needs to be
guessed prior to the receipt of a legitimate answer by a real server.

The 4.9.6 resolution to the ID-guessing problem contributes randomized
query IDs to this. In the presence of randomized query IDs, and in the
absence of attacks on the legitimate authority servers, it's probably
reasonable to assume that DNS is reliable in the face of an attack, due to
the extremely low likelihood of guessing the right one out of sixty-five
thousand IDs before a valid response.

However, in the presence of an attack on the legitimate authorities, we
have a real problem. If I can cause all the listed authorities for a
domain to cease responding to queries, I can set myself up for a
completely successful spoofing attack on the records they're answering
for. There's a real issue here involving the fact that, right now, /any/
denial of service attack in BIND (and we've just seen one of them posted
to Bugtraq) potentially allows for the compromise of nameserver caches.

A proposed countermeasure for this involves something I've taken to
referring to as "DNS cookies". The goal is to ensure that the listed
authority servers are capable of answering questions; that is, we'd like
to know if an attacker will have to beat out a legitimate server in a
brute force attack (in which case the attack will be difficult to carry
out), or whether the attacker will always be successful, since the
authorities can't assert the right information.

The idea is to send a random nonrecursive query to the authority server
being queried, in addition to (in a seperate packet) the real query. Using
a second query as a cookie allows us a massive random number space; we can
safely assume that the receipt of an answer for the random "cookie" query
means that the listed server is alive and answering.

This method would only be used when it's determined that the nameserver is
under attack, and should therefore add minimal load to the DNS system. In
place, the attack changes from something with deterministic chances of
success (I /will/ eventually hit on the right ID) to something with a very
slim probability of success (I'll eventually hit the right ID, but the
likelihood of doing so before the real server answers is minimal).

So, there's another piece of input. There are other ideas, too.

----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf at enteract.com]
----------------
"If you're so special, why aren't you dead?"





More information about the NANOG mailing list