On Tue, Jul 08, 2008 at 06:26:01PM -0700, Lynda wrote:
Owen DeLong wrote:
The tool, unfortunately, only goes after the server it thinks you are using to recurse from the client where you're running your browser.
This makes it hard to test servers being used in production environments without GUIs. The tool is not Lynx compatible.
Figures. It's becoming a pointy-clicky world. I don't like it much, either.
[..]
I'll see whether someone can pry the code loose from Dan, rather than having it hidden under a button. As Christian Koch said, the tool isn't really directed at NANOG folk. I'm sure that it could be modified so that it was. I note that BIND has been updated on all your favorite operating systems, which should help some. Still, the updates just barely happened, and then the announcement hit.
Reading through the JavaScript that drives <http://www.doxpara.com/>, it appears to be pretty easy to write a non-AJAX client to query Dan's service. I threw one together in perl, named "noclicky", that allows you to use Dan's service against any nameserver specified on the command line. You can download a copy from <http://michael.toren.net/code/noclicky/>. Here's an example using the script against an unpatched system: bash$ ./noclicky 207.106.1.2 Looking up knzcgp14upi9.toorrr.com against 207.106.1.2 Fetching http://209.200.168.66/fprint/knzcgp14upi9 Requests seen for knzcgp14upi9.toorrr.com: 63.139.151.102:32932 TXID=45460 63.139.151.102:32932 TXID=9718 63.139.151.102:32932 TXID=40448 63.139.151.102:32932 TXID=27861 63.139.151.102:32932 TXID=59838 Your nameserver appears vulnerable; all requests came from the same port. Note that the IP address Dan's service is reporting on is 63.139.151.102, which is different than the IP address I'm issuing DNS requests against. In this specific case, it's likely that 207.106.1.2 is configured to use 63.139.151.102 as a forwarder. Here's an example using the script against a Comcast nameserver, which has already patched been patched: bash$ ./noclicky 68.87.76.181 Looking up r14z2k52m6uj.toorrr.com against 68.87.76.181 Fetching http://209.200.168.66/fprint/r14z2k52m6uj Requests seen for r14z2k52m6uj.toorrr.com: 68.87.76.181:17244 TXID=23113 68.87.76.181:17219 TXID=31336 68.87.76.181:17270 TXID=1613 68.87.76.181:16987 TXID=22846 68.87.76.181:16974 TXID=24013 Your nameserver appears to be safe On Tue, Jul 08, 2008 at 09:22:23PM -0500, Jimmy Hess wrote:
I suspect the tool's form might partly be meant to obscure exactly what patterns it is looking for. Kind of how one might release a vulnerability checker in binary form (but with source code intentionally witheld)
5 query samples would not seem to be a sufficient number to compute the probability that the TXIDs and source ports are both independent and random, with stringent confidence intervals, and that there is no sequence predictability (due to use of a PRNG)...
The logic for determining whether or not a nameserver is vulnerable turns out to be entirely exposed in the JavaScript client. It isn't doing anything with the TXID values, but rather just checking to see if requests were issued from more than one source port. See line 86 of <http://foo.toorrr.com/printme.html>. Also, if you want to see how the service is forcing the client to issue five successive DNS requests, check out the output of dig(1) against foo.toorrr.com. (Disclaimer: I'm somewhat sleep deprived at the moment due to jet lag, and some of the information above could very well end up being wrong. Others are encouraged to double check my work.) Thanks, -mct