DNS security problem details released

The cat is out of the bag. Illuminating details about the DNS security problem have been publicised more or less by accident, before Dan Kaminsky has had the opportunity to reveal them at the upcoming Black Hat Conference. The secret of how to launch the simplified cache poisoning attack is apparently "in bailiwick records". Bailiwick checking ensures that a cacheing nameserver does not accept any unrequested additional resource records if they do not come from the queried domain, i.e. out of bailiwick. This is how the server prevents being slipped an entry for www.noexample.com when it is querying www.example.com.

However, an attacker can still successfully manipulate the cache in combination with a DNS birthday attack. This causes the victim's server, via links contained in emails to users for instance, to query certain addresses, such as aaa.example.com, aab.example.com, aac.example.com and so forth. The victim's nameserver uses a unique transaction ID for each of these queries. The more transaction IDs used, the greater the attacker's chance of obtaining a correct ID using a falsified response and a guessed ID. The probability of actually getting a correct ID for www.example.com is still very slim; however, if the attacker adds an additional resource record (RR) to every response for www.example.com, containing the IP of the server he controls, he can still manipulate the cache, since the RR is "in bailiwick".

According to Matasano Security, which briefly published the details of the security hole in its blog, an attacker with a fast internet connection would only need 10 seconds to carry out such an attack. The blog entry has since been removed – even from the Google cache. But another copy can be found in the pastebin at amd.co.at. Matasano published the details based on speculation in security specialist Thomas Dullien's (aka Halvar Flake) blog. But it is unclear why Matasano was in such a rush to spill the beans, releasing all of the details. In fact, all of Dullien's hunches had already been sketched out the day that US-CERT published a vulnerability note on the security hole. Dan Kaminski had confirmed on Twitter that Halvar Flake's hunches were on the mark, "DNS bug is public. You need to patch or switch to opendns - RIGHT NOW."

That provided another clue. Administrators should not wait any longer to install available patches for their nameservers. By assigning a random source port for each DNS query, these ensure that the attacker will not only have to guess the transaction ID, but also the UDP port. Unfortunately, this still does not solve the problem, but only defers it. For that reason, there is talk of introducing DNSSEC across the board, since the authenticity of the responding server is established via PKI key verification.

See also:

• On Dan's request for "no speculation please", blog entry by Halvar Flake
• Reliable DNS Forgery in 2008, Description by Matasano Security
• Massive DNS security problem endangers the internet, heise Security report

(trk)