The out-of-domain NS registration attack

[djb () CR YP TO (D. J. Bernstein)]

Let's say an attacker wants to steal your mail to hotmail.com.

You're running the current version of BIND. You have the following
information in your cache from recent lookups of MX hotmail.com and
* law5.hotmail.com:

   hotmail.com MX 10 mail.hotmail.com
   hotmail.com MX 10 mc2.law5.hotmail.com
   hotmail.com MX 10 mc4.law5.hotmail.com
   hotmail.com MX 10 mc5.law5.hotmail.com
   hotmail.com NS ns1.hotmail.com
   hotmail.com NS ns3.hotmail.com
   mail.hotmail.com A 216.33.151.135 (from additional records)
   mc2.law5.hotmail.com A 216.32.243.135 (from additional records)
   mc4.law5.hotmail.com A 216.33.151.136 (from additional records)
   mc5.law5.hotmail.com A 216.32.243.136 (from additional records)
   law5.hotmail.com NS ns1.jsnet.com
   law5.hotmail.com NS ns2.jsnet.com
   law5.hotmail.com NS ns1.hotmail.com
   law5.hotmail.com NS ns3.hotmail.com
   ns1.jsnet.com A 209.1.113.3 (from additional records)
   ns2.jsnet.com A 209.1.113.4 (from additional records)
   ns1.hotmail.com A 216.200.206.140 (from additional records)
   ns3.hotmail.com A 209.185.130.68 (from additional records)

The attacker begins by sending you a few hundred queries for each A
record. One of BIND's bogus ``credibility'' rules is that each query
drops the record's TTL by 5%, so the A records soon disappear. (I don't
blame BIND for the attack as a whole; there are other ways to knock
records out of a cache, though BIND makes it absurdly easy.)

The attacker then registers a new domain with NSI, using ns1.jsnet.com
as the domain's server name, but his own IP address for ns1.jsnet.com:

   zerosecurity.com NS ns1.jsnet.com
   ns1.jsnet.com A 5.6.7.8

The attacker then convinces you to look up zerosecurity.com. Your cache
accepts the ns1.jsnet.com address from the .com servers:

   zerosecurity.com NS ns1.jsnet.com
   ns1.jsnet.com A 5.6.7.8 (from additional records)
   hotmail.com MX 10 mail.hotmail.com
   hotmail.com MX 10 mc2.law5.hotmail.com
   hotmail.com MX 10 mc4.law5.hotmail.com
   hotmail.com MX 10 mc5.law5.hotmail.com
   hotmail.com NS ns1.hotmail.com
   hotmail.com NS ns3.hotmail.com
   law5.hotmail.com NS ns1.jsnet.com
   law5.hotmail.com NS ns2.jsnet.com
   law5.hotmail.com NS ns1.hotmail.com
   law5.hotmail.com NS ns3.hotmail.com

Next the attacker convinces you to look up mc2.law5.hotmail.com. Your
cache contacts the attacker's ns1.jsnet.com server, and receives a
response:

   mc2.law5.hotmail.com A 5.6.7.8

Similarly, the attacker feeds you fake addresses for mc4 and mc5. He now
has a 75% chance of receiving your mail to hotmail.com. He can increase
the chance to 100% with a bit more effort.

I should mention several things that _don't_ stop this attack:

   * Query source restrictions. Perhaps your cache doesn't accept
     recursive queries from 5.6.7.8---but the attacker can tunnel
     queries through your MTA.

   * Poison protection. Information about ns1.jsnet.com from the .com
     servers is, by definition, not poison.

   * BIND's bogus ``credibility'' rules. I made my example a bit more
     complicated than necessary to avoid moving information across
     ``credibility'' boundaries.

     One of the authors of RFC 2181, which has ``credibility'' rules
     even more extreme than the rules in BIND, claims that the rules
     stop high-level servers from accidentally spreading bad
     information. As my example shows, that claim is false. The
     high-level servers need to provide correct information.

   * NSI's bogus one-name-one-address policy. The host ns1.jsnet.com
     doesn't seem to be registered with NSI, and the attacker's IP
     address certainly isn't.

     I suppose this message will lead to a flood of new host
     registrations. But NSI doesn't have the resources to keep track of
     every server on the Internet; and the host registration process is
     itself a source of security problems.

I should also mention that attackers can forge DNS responses without the
help of the official servers. However, except for the relatively small
set of attackers who can sniff your network, forgery requires billions
of packets on average, and is much more difficult to carry out on a
large scale than the attack described here.

Solution: I suggest that NSI---and all other high-level registries---
immediately change the zone-file building process so that all NS names
for a domain are within that domain. Out-of-domain server information
such as

   zerosecurity.com -> ns1.jsnet.com -> 5.6.7.8
   zerosecurity.com -> ns2.jsnet.com -> 6.7.8.9

will be translated automatically into

   zerosecurity.com NS a.ns.zerosecurity.com
   zerosecurity.com NS b.ns.zerosecurity.com
   a.ns.zerosecurity.com A 5.6.7.8
   b.ns.zerosecurity.com A 6.7.8.9

(with appropriate dots, of course) for the .com zone file. Beware that
child servers will have to make the same change; otherwise they're
vulnerable to the BIND denial-of-service attack that I explained in

   http://cr.yp.to/dnscache/bugtraq/20000112082807-15140-qmail@cr-yp-to

Furthermore, any domain that (1) uses out-of-domain NS names and (2) is
already using *.ns for other purposes will have to change a few host
names to resolve the conflict.

On the bright side, in-domain NS names have efficiency benefits and
reliability benefits, as explained in

   http://cr.yp.to/dnscache/notes.html#gluelessness

Caches won't have to contact parent servers as often as they do now.
This could noticeably reduce the .com server load, and it will reduce
the frequency of long DNS lookup delays for users.

---Dan