[CrackMonkey] [djb@CR.YP.TO: The 200 trusted .com servers]
Seth David Schoen
schoen at loyalty.org
Mon Jan 24 00:41:16 PST 2000
Raffiniert ist DJB, aber boshaft ist er nicht.
----- Forwarded message from "D. J. Bernstein" <djb at CR.YP.TO> -----
Date: Sun, 23 Jan 2000 11:49:46 -0000
Reply-To: "D. J. Bernstein" <djb at CR.YP.TO>
From: "D. J. Bernstein" <djb at CR.YP.TO>
Subject: The 200 trusted .com servers
X-To: bugtraq at securityfocus.com
To: BUGTRAQ at SECURITYFOCUS.COM
Would you trust *.com DNS information from a computer that's running
BIND 8.2.1 and Sendmail 8.8.5 today, sitting on an open network in the
electrical engineering department at a large Australian university?
``Of course not,'' you say. ``Top-level DNS servers can't use versions
of BIND with well-known remote root exploits. They can't run any mail
programs. They can't be on open networks. They have to be protected from
sniffing. This is how the twelve official .com servers are run.''
But there's a difference between the twelve official .com servers and
what your DNS cache _thinks_ are the .com servers. This is true even if
all IP packets are cryptographically authenticated.
Suppose an attacker can make recursive queries through your cache. Let
me emphasize that this does not mean that the attacker is one of your
beloved users; many programs act as DNS query-tunneling tools.
Suppose the attacker is also able, somehow, to take over ns2.netsol.com.
This isn't one of the .com servers, but it's a name server for the
gtld-servers.net domain. Here's what happens:
(1) The attacker asks your cache about z.com. Your cache contacts
(say) k.root-servers.net, which provides a referral:
com NS j.gtld-servers.net (among others)
j.gtld-servers.net A 184.108.40.206
These records are cached.
(2) The attacker asks your cache about z.gtld-servers.net. Your cache
contacts (say) f.root-servers.net, which provides a referral:
gtld-servers.net NS ns2.netsol.com (among others)
ns2.netsol.com A 220.127.116.11
These records are cached.
(3) The attacker takes over ns2.netsol.com.
(4) The attacker asks your cache about zz.gtld-servers.net. Your
cache contacts ns2.netsol.com, and the attacker answers:
zz.gtld-servers.net CNAME j.gtld-servers.net
j.gtld-servers.net A 18.104.22.168
These records are cached, wiping out the obsolete j glue.
(5) A legitimate user asks your cache about yahoo.com. Your cache
contacts j.gtld-servers.net, and the attacker answers:
yahoo.com A 22.214.171.124
The user contacts yahoo.com at that address.
In some of these steps, your cache could have tried other servers first.
Perhaps the attacker briefly flooded your network, or those servers. Or
perhaps the attacker abused BIND's bogus ``credibility'' rules, as I
described in a previous message, to knock the other server addresses out
of your cache.
Of course, the same pattern can be extended. The attacker can start by
taking over one obscure computer in Australia. That lets him control the
address of a slightly less obscure computer; this power, in turn, lets
him control the address of yet another computer; and so on. After a
chain of ten NS records, he controls .com. (Exercise: Find this
computer. Hint: The chain doesn't include ns2.netsol.com.)
Right now there are more than 200 computers, spanning 224 IP addresses,
that can trivially take over .com in this way. They don't have to forge
packets; their power is provided by the architecture and configuration
of the Domain Name System. Some of these computers are clearly insecure.
Similar comments apply to many second-level domains that use third-party
slave servers. If your.dom has an NS record of fud.third.dom, you're
trusting not only the real fud.third.dom machine, but all the third.dom
servers. It's better to copy the real IP address to b.ns.your.dom, and
use that in your NS record. This also improves the reliability of the
The only real obstacle is NSI, which currently doesn't allow
registration of multiple names with the same IP address.
----- End forwarded message -----
I wonder whether this attack can also be used to take over the entire root
zone. I think it depends on how BIND treats the information it obtains
from the root.hints file -- is it willing to replace its cached NS records
for "." if they appear to differ from those returned by a query on "." to an
Seth David Schoen <schoen at loyalty.org> | And do not say, I will study when I
Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will
down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5
More information about the Crackmonkey