Re: DNS Speculation

[Alexander Sotirov <alex () sotirov net>]

On Mon, Jul 21, 2008 at 10:24:11AM +0200, Halvar Flake wrote:
> 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.
> ns.polya.com doesn't have these requests cached, so it asks a root
> server "where can I find the .com NS?"
> It then receives a referral to the .com NS. It asks the nameserver for
> .com where to find the nameserver
> for ulam00001.com, ulam00002.com etc.
>
> Mallory spoofs referrals claiming to come from the .com nameserver to
> ns.polya.com. In these referrals, it
> says that the nameserver responsible for ulamYYYYY.com is a server
> called ns.gmx.net and that
> this server is located at 244.244.244.244. Also, the time to live of
> this referral is ... long ...
>
> Now eventually, Mallory will get one such referral spoofed right, e.g.
> the TXID etc. will be guessed properly.
> ns.polya.com will then cache that ns.gmx.net can be found at ...
> 244.244.244.244. Yay.
>
> The above is almost certainly wrong. Can someone with more insight into
> DNS tell me why it won't work ?


I've been trying to understand the attack, but I am not sure that I really get
it. It looks like the only way it would work is if the DNS resolvers accept
records they didn't ask for. Do they? If they do, why?

I am certainly not an expert on DNS, so I'm looking for education rather than
presenting a complete attack scenario. Please excuse my ignorance if I don't
get something right.

So from what I understand, the attack works like this (starting with a empty
cache):

1) attacker sends a query for 1234.google.com to ns.isp.com
2) ns.isp.com sends a query for 1234.google.com to the root nameserver
3) the root nameserver responds with the authority record for .com
4) ns.isp.com sends a query for 1234.google.com to the .com nameserver
5) the .com nameserver responds with the authority record for google.com
   (the response includes the IP address of ns.google.com)
6) ns.isp.com sends a query for 1234.google.com to ns.google.com
7) ns.google.com responds with "does not exist" and includes a SOA record for
   google.com that points to ns.google.com. There is no A record for ns.google.com
   in this response.

I've verified steps 1-7 with tcpdump, but I have not tried to do the spoofing
yet, so what follows is pure speculation.


Spoofing a A record:

Right before step 7, the attacker sends a spoofed response from ns.google.com
that includes an A record for www.google.com and points it to 1.2.3.4 (which is
an attacker controlled name server). If the attacker does not win the race,
they just try again with 1235.google.com and so on.

When ns.isp.com receives the spoofed response, it puts the A record for
www.google.com in its cache and from now on google is at 1.2.3.4.

Why would this work? ns.isp.com did not ask for www.google.com, it asked only
for 1234.google.com. Why would ns.isp.com cache that unsolicted A record? Is
there some obscure DNS feature that requires this behavior?


Spoofing a SOA record:

Another possibility is to send a spoofed response with a SOA record for
google.com that points to 1234.google.com and an A record that gives the IP of
1234.google.com as 1.2.3.4. Perhaps the ns.isp.com nameserver will replace the
SOA record in its cache and from now on it will send all *.google.com queries
to 1.2.3.4.

Again, I'm wondering why this would work (if it does, I haven't tried it). The
ns.isp.com nameserver already has a cached authority record for google.com that
points to ns.google.com. It should not replace it in the cache until the record
expires, and even then it should only accept such authority records from the
.com nameserver (just like in step 5 above). Is there some DNS feature that
requires such SOA records to overwrite previousely cached ones? Shouldn't the
authority record for google.com that the .com server sent supercede all others
(until its TTL expires)?


Alex

Attachment: _bin
Description:

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave