COMMAND
bind()
SYSTEMS AFFECTED
All systems using BIND as their domain name server with recursion
enabled.
Windows NT (server) version 3.51 & 4.0 DNS server.
PROBLEM
The following informations is based on Secure Networks Inc. and
CORE Seguridad de la Informacion advisories.
The usage of predictable IDs in queries and recursed queries
allows for remote cache corruption. This allows malicious users
to alter domain name server caches to change the addresses and
hostnames of hosts on the internet.
Remote root users can poison BIND and Microsoft Windows NT name
server caches by forging UDP packets. Note that unlike other
well documented attacks, in this instance it is NOT necessary for
the attacker to take over a DNS server or sniff the target
network.
This particular cache corruption attack requires that the target
nameserver be configured to allow recursion. Recursion allows a
nameserver to handle requests for zones or domains which it does
not serve. When receiving a query for a zone or domain which is
not served by the name server, the name server will transmit a
query to a nameserver which serves the desired domain. Once a
response is received from the second nameserver, the first
nameserver sends the response back to the requesting party.
The following attack is outlined in the paper "Addressing
weaknesses in the Domain Name System Protocol" by Christopher
Schuba and Eugene Spafford. The paper also assumes that the
attacker has super-user access to a primary nameserver, here SNI
and CORE demonstrates that this is not necessary nor are source
routed packets required.
Using the recursion feature, one can poison the cache on a name
server with the following procedure:
The Players
HOST.ATTACKER.COM is the attacking host.
DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that
this is the only name server for ATTACKER.COM to simplify the
description.
DNS.TARGET.COM is the target nameserver which runs BIND. What
we will attempt to do is add an A (address) resource record on
DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1.
We are sure that WWW.SPOOFED.COM is not cached in
DNS.TARGET.COM's DNS cache.
DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We
have determined this before the attack begins. Once again we
just presume its the only one in order to simplify this
description.
The Attack
A. First a query is sent to DNS.TARGET.COM asking for the
address of UNKNOWN.ATTACKER.COM. Our query has the
recursion desired bit set, meaning that if the nameserver
we are querying has recursion enabled, it will query
another nameserver with our query (assuming it does not
have the information cached).
B. DNS.TARGET.COM will first determine who serves the
ATTACKER.COM domain, then it will build a query packet and
send it to DNS.ATTACKER.COM.
C. We sniff DNS.ATTACKER.COM's local network and retrieve the
query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM.
We can then determine the query ID (qid0) used by
DNS.TARGET.COM. Chances are that the next queries
generated by DNS.TARGET.COM will have query IDs that will
fall in the range [qid0,qid0+N] where N is dependent on the
amount of queries DNS.TARGET.COM is generating in the
period of time on which the attack takes place. N is
usually <= 10 for most cases.
D. Once we have determined what the next query ID generated
will be, we send a query to DNS.TARGET.COM asking for
WWW.SPOOFED.COM's address.
E. Then we start sending spoofed DNS replies from
DNS.SPOOFED.COM, telling DNS.TARGET.COM that
WWW.SPOOFED.COM is '127.0.0.1'.
F. If we guessed the query ID used by DNS.TARGET.COM in its
recursed query and our response is received first, our
response will be taken as valid and the address will be
cached. Subsequent responses will be discarded as
duplicates. We can always send many (N*M) spoofed packets
with different IDs in the range (qid0,qid0+N] so we will be
sure that at least one of them will hit DNS.TARGET.COM and
have the 'right' ID. M is a factor dependent of the amount
of UDP packets we expect to lose on their way to
DNS.TARGET.COM.
If the attack succeeded, any query to DNS.TARGET.COM asking for
WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response.
Thus, any user on TARGET.COM's domain will connect to 127.0.0.1
if they try to contact WWW.SPOOFED.COM.
The usage of 127.0.0.1 in this description is of course for
instructional purposes, any IP address can be used, in particular
an attacker could use its own IP address (BADGUY.COM's IP) so all
connections to 'host' will go to 'BADGUY'. The attacker can
then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is
easy to visualize the effects of impersonating a high traffic FTP
distribution site. This attack can also be used to intercept
email traffic, and bypass address based authentication methods,
including TCP wrappers and firewalls.
However, this attack depends on a few things to succeed:
1. The attacker has complete control of DNS.ATTACKER.COM's
network, he can both spoof and sniff DNS packets there. In
particular, he can sniff DNS packets sent to DNS.ATTACKER.COM.
2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM
must be received before the legit response from
DNS.SPOOFED.COM. This is very easy to achieve. In testing we
have not yet encountered a situation where we could not get
our packets to the nameserver first.
3. The name server on DNS.TARGET.COM supports recursion and caches
responses. This is common practice. It should be noted that
most nameservers allow recursion (unless specifically denied
by configuration options). Root name servers, however, do not
allow recursion.
If DNS.TARGET.COM caches negative responses as well (NCACHE), a
denial of service attack can be performed, in this case, spoofed
responses sent by the attacker will tell DNS.TARGET.COM that
WWW.SPOOFED.COM does not exist (and be authorative on this).
The existence of several nameservers for the domains does not
alter the basic outline of this attack. The attacker would only
need to send DNS responses with source addresses of each of
SPOOFED.COM's nameservers. (N*M*I responses, where I is the
number of nameservers).
SOLUTION
The Microsoft DNS Server has been modified to use random query
IDs. Random query IDs reduce the effectiveness of this cache
pollution attack. Obtain the following fix, or wait for the next
Windows NT service pack. This hotfix has been posted to the
following Internet location:
ftp://ftp.microsoft.com/
following path:
bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/dns-fix
The KB article Q159310 says this was last updated March 31, 1998
and it says that there is a fix available to correct them. To get
a fix that is not available from the standard MS FTP site, you
need to contact Microsoft Professional Support Services (PSS) and
refer to the KB article. This will be also addressed in SP4.
As for others, apply newest BIND (4.9.7/8.1.2)