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. I explained it in a paper I
wrote last year I sent it off to Paul Vixie to get a reply (and possibly a
patch) to the problem. The problem is basically this: BIND will cache
ANYTHING that it gets in the return packet. This advisory was
partially leaked to nanog and is known to have been leaked to a number
of other people. Here it is from my original advisory (complete with
spelling and grammar mistakes):
[BEGIN EXCERPT]
4) Explanation of bug
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.
4) Denial of service
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.
5) 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.
6) Limitations
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
[END EXCERPT]
In addition to this problem, 4.9.5+P1 (and probably some derivation of
in older versions) has another problem. Even tho it fixes these problems
it still passes the packet generally untouched onto the remote end. If the
other end does any caching, it'll cache the bad stuff. Also, if the PTR
record has a bad domain name, it'll use it. (I thought this was fixed in
4.9.4?) All of this stems from the fact, that bind basically doesn't touch
the packet when it resends it off to the original querying machine.
Right now, this is playing havok on IRC networks since the ircd server has
it's own resolver library and does some basic caching. Not to mention the
fact that the IRC protocol stream is \n terminated and you can put \n's in
domain names this way.
Now that SNI has broken the silence (and my thunder by releasing first)
I'll explain another "hypothetical" attack. The InterNIC is very dependant
on email. In fact, when someone goes to update a domain, they will send
the change notice to the contacts. What if someone had cached an MX record
on the DNS servers the internic uses to do recursive queries so that when
sendmail goes to send the message, it'll be delivered to another machine
and it just eats it. (btw - that DNS server was mtsfs.internic.net as of a
couple of weeks ago)
Even better is this statement in their template:
7.3. Request from a Sender not listed as a Contact
All the Contacts will be notified before processing the request. If
the InterNIC receives an ACK first before the waiting time indicated
on the Notify Template expires, the request will be processed.
Otherwise, the request will NOT be processed.
Since you're intercepting all of that mail, you can easily ACK the mail
from the InterNIC. I'm exactly sure how to read that, but it looks like to
be if someone else sends in the update then it'll require one of the
contacts to ACKnowledge that the change is legit. I sent some email to
the InterNIC, however (after over a month) have yet to receive a reply. If
there's anyone from the InterNIC reading this, please respond to
NIC-970309.5128 sometime this century.
Also, you can make yourself look like the email is coming from the right
person by caching the PTR/A records on their other DNS server which does
recursive queries when email comes in. (which happens to be
lists.internic.net) Not to mention that rs.internic.net (the MX for
internic.net) is IP spoofable as well. All of the info was legit a couple
of weeks ago. It may have changed now, but I'm not sure. I also won't say
if this ever has been attempted or accomplished :)
Any questions? Please direct them to jerdfelt@sventech.com, I'm busy
working right now but I'll do my best to answer all of the email I get.
Also please forgive any grammar/spelling mistakes. I'm horrible at
English.
BTW - All versions of sendmail blindly copy the domain name into a 514
byte buffer. I haven't gotten my PTR records to get past 420 bytes but I
have a feeling my code to build DNS packets is a little buggy.
JE
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Date: Wed, 23 Apr 1997 14:14:04 +0200
From: Thomas Roessler <Thomas.Roessler@SOBOLEV.IAM.UNI-BONN.DE>
Subject: Re: [linux-security] SNI-12: BIND Vulnerabilities and Solutions (fwd)
In-reply-to: <Pine.LNX.3.95.970422161814.19818A-100000@quick.gt.ed.net>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
To: BUGTRAQ@NETSPACE.ORG
X-To: linux-security@redhat.com
Reply-to: Thomas Roessler <Thomas.Roessler@SOBOLEV.IAM.UNI-BONN.DE>
MIME-version: 1.0
X-Mailer: Mutt 0.70
Content-description: Main Body
Content-transfer-encoding: 8bit
Approved-By: aleph1@UNDERGROUND.ORG
References: <Pine.LNX.3.95.970422161814.19818A-100000@quick.gt.ed.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Length: 999
On Apr 22 1997, Kirk Bauer wrote on linux-security:
> I don't know if this has made it to you yet, so here it is...
[del del del]
> BIND Vulnerabilities and Solutions
As currently discussed on bugtraq, the proposed fix uses a weak
seeding for the random number generator if not using OpenBSD.
Under OpenBSD, an arc4random(3) libc routine which is
essentially RC4 seeded from /dev/arandom is used for this
purpose.
Well, OpenBSD is not the only OS with a /dev/*random, linux has
this too (but it's called /dev/urandom). Nevertheless, I'm not
aware of any libc interface to this. So I've put together a
little one-object-file librandom from OpenBSD's arc4andom
sources (which were trivial to ``port''); the changes to the
(patched) bind code if you want to use this beast are quite
obvious. You can find the source under
ftp://riemann.iam.uni-bonn.de/pub/users/roessler/arc4random.tgz.
HTH, tlr
-- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/