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

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

Tag Archives: djbdns

DNS Cache Poisoning against djbdns

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