Yesterday, Dan Kaminsky posted a long post about his latest DNS find. In it, he give some incentive to find the bug before his talk!
Now, if you do figure it out, and tell me privately, you’re coming on stage with me at Defcon. So I can at least offer that
And Dan also has a tool on his site to test your DNS server (it appears to go after the DNS server authorizative to your IP address, i.e. the ISP DNS server. When I run the test regularly, it always tells me “All requests came from the following source port: 35353.”
If I were an ISP, I would do this against my own DNS and then watch the wire to see exactly what tests Dan is probing my server with. 🙂 Some further reading by Joe Stewart on DNS cache poisoning and Dan J. Bernstein on various DNS challenges. And yet more DNS challenges. And another nice paper which includes non-spoofing poisoning attacks (btw, papers with no dates in them fail).
Some questions: Is the bug in the servers or actually in the cache gets poisoned on the clients because of a predictable responses? If on servers, I wonder if it is more vulnerable to local networks as opposed to external attackers? Just some thoughts…
I did a packet capture on just what occurs during that test earlier today (running against an in-house DNS server at work, which isn’t reachable from the internet). The tester adds an iframe to the webpage, served up from a random subdomain of toorrr.com. The DNS server for toorrr.com then causes your resolver to chase through several levels of CNAMEs before it gives you the real IP address. Since each of the CNAMEs is looked up in a separate request, the server gets see multiple DNS requests, allowing it to determine whether your recursive DNS server is randomizing the source port. Then either the DNS server itself, or something sniffing the network, analyzes the requests and saves the result somewhere the webserver can get at. When you connect to the webserver soon thereafter, it can look up the result, and generate the HTML to tell you whether you’re vulnerable or not.