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
Remember SNI's advisory about bind(). If not, take a look at
BIND #5 in mUNIXes sections on this page. Johannes Erdfelt did
that time ago as well and so this is a part of his advisory.
There's a MUCH easier way of caching RR's. As long as the
nameserver is older than 4.9.5+P1 which is > 90% of the net. The
problem is basically this: BIND will cache ANYTHING that it gets
in the return packet.
During the caching of the information of answer returned from a
recursive query it will cache everything that is returned in the
answer, name server and additional sections. The way to exploit
this bug is trivial. As an example, a daemon running on
123.45.67.89 wants to determine the domain name of the IP which
just had connected to it. This is a common practice done by many
daemons for logging purposes. A user on the machine 38.222.74.2
connects to the rlogin port of 123.45.67.89. The DNS server that
123.45.67.89 uses is 98.76.54.32. 123.45.67.89 sends out a query
to 98.76.54.32 asking for a PTR record:
123.45.67.89 -> 98.76.54.32 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: 2.74.222.38.in-addr.arpa PTR
The name server at 98.76.54.32 has no information on that domain.
After a couple of more queries, it comes to find that 38.222.74.2
and 38.222.74.10 are authoritative name servers for
74.222.38.in-addr.arpa. It then sends a query out to one of them:
98.76.54.32 -> 38.222.74.2 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: 2.74.222.38.in-addr.arpa PTR
The DNS server at 38.222.74.2 receives the query and then answers
it:
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 2 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
When the DNS server at 98.76.54.32 gets the answer, it will relay
this packet back to 123.45.67.89, the original querying machine.
It will also, take the answer, the name servers, and the
additional sections and cache them.
Now that it has a domain name for the IP, and since the service
is rlogin, the daemon will now check the /etc/hosts.equiv file to
see if this host is allowed access to the machine. However,
spoofing, as this technique is commonly called, a PTR record has
been known about for years. TCP wrappers for instance try to fix
this problem by doing a lookup on the domain name returned in the
original query and checking the 2 IP addresses. If they don't
match then it assumes that someone is trying to fake their PTR
record to gain unauthorized access. However, when tcpd does the
lookup for the A record:
123.45.67.89 -> 98.76.54.32 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: trusted.host.com A
The DNS server at 98.76.54.32 will return the information which
it had cached earlier when the 2.74.222.38.in-addr.arpa answer
was returned:
98.76.54.32 -> 123.45.67.89 [Query]
NQY: 1 NAN: 1 NNS: 2 NAD: 2
QY: trusted.host.com A
AN: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
Now tcpd thinks that the user at 38.222.74.2 is actually
trusted.host.com when they are really someone else. This can lead
to unauthorized access to a system which does all authentication
based on domain name.
Denial of service is possible as well. Let's take the original
2.74.222.38.in-addr.arpa query and modify it slightly:
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 2 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: www.company.com A 0.0.0.1
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
Now whenever some queries the DNS server at 98.76.54.32 for
information about www.company.com then they will be pointing at
0.0.0.1 which is a non existant IP address which no one will
respond to. Effectively denying service to the people who wish to
get to www.company.com.
Theft of services? Let's take the 2.74.222.38.in-addr.arpa query
one more time as an example:
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 3 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: www.company.com CNAME www.competitor.com
AN: company.com MX 0 mail.competitor.com
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
Now, whenever someone wishes to visit www.competitor.com, they
are instead diverted to a thrid party, possibly hostile site. In
this case, to a competitors web site. If someone were to send
email to company.com, it would go to mail.company.com instead
where a competitor could get information which is supposed to be
destined to www.company.com.
There a couple of limitations to this particular attack. One
cannot "replace" DNS information that is already in the cache.
For instance, say DNS server 98.76.54.32 has a CNAME record for
www.company.com already and I try to replace it with
www.competitor.com, it will not work. However, there are pieces
of information which can be "added" to. For instance, A records
can be "added" to. If www.company.com has instead an A record to
1.2.3.4 and I send an A record of 4.3.2.1 in my packet,
www.company.com will now have the IP addresses 1.2.3.4 and
4.3.2.1 which will be "randomly" picked between the two whenever
someone queries www.company.com. This can be circumvented with a
little patience. For instance, www.altavista.digital.com has a
TTL of 7200. That means, the DNS server will only cache the
information for www.altavista.digital.com for 7200 seconds or 2
hours. If we put an A record which has an TTL of 604800 or 1
week, then we can effiectively "outlive" the real cached
information. After 2 hours, then our bad information is the only
thing left and the DNS server will then start giving out bad
information. Here is a list of the most commonly used "addable"
and non-"addable" DNS records:
A can add
NS can add
MX can add
PTR cannot add
CNAME cannot add
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)