Date: Wed, 9 Jul 2008 15:51:35 -0500
From: "Fredrick Diggle" <fdiggle@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: [FDSA] BIND's vulnerability to packet forgery

From: ("D. J. Bernstein^H^H^H^H^H^H^H^H^H^H^H^HKaminsky")
Newsgroups: mailing.unix.bind-users^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hfull-disclosure
Subject: Re:^H^H^H BIND's vulnerability to packet forgery
Date: 29^H^H8 Jul 2001^H8 22:14:25 +0800

Jim Reid writes:
> Wrong. From setup_lookup():
> lookup->sendmsg->id = (unsigned short)(random() & 0xFFFF);
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
Wrong.^H^H^H^H^H^H I said ``cryptographic randomization.'' The output
of random() is
not cryptographically secure. In fact, it is quite easily predictable.
This is a standard exercise in first-semester cryptography courses.

> Randomising the port number for each query achieves precisely nothing.
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
Wrong. Randomizing the port number makes a huge difference in the cost
of a forgery for blind attackers---i.e., most attackers on the Internet.
Here's the picture:

                     normal         colliding      sniffing
                     blind attack   blind attack   attack
                     ------------   ------------   --------
   nothing           1              1              1
   ID (BIND)         65536          256            1
   ID+port (djbdns)  4227727360     65020          1

It's funny that the BIND company has gone to so much effort to move from
the first line to the second, but now pooh-poohs the third line.

> > Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html, the
> > current reality is that DNSSEC does nothing to prevent forgeries.
> Really? When were RSA and DSA broken?
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
Do you think that ``RSA'' is a magic word that makes security problems
disappear? Withotu a central key distribution system---a system that
doesn't exist now and won't exist for the foreseeable future---DNSSEC
doesn't stop forgeries.

---Dan^H^H *Oh wait!*an


I think you are confused here. Let me clarify.
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
I want the A record for HOME.NETSCAPE.COM. I send a query for it to
NS.MCI.NET, with the query ID "10".

Immediately thereafter, I receive 15 responses, forged to appear to come
from NS.MCI.NET, with IDs ranging from "20" to "65500". None of them can
possibly be valid, and there's no legitimate reason that I should be
receiving these responses. I (nameserver) therefore make the determination
that I am under attack.

At this point, I can either log the fact and ignore what's happening, in
which case the attacker will simply continue to send forged responses
until one of them happens to bear the query ID "10", or I can decide "hey,
I'm going to ignore even a valid response from NS.MCI.NET at this point,
because I have no way to tell that it isn't forged".

The problem with this is that it allows a trivial denial of service
attack. I'm Karl Kashpureff, and I want to prevent anyone at Netcom from
being able to resolve WWW.NETSOL.COM. All I do is send a consistant stream
of forged responses from the listed authority servers for NETSOL.COM to
Netcom's nameservers. They will no longer be able to resolve NETSOL.COM,
since every query they open up will be immediately invalidated by a fake
response.

What I'm saying probably makes the ID guessing attack look much simpler
than it really is. This is because, in the real world, there are actual
authority servers that actually receive the sent query. Even in the
absence of countermeasures such as the one outlined above, brute-force ID
guessing attacks are extremely difficult, since the correct ID needs to be
guessed prior to the receipt of a legitimate answer by a real server.

The 4.9.6 resolution to the ID-guessing problem contributes randomized
query IDs to this. In the presence of randomized query IDs, and in the
absence of attacks on the legitimate authority servers, it's probably
reasonable to assume that DNS is reliable in the face of an attack, due to
the extremely low likelihood of guessing the right one out of sixty-five
thousand IDs before a valid response.

However, in the presence of an attack on the legitimate authorities, we
have a real problem. If I can cause all the listed authorities for a
domain to cease responding to queries, I can set myself up for a
completely successful spoofing attack on the records they're answering
for. There's a real issue here involving the fact that, right now, /any/
denial of service attack in BIND (and we've just seen one of them posted
to Bugtraq) potentially allows for the compromise of nameserver caches.

A proposed countermeasure for this involves something I've taken to
referring to as "DNS cookies". The goal is to ensure that the listed
authority servers are capable of answering questions; that is, we'd like
to know if an attacker will have to beat out a legitimate server in a
brute force attack (in which case the attack will be difficult to carry
out), or whether the attacker will always be successful, since the
authorities can't assert the right information.

The idea is to send a random nonrecursive query to the authority server
being queried, in addition to (in a seperate packet) the real query. Using
a second query as a cookie allows us a massive random number space; we can
safely assume that the receipt of an answer for the random "cookie" query
means that the listed server is alive and answering.

This method would only be used when it's determined that the nameserver is
under attack, and should therefore add minimal load to the DNS system. In
place, the attack changes from something with deterministic chances of
success (I /will/ eventually hit on the right ID) to something with a very
slim probability of success (I'll eventually hit the right ID, but the
likelihood of doing so before the real server answers is minimal).

So, there's another piece of input. There are other ideas, too.

----------------
Thomas Ptacek^H^H^H^H^H^H^H^H^H^H^H^H^HDan Kaminsky at EnterAct,
L.L.C.^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HDoxpara Research, Chicago,
IL^H^H^H^H^H^H^H^H^H^H^H []
----------------
"If you're so special, why aren't you dead?"
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H



^----------- Dan Kaminsky discloses uber critical vulnerability in the internet

- Fredrick Diggle

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists