Multiple DNS implementations vulnerable to cache poisoning
Michael C. Toren
mct at toren.net
Wed Jul 9 05:54:27 UTC 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,
> 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.
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 188.8.131.52
Looking up knzcgp14upi9.toorrr.com against 184.108.40.206
Requests seen for knzcgp14upi9.toorrr.com:
Your nameserver appears vulnerable; all requests came from the same port.
Note that the IP address Dan's service is reporting on is 220.127.116.11,
which is different than the IP address I'm issuing DNS requests against.
In this specific case, it's likely that 18.104.22.168 is configured to use
22.214.171.124 as a forwarder.
Here's an example using the script against a Comcast nameserver, which has
already patched been patched:
bash$ ./noclicky 126.96.36.199
Looking up r14z2k52m6uj.toorrr.com against 188.8.131.52
Requests seen for r14z2k52m6uj.toorrr.com:
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
> 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
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.)
More information about the NANOG