To see how see how a DNS cache
poisoning attack works, consider a network where a stub
resolver issues a query to its recursive resolver, and
the recursive resolver in turn sends that A record
query to the start of authority for that
domain. Now, in an ideal world, the authoritative name
server for that domain Would reply with the correct
IP address. If an attacker guesses that a recursive
resolver might eventually need to issue
a query for say, www.google.com. The attacker
can simply reply with multiple, specially crafted.
Replies each with different id's. Although this
query has some query id, the attacker doesn't need to see that query because
the attacker can simply flood the recursive resolver with a bunch of bogus
replies and one of them, in this case the response with id3 will match. As
long as this bogus response reaches the recursive
resolver before the legitimate response does, the recursive
resolver will accept this bogus message. And
worse, it caches the bogus message. And DNS,
unfortunately, has no way to expunge. A message
once it has been cached. So now this
reclusive resolver will continue to send bogus
A record responses for any query for
this particular domain name until that entry
expires from the cache. Now there's several defenses
against DNS cache poisoning, and we've already seen one, which is the query ID.
But of course, the query ID can be guessed. The next defense is to randomize
the ID so rather than having a resolver, end queries where
the ID's increment in sequence, the resolver can pick a random
ID. This makes the ID tougher to guess, but still,
the query ID is only 16 bits, which still makes it possible for
an attacker to flood the recursive resolver with many
possible responses. And, it's likely that, with
relatively few responses, One of these bogus
responses will match the ID for the real query. Due to the birthday paradox,
the success probability for achieving a collision
between the query ID of the query
,and of the response actually only requires
sending hundreds of replies, not a complete 32,000.
Due to the birthday paradox, The probability that
such an attack will succeed, using only a
few hundreds of replies, is relatively close to
one. The attacker does not need to send
replies with all two to the 16th possible
IDs. The success of a DNS cache poisoning
attack not only depends on the ability to
reply to a query with a correct matching ID,
but it also depends on winning this race. That is, the attacker must reply
to that query before the legitimate authoritative
name server replies. If the bad guy, or
the attacker, loses the race, then the
attacker has to wait for that correct cached
entry to expire, before trying again, however
the attacker can generate his own DNS query.
For example, he could query one.google.com, two.google.com and so forth. Each
one of these bogus queries will generate a new race. And eventually the attacker
will win one of these races for an A record query. But who
cares? Nobody necessarily cares to own
one.google.com, or google.com. The attacker really wants
to own the entire zone. Well the trick
here is that instead of just simply responding
with A records in the bogus replies. The
attacker can also respond with NS records for
the entire zone of google.com. So by creating
one of these races, using an A record
query, and then responding not only with the
A record response, but also with the authoritative
of the NS record,for the entire zone. The attacker can in fact own the entire
zone. This idea of generating extreme of A record queries to generate a bunch of
races and then stuffing the A record responses for each of these with a bogus
authoritative NS record for the entire zone. Is
what's called the Kaminsky Attack, after Dan Kaminsky,
who discovered the attack. The defenses of
picking a query ID and randomizing the ID,
help, but remember the randomization is only 16
bits, so let's think about other possible defenses.