Re: djbdns/dnscache poisoning weakness

I recommend ignoring these patches and avoiding any server that uses
these patches. 

I have discovered that Kaminsky was searching for open recursors roughly 
during the time of the first open recursor attack reported in October 
2005.  Kaminsky reported finding about 500,000 open recursors at 
Schmoocon in January 2006. 

When the 'DNS cache scare' started last summer, Kaminsky tried to get
people to convert to David Ulevitch's OpenDNS service. The scare also
prompted efforts to promote DNSSEC.  These are "scare" scams, not
legitimate threats for which people should change DNS software.

Previous analysis of the Kevin Day/Dan Kaminsky proposed changes to
DNSCACHE revealed that they would ADD EXTREME WEAKNESS not fix weakness,
making it possible to poison a cache in about 1000 messages. I have not
yet analyzed the BIND changes, and do not know if they suffer the same
weaknesses as the DNSCACHE changes.

I see nothing here to change that opinion.

Some more inline.

		--Dean


On Mon, 9 Feb 2009, Kevin Day wrote:
> 
> Dnscache's weaknesses:
> 
> 
> 1) Dnscache treats "SOA" requests as uncacheable.
> 
> There are several types of DNS query types, used to ask for different  
> information about a domain. The "Start of Authority" (SOA) type is  
> used to ask for certain data about the management and cache policies  
> for the domain. When receiving a reply from the real server about an  
> SOA request, it tells the client who requested it everything it found,  
> then immediately forgets the reply. This makes the "Kaminsky" attack  
> (described above) much simpler, and improves its efficiency slightly.
> 
> Alone, this is not a major problem, but combined with the problems  
> below it has a multiplying effect.

SOA should not be cached; if it is cached, one can't find out if the SOA
has changed promptly, and zone transfers won't work in a timely manner.  
There is no reason to cache SOA records.

> 2) Dnscache makes no attempt to prevent simultaneous identical queries  
> from going out at once.
> 
> By default, dnscache allows up to 200 queries to be "in progress" at  
> once. However, it doesn't check to see if it's already waiting for a  
> response for a query before asking the same question again. Using the  
> SOA weakness above, the attacker can make the same SOA request over  
> and over until they succeed in poisoning the server. An attacker can  
> take advantage of this by requesting the same query 200 times, then  
> send a flood of forged replies.

We have already analyzed this. This attack requires some 20 million
packets to succeed. Reducing the number of outstanding queries increases
the effort.  The proposed changes made the dnscache server much weaker, 
exploitable in about 1000 messages instead of 20 million.

> 3) When dnscache hits its query limit, it silently drops the oldest  
> query in progress.
> 
> As mentioned above, dnscache has a strict limit of how many queries it  
> can be working on at once. If the defaults haven't been changed,  
> dnscache can be looking up 200 answers to clients' questions at a  
> time. If all 200 slots are full and another client asks a question,  
> the query that's been waiting the longest is aborted. This makes good  
> sense. If many users are trying to lookup a popular website's address,  
> and that site's DNS servers are unresponsive, you don't want all 200  
> slots tied up on queries that aren't going to get an answer.
> 
> However, this makes an attacker's job even easier for poisoning. By  
> sending new queries fast enough that the oldest query is kicked out  
> before the real server's response reaches the victim, the victim will  
> never learn any answers from the real server. The scenario looks like  
> this:
> 
> Step 1: Through some careful timing analysis, the attacker can  
> determine how long it takes the victim to receive a reply from the  
> real server. Assume the attacker determines that it takes no less than  
> 1/10th of a second(100ms) for the real reply to reach the victim.
> Step 2: The attacker sends a flood of queries to the victim, filling  
> all 200 slots.
> Step 3: Due to the lack of duplicate query checking mentioned in #2  
> above, the victim rushes to send the real server 200 queries.
> Step 4: The attacker floods the victim with forged responses, hoping  
> to guess the random numbers correctly.
> Step 5: Just before the oldest query in the 200 slot window reaches  
> 100ms in age, the attacker sends a new query to the victim.
> Step 6: The victim throws away the oldest query, and issues a brand  
> new request.
> Step 7: When the real reply from the real server comes in for the  
> query that was just thrown away, the victim doesn't recognize it and  
> discards it.
> Step 8: Go back to Step 4 until success.

Without careful analysis, I'm quite dubious of this claim. Once an 
oustanding queryid is dropped, so is the record of its queryid. One 
still has a 1 in 20 million chance of hitting the right port and right 
queryid.

		--Dean


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