12.2.2014: Dan Bernstein's: dnscache compromised at the CCC

The German Chaos Computer Club CCC -- which stands for a free Internet and is in particlur critcal against the German government's Internet politics -- has been subject of a lare scape Birthday attack against their public available DNS cache server (IP: 213.73.91.35) [1].

This DNS cache server hast been setup and promoted in particluar to provide un-censored answers from the DNS, unlike answers originating from other DNS caching servers from ISP's which are subject of 'Internet filtering' due to the 'child pornography' debate in 2009 [2].

Thus, the often self-declared 'hackers' of the CCC have been subject of attacks from other 'hackers'. This is in particular striking, because the CCC used Dan J. Bernsteins 'djbdns' [3] and here specifically 'dnscache' which was thought to be immune against those attackes due to it's superior design and careful implementation published as 'djbdns 1.05' in 2001 [5]. However, in 2008 a vulnerability of 'dnscache' was discussed by Jeff King [6] and subsequently some patches ware developed and made public -- which never were introduced officially into 'djbdns' since Dan Bernstein made that package 'public domain' in 2007 and this particular attack is not covered by Bernstein's guarantee [4].

Howerver, having a closer look about 'dnscache' and it's design, it turns out -- as already discussed here [7] -- that unlike it's name, it is not a cache poisoning per se -- but rather a failure of resolver lookups and subsequent wrong entries in the cache. Let's have a look what was happening:

(a) Standard Birthday attacks guess the 'transaction id' TID of the DNS queries and provide to the Resolver a wrong answer with the very same TID and query.

(b) Dan Bernstein has analysed this weakness and while providing an exceptional good random generator (PRNG) to generate the TID, he introduced 'source port' randomization as well, which was neglected by BIND until recently. This chance to find the correct combination for cache posioning is now at a level of 2x109.

(c) However, djbdns' Resolver posses a query&answer queue which is triggered by the every query and flushed upon a successful response. Despite the very same question (say: IP ? www.microsoft.com) every query has it's own queue (based on the TID) while the final answers are put in the cache. Once the response is in the cache, answers to all queries are taken from here. Here, the first response wins the race. Sending 1000 identical queries, the chance to win the race climbs up to 2x106. This is feasible, even on a 10 Mbit/s line, but then we not only talk about cache poisoning, but rather this is an effective Denial of Service (DoS) attack.

In effect, prior to any cache poisoning, a significant DoS attack compromises the DNS cache anyway and makes it unresponsive for any service [7] thus stoking at just 10cc [8].

Though Jeff King was provided a patch, to circumvent this situation, 'merging' identical queries in one queue; the DoS part of the attack can not be solved by technical means, but rather by infrastructure and/or architecture.

Fortunately, Dan Bernstein's 'djbdns' provides already the means to care about this situation, but was neglected by the CCC:

(1) If you ran a public DNS cache, decouple it from the Recursive Resolver: 'dnscache' allows to br run in a 'caching-only' mode simply as cache, while forwarding the queries to dedicated Resolver (FORWARDONLY). This is typically another instance of 'dnscache' with different parameters.

(2) The public available IP address of the DNS cache should not identical to the Resolver's IP. In fact, it is the Resolver which is vulnerable by the Birthday attack.

(3) Each and every public Internet service needs to be monitored and analysed for service degradation and erratic behaviour/results. This is an operational requirement in addition.

The CCC ('erdgeist') exchanged finally 'dnscache' with 'unbound' [9]. This simply does not solve the architectural and operational deficiencies.

In addition, it is not the blame of Dan Bernstein regarding the design of 'djbdns' but rather a simplistic believe in short-hand technical solutions.

 


[1] www.heise.de/security/meldung/DNS-Server-des-CCC-als-Werbeschleuder-missbraucht-2111501.html
[2] www.stern.de/digital/online/internetsperren-stoppschild-gegen-kinderpornos-im-web-661190.html
[3] cr.yp.to/djbdns/dnscache.html
[4] cr.yp.to/djbdns/guarantee.html
[5] www.fehcom.net/diary/2012/cachepoisoning.pdf
[6] www.your.org/dnscache/
[7] www.heise.de/foren/S-DNS-vom-CCC-down/forum-10541/msg-24759990/read/
[8] en.wikipedia.org/wiki/10cc
[9] www.ccc.de/de/updates/2014/cache-poisoning-attack