Multiple DNS implementations vulnerable to cache poisoning:
http://www.kb.cert.org/vuls/id/800113
(A widely coordinated vendor announcement. As always,
check with your vendor(s) for patch status.)
Gary
Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225
(There's actually some useful data in the comments for a change, or I
wouldn't have bothered.)
Cheers,
-- jra
Additional coverage:
http://news.cnet.com/8301-10789_3-9985815-57.html
http://news.cnet.com/8301-10789_3-9985826-57.html
http://news.cnet.com/8301-10789_3-9985618-57.html
http://www.linux.com/feature/141080
http://www.internetnews.com/security/article.php/3757746
http://www.techmeme.com/080708/p137#a080708p137
Y'know, for you to put on the noticeboard for your help desk, for when
the spooked herd starts calling.
Cheers,
-- jra
This is also being covered over on the Defcon Forums. Jeff Moss has said that he'll post the link to the interview that Kaminsky is doing right now, after it's over. Here's the link to the Forum discussion:
https://forum.defcon.org/showthread.php?t=9547
The forum link also has a link to Dan's tool, where you can see if your DNS server is vulnerable.
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.
Owen
surely the tool is not focused at a dns operator/admin audience..
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.
This is also being covered over on the Defcon Forums. Jeff Moss has said that he'll post the link to the interview that Kaminsky is doing right now, after it's over.
Here's the direct link, for the curious:
Audio of Dan's press interview:
https://media.blackhat.com/webinars/...conference.mp3
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.
As a /.er noted, running that tool after *accessing it via DNS* may not
tell you anything, and I don't know that Kaminsky has himself
publically announced the IP address of his test machine.
Cheers,
-- jra
Christian Koch wrote:
surely the tool is not focused at a dns operator/admin audience..
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)...
More exhaustive tool would operate on tcpdump output or run live with pcap, gather samples of sequences of TXIDs,
port numbers, timestamps.
And perform tests for independency between TXID and port number, timestamp,
and some statistical tests for randomness.
The tool, unfortunately, only goes after the server it thinks you are using
to
recurse from the client where you're running your browser.
The very nature of the tool (remote probe by an outside server) also makes it impossible for it you to probe
intermediary DNS servers.
For example, you might resolve using vulnerable recursive server that forwards all queries to a 'safe'
recursive server.
The TXIDs generated by the 'vulnerable' server are never seen by the remote web server.
Re: the tool
My DNS server does not serve the outside world. Incoming packets to port
53 are NAT directed to an non-existant IP on the LAN.
The tool uses my internet facing IP as my DNS server and tells me I am
vulnerable. Since, from the internet, connecting to that IP at port 53
will not get you to a DNS server, I find the tool's conclusion rather
without much value.
Once upon a time, Jean-Fran�ois Mezei <jfmezei@vaxination.ca> said:
The tool uses my internet facing IP as my DNS server and tells me I am
vulnerable. Since, from the internet, connecting to that IP at port 53
will not get you to a DNS server, I find the tool's conclusion rather
without much value.
There are many ways to get your server to look something up other than
allowing direct queries.
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
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
Michael C. Toren wrote:
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
Thanks for the explanation. I used wireshark to capture the DNS traffic
My DNS server made the various DNS requests from the same port and is
thus vulnerable. (VMS TCPIP Services so no patches expected).
Well, yes, but unless I've badly misunderstood the situation, all
that's necessary to mitigate this bug is to interpose a non-buggy
recursive resolver between the broken machine and the Internet at
large, right?
So just make sure your corporate/campus edge router has a reasonable
named on it, and point everything broken at that, and you should be ok,
even though, as you note, DEC won't be updating VMS any time soon. 
Cheers,
-- jr 'Compaq? No, that's HP now, isn't it?' a
He said "DNS server", which you wouldn't want to point at a correct named,
because that would be forwarding, and forwarding has its own security issues.
I've already dragged a name server here back to a supported OS version today
because of this, don't see why others should escape 
> > My DNS server made the various DNS requests from the same port and is
> > thus vulnerable. (VMS TCPIP Services so no patches expected).
>
> Well, yes, but unless I've badly misunderstood the situation, all
> that's necessary to mitigate this bug is to interpose a non-buggy
> recursive resolver between the broken machine and the Internet at
> large, right?He said "DNS server", which you wouldn't want to point at a correct named,
because that would be forwarding, and forwarding has its own security issues.
Assuming that he actually meant "name server" and not "the resolver
library on my VMS machine" -- lots of Unix boxes don't run a local
named either. No offense to JF...
I've already dragged a name server here back to a supported OS version today
because of this, don't see why others should escape
Well, in his case, for the same reason that no one will be upgrading
the resolver library on Win98 if it's broke, I think.
Cheers,
-- jra
It's worth noting that the basic idea of the attack isn't new. Paul
Vixie described it in 1995 at the Usenix Security Conference
(http://www.usenix.org/publications/library/proceedings/security95/vixie.html)
-- in a section titled "What We Cannot Fix", he wrote:
With only 16 bits worth of query ID and 16 bits worth of UDP
port number, it's hard not to be predictable. A determined
attacker can try all the numbers in a very short time and can
use patterns derived from examination of the freely available
BIND code. Even if we had a white noise generator to help
randomize our numbers, it's just too easy to try them all.
The ISC web page on the attack notes "DNSSEC is the only definitive
solution for this issue. Understanding that immediate DNSSEC deployment
is not a realistic expectation..." I wonder what NANOG folk can do
about the second part of that quote...
--Steve Bellovin, http://www.cs.columbia.edu/~smb
get the root zone signed, get com/net/org/ccTLD's signed.. oh wait,
that's not nanog... doh!
Pressure your local ICANN officers?
-Chris
How many ISPs run DNS servers for customers? Start by signing those
zones -- that has to be done in any event. Set up caching resolvers to
verify signatures. "It is not your part to finish the task, yet you
are not free to desist from it." (From the Talmud, circa 130.)
No, I didn't say it would be easy, but if we don't start we're not
going to get anywhere.
--Steve Bellovin, http://www.cs.columbia.edu/~smb