Re: djbdns/dnscache poisoning weakness

On Thu, 12 Feb 2009, Kevin Day wrote:

> Step 1: The client asks dnscache to look up a record.
> Step 2: dnscache checks to see if the information the client wants is  
> already cached, if so send it to the client and stop here.
> Step 3: If not, dnscache connects to the authoritative server for that  
> domain, passes on the request and waits for a reply.
> Step 4: The authoritative server replies, dnscache checks to see if it  
> appears authentic, caches that reply, and passes the result on to the  
> client who requested it initially.
> 
> In step 4, I say "dnscache checks to see if it appears authentic". How  
> does it do this? When dnscache made the request to the authoritative  
> server, it included 5 important pieces of information. They are:

> 1) The IP address of the authoritative server it contacted.
> 2) The name of the resource it was looking up. ("example.com")
> 3) The type of query it was making. (A, PTR, MX, etc)
> 4) A randomly generated 16-bit number called a "query ID".
> 5) A randomly generated "source port", included in the UDP header.
> 
> When the reply comes back, all 5 must be correct or dnscache  
> completely ignores the reply.

This is what DNScache has done since the beginning. This is why DJB
wrote DNScache. Its not what BIND did, despite warnings from Bernstein
to use the UDP port to make poisoning more difficult.


> Now, pretend we're in the "pre-Kaminsky-attack" days. 

No change. Except for BIND, which hadn't adopted Bernstein's 
recommendation. Everyone else did in about 2006; that's 
"pre-Kaminsky-attack" days.


> One of the things I discovered was that dnscache makes no attempt to  
> stop duplicate outgoing queries from happening at once. Essentially,  
> if 200 clients request the address for "www.example.com" all at once,  
> and dnscache doesn't have "www.example.com" in its cache, it makes 200  
> requests to example.com's authoritative servers to look it up. A tad  
> inefficient, but usually a short lived phenomenon. From an attacker's  
> point of view, this actually helps them though. 

> Repeat the scenario above, modified to take advantage of this:
  ^^^^^^^^^^^^^^^^^^^^^^^^^^

Ah. The scam. "Lather, Rinse, Repeat, and success". There are lots of
algorithms to "lather rinse repeat and successfully break crypto. Trial
division eventually factors all RSA moduli.  Weren't not worried about
https, though.

In this case, one has to repeat the scenario using 28 million packets to
get one that will match, before a real packet is received.  This is
quite hard to do, harder still to get past an IDS, a lot harder than the
mere 65000 packets that it took to spoof BIND.  TCP is quite a bit
harder yet.

The fear factor is in the 'just repeat and you'll succeed eventually'.  
This is true, just not realistic.

If you want very secure DNS, use TCP. 

		--Dean





-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000