North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Multiple DNS implementations vulnerable to cache poisoning

  • From: Michael C. Toren
  • Date: Wed Jul 09 01:54:43 2008 
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