DNS Cache Poisoning Webcast


UPDATE: Full audio of the webcast is now available

Today Black Hat held a preview webcast with [Dan Kaminsky] about the massive DNS bug he discovered. On July 8th, multiple vendors announced a patch for an undisclosed DNS vulnerability. [Dan Kaminisky] did not release the details of the vulnerability at that time, but encouraged security researchers to not release their work, if they did happen to discover the bug. On the 21st, the full description of the vulnerability was leaked.

In today’s webcast, [Dan] covered how he felt about the handling of the vulnerability and answered a few questions about it. He started out by talking about how he stumbled across the bug; he was working on how to make content distribution faster by using DNS to find the server closest to the client. The new attack works because DNS servers not using port randomization make it easy for the attacker to forge a response. You can read the specifics of the attack here.

[Dan] talked about the work that had been done since the July 8th announcement. A handful of researchers had contacted him with exact bug in hand, but as requested, did not release the information. When first announced, 86% of all servers voluntarily tested using the checker on doxpara.com were vulnerable. 13 days later, the vulnerability was published and only 52% of the people using the checker are vulnerable. That’s not perfect, but 13 days gave plenty of companies enough time to both test and roll out their patches.

[Jerry Dixon], the former Director of the National Cyber Security Division, pointed out that even though the vulnerability was eventually leaked, the patches had already been out for 13 days; this isn’t a zero day vulnerability with no fix. So, we’re in a fairly good position. That being said, even since our Metasploit announcement yesterday, they’ve pushed new module code that will take over an entire domain. Security researcher [Rich Mogull] has feels that producing this exploit code quickly was “bullshit” and “only helps the bad guys“.

[Dan] pointed out that some related work people have been doing to mitigate DNS cache poisoning using firewalls. [Michael Rash] wrote about using iptables in Linux to randomize outbound requests and [Jon Hart] covered using PF in OpenBSD. The team is actively contacting vulnerable servers to get them to patch. They’ve also advised IDS vendors to look for multiple replies with the same ID as a telltale sign of this attack.

You can check your DNS servers using the tool on doxpara.com. We’ve personally switched our machines to OpenDNS‘s servers 208.67.222.222 and 208.67.220.220. Not only did it give us some piece of mind, but the performance is way better than our ISP’s overloaded DNS.

4 thoughts on “DNS Cache Poisoning Webcast

  1. after the NANOG mailing list blew up my inbox, i realized that this was a big deal. i’ve tried running the doxpara tool on my home isp but it’s not working, so i too switched my router over to opendns. i’m just not a fan of the covert redirection and possible datamining of my dns requests. soon my isp should patch this issue and i can switch away from openDNS.

    for more info, see http://en.wikipedia.org/wiki/opendns#privacy_issues_and_covert_redirection

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.