Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

DNS Cache Poisoning against djbdns

3 Comments Posted by on February 28, 2009

I’ve been reading up on the newest DNS cache vulnerability. Hot on the heals of the most over-hyped bug of the year (Sorry Dan), comes an attack that actually works against djbdns.

djbA little history. Djbdns (Daniel J. Bernstein’s DNS) was immune to the 2008 Cache Poisoning attacks from Dan Kaminsky as it already implemented the UDP Port randomisation that was marketed as the (temporary) solution to the issue. Although port randomisation doesn’t solve the problem 100%, it makes the attack considerably harder (read longer) to complete. The theory is, that you’ll see an attacker hammering your DNS serer with UDP packets for hours or days before they manage to poison the cache. That is if you’re paying attention to your DNS server. Anyway, a discussion of the 2008 attack vectors isn’t the point here. There are many sources of this already on the interwebs.

The djbdns attack was released on 09.02.2009 by Kevin Day. Full details of the research and examples can be found on his website. The Basics : By using a number of flaws in the dnscache program provided with djbdns, Kevin was able to prove that djbdns is vulnerable to cache poisoning. The attack centers around SOA records and the fact that these are not cached by djbdns. By filling the buffer (defaulted to 200 open requests) with SOA queries, he was able to attempt a collision (matching ID and UDP Port). By having 200 active SOA requests he is in effect increasing the chances of a collision by 20,000%. This reduces the 40 billion packets required for a 50% collision to around 16.8 million packets (not much in computer terms). If the server has been configured to accept more than 200 simultaneous queries, then the attack could be executed even faster.  By constantly rotating the queries (djbdns drops older queries if the buffer is full and a new request comes in) he was able to force djbdns to ignore the official responses from the nameserver, and keep the dns server from accepting a valid response. This attack requires that communication between the attacker and dns cache being poisoned is quicker than the nameserver of the domain being poisoned.

My explanation is a little hard to follow (it’s hard to cram into 10 lines on a blog). So I suggest you hop over to Kevin’s site, read the excellent paper and apply the 3rd party patch to your djbdns server before a Metasploit module appears. Going by previous vulnerabilities, that won’t be long 😉

DJBDNS –> http://cr.yp.to/djbdns.html

Security , , , ,

3 responses to “DNS Cache Poisoning against djbdns”

  1. Dan Kaminsky February 28, 2009 at 17:16

    Just to be clear, the SOA is an accelerant, that allows cached records to be poisoned. But the actual bug is the lack of birthday protection.

  2. ChrisJohnRiley February 28, 2009 at 17:44

    Well there are a number of bugs here. Lack of birthday protection seems to be a common flaw in the architecture of DNS. After all it was never meant to be a secure transaction. DNSSEC to the rescue ??? maybe in 2012 or beyond.

    The flaws that make djbdns’s cache vulnerable appear to be the lack of SOA caching, ability to queue multiple (read 200+) identical requests, and the dropping of older queries when the buffer is full and a new request is received. If any one of these flaws was fixed then djbdns would be no more vulnerable than the other offerings (i.e. 1 in 4 billion chance of cache poisoning).

    Some fixes would be more effective than others obviously. Refusing to drop old requests when the maximum number was reached could cause various Denial of Service issues (users can no longer request resolution, or the server could be overloaded with thousands of requests). Caching the SOA seems to make sense, but as you said this is only an accelerant. With the other flaws left unpatched the server would never receive a valid response (the older queries would drop off the queue and the response from the nameserver would be ignored). SOA caching coupled with prevention of multiple identical requests seems to make sense from my standpoint (not a DNS expert by any means). Although what process is used to match the new request could be another issue altogether. I’d like to see what overhead Kevin’s unofficial patch for this puts on the server under load.

    I’d appreciate your opinions if I’m seeing something wrong here. As I said, I’m no DNS expert ;), I just hack stuff.

  3. Dan Kaminsky March 7, 2009 at 05:04

    There’s lots and lots of partial fixes. The bar I set is that if you don’t protect all names equally, you’re not doing enough. Kevin’s SOA trick works OK but you can just mix his birthday paradox stuff with sibling names from my talk and the attack works essentially just as well.

%d bloggers like this: