Just a quick note
1) Yes, I’m doing a webcast with Black Hat on the 24th
2) No, I’m not releasing the exploit early.
Now, let me be clear. Oh wow, I wish I could drop the technical details on the 24th. Did I really just sign up for a month of this? But, no. The webcast will be good. The webcast will have interesting information. You should indeed attend the webcast. But I’m not screwing up everyone’s schedules with a huge “WHUPS JUST KIDDING”. Details are being held until either August 6th at 11:15AM Pacific (thanks, Travis!), when I talk at the Black Hat Briefings.
Just a l’il while longer, guys.
Categories: Security
Dan Kaminsky's Blog 
Thank you.
Thank you more than you know, especially for dealing with it — and not “spilling the beans”.
You exhibit a professional self-control that most of us envy. You have talent we envy too! :p
This issue blew me away. The more I dig into your site, the more I’m amazed.
This is a great tool for checking DNS servers for the cache poisoning vulnerability. Is there any way you can make the form take an IP address as input, so I can use it to check the DNS servers I manage? I just applied the Red Hat patch.
Eddie
Nice Tools,
Thank you
Thank you friend, for this tools.
Dan,
How do we test servers behind closed networks? Yes, the redirection impact is minimal (in a closed network), but if this threat is for real, the disruption potential is HUGE.
Is there a tool/method that we can deploy before or on Aug 7 we can give a list of NS IPs to test for random IDs/ports? Sure, we can demand people “patch” — but there is nothing like a tool/test to walk through our NS server IPs so we can KNOW what is out there on our networks.
Is there anything availble, or do we need come up with our own solution?
Thanks!
Eddie –
If you look at the code, and figure out what it’s doing, you’ll see that what you’re asking isn’t possible.
Basically, it forces the client to query a random name in toorrr.com. The DNS server for that domain then records queries it receives. You’re browser is then shown a page which displays the records for the name it just queried. As such, the whole thing is client side – the server’s only involvement is in requesting the name on behalf of it’s client. There’s no way to check a given server, other than to make that server query a random name at toorrr.com.
If you really wanted to check a server, you could generate your own name, query it on that server via NSLookup or dig, and then grab the resulting page from toorrr.com. However, toorrr.com only displays results for queries within the first few seconds after it sees the queries, so you’d likely need to script this the do it within the alloted time – or write your own checker using Dan’s code as an example.
Dan,
Can you comment on this vulnerability and how it relates to NeuStar’s UltraDNS platform? Since they are not running a BIND based resolver code would they still be affected by this flaw?
Please let us know.
Thanks!
Also note that the dns-oarc test is great for that situation.
Run a command line the following, where the 1.2.3.4 is your DNS server.
dig @1.2.3.4 +short porttest.dns-oarc.net TXT
The results will show if your ports look random, including a simple test of the standard deviation for (very roughly) estimating how random the values are.
More info here:
https://www.dns-oarc.net/oarc/services/porttest
http://www.alexa.com/
see you there