Multiple DNS implementations vulnerable to cache poisoning
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
On Tue, Jul 08, 2008 at 01:48:57PM -0700, Buhrmaster, Gary wrote:
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.)
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
On Tue, Jul 08, 2008 at 07:20:05PM -0400, Jay R. Ashworth wrote:
Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
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. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks
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 On Jul 8, 2008, at 5:12 PM, Lynda wrote:
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.
-- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks
surely the tool is not focused at a dns operator/admin audience.. On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong <owen@delong.com> 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.
Owen
On Jul 8, 2008, at 5:12 PM, Lynda wrote:
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.
-- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks
-- ^christian$
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.
On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong <owen@delong.com> 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.
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.
This makes it hard to test servers being used in production environments without GUIs. The tool is not Lynx compatible.
Owen
-- -J
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
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.
Since it appears as though a significant part of the solution is tied to upgrading to new code, which implements better PRNG *and* random source ports, it seems that one indicator for vulnerability is simply the reuse of a source port number, which should be trivial to identify without any concern for having to look for "patterns" within the PRNG-generated TXID. You do not necessarily need to be able to verify that something is NOT vulnerable in order to detect vulnerability. Your answers will only be "is vulnerable" and "might be vulnerable" of course, but that's useful all by itself. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
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.
On Jul 8, 2008, at 5:12 PM, Lynda wrote:
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. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks
On Tue, Jul 8, 2008 at 8:26 PM, Lynda <shrdlu@deaddrop.org> wrote:
Audio of Dan's press interview:
Actual URL: https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conference.m... Jeff
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
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 from my server to the outside world while running the doxpara.com test. My DNS server made the various DNS requests from the same port and is thus vulnerable. (VMS TCPIP Services so no patches expected).
On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote:
On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
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. 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 ;)
On Wed, Jul 09, 2008 at 02:38:38PM +0100, Simon Waters wrote:
On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote:
On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
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/>.
It looks like Dan changed what it returns, and noclicky 1.00 gets confused. You can fix this, atleast until MCT comes out with a new version, by putting : my $date = shift @data; before the line : print "Requests seen for $domain:\n"; Tuc/TBOH
On Jul 11, 2008, at 7:58 AM, Tuc at T-B-O-H.NET wrote:
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/>.
It looks like Dan changed what it returns, and noclicky 1.00 gets confused. You can fix this, atleast until MCT comes out with a new version, by putting :
my $date = shift @data;
before the line :
print "Requests seen for $domain:\n";
Tuc/TBOH
Sorry to necro this, but the original version will lead to a false sense of security and people might be finding it in the archives... --- noclicky-1.00.pl Fri Jul 25 02:02:16 2008 +++ noclicky-1.01.pl Fri Jul 25 02:11:18 2008 @@ -64,10 +64,12 @@ my %ports; for my $data (@data) { - chomp($data); - my ($ip, $port, $txid) = split "-", $data; - print " $ip:$port TXID=$txid\n"; - $ports{$port} = 1; + if ($data =~ /^[1-9]/) { + chomp($data); + my ($ip, $port, $txid) = split "-", $data; + print " $ip:$port TXID=$txid\n"; + $ports{$port} = 1; + } } Thanks to Michael for the tool, though! Brian Keefer Sr. Systems Engineer www.Proofpoint.com "Defend email. Protect data."
On Tue, Jul 08, 2008 at 05:12:04PM -0700, Lynda wrote:
The forum link also has a link to Dan's tool, where you can see if your DNS server is vulnerable.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
On Tue, 8 Jul 2008 13:48:57 -0700 "Buhrmaster, Gary" <gtb@slac.stanford.edu> wrote:
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.)
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
On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
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...
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
On Wed, 9 Jul 2008 12:05:38 -0400 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
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...
get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, that's not nanog... doh!
Pressure your local ICANN officers?
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
On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
On Wed, 9 Jul 2008 12:05:38 -0400 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
Pressure your local ICANN officers?
How many ISPs run DNS servers for customers? Start by signing those
This is likely going to mean some mean OSS changes and perhaps re-adjustment of where customer zones live to deal with extra load on auth servers... Also, the customer(s) likely have to ask for that sort of thing to happen, and include in their OSS re-signing/verifying/blah when they make changes to their zone(s).
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
yup, more server load considerations, for services not being paid for directly by customers... also, this is but a small minority of the affected devices here. Not that it's not important, but there are other parts of the dns pie. Someone mentioned CPE devices doing cache-resolving as well, if their upstream is an affectd device they are vulnerable, if they are vulnerable they could be subverted :( My point was really, how do we get dns-sec rolling? From the top-down that's 'bug icann' right? and from the bottom-up that's: 0) update applications to meaningfully use dnssec data 1) educate users/domain-owners 2) roll infrastructure to the ISP/Enterprise 3) make sure the CPE/end-systems are prepared for dnssec 4) update OSS bits down the dns-tree 5) deploy 6) rejoice? Just saying "DNSSEC is the answer" is cool, but we've (network/security community) been saying that for 10 years. How does this move forward?
No, I didn't say it would be easy, but if we don't start we're not going to get anywhere.
yup.
On Wed, 9 Jul 2008 13:06:53 -0400 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
On Wed, 9 Jul 2008 12:05:38 -0400 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
Pressure your local ICANN officers?
How many ISPs run DNS servers for customers? Start by signing those
This is likely going to mean some mean OSS changes and perhaps re-adjustment of where customer zones live to deal with extra load on auth servers... Also, the customer(s) likely have to ask for that sort of thing to happen, and include in their OSS re-signing/verifying/blah when they make changes to their zone(s).
Precisely my point. (In a related vein, how many folks started updating their OSSs a few years ago to handle IPv6 addresses?)
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
yup, more server load considerations, for services not being paid for directly by customers... also, this is but a small minority of the affected devices here. Not that it's not important, but there are other parts of the dns pie. Someone mentioned CPE devices doing cache-resolving as well, if their upstream is an affectd device they are vulnerable, if they are vulnerable they could be subverted :(
My point was really, how do we get dns-sec rolling? From the top-down that's 'bug icann' right? and from the bottom-up that's:
0) update applications to meaningfully use dnssec data 1) educate users/domain-owners 2) roll infrastructure to the ISP/Enterprise 3) make sure the CPE/end-systems are prepared for dnssec 4) update OSS bits down the dns-tree 5) deploy 6) rejoice?
Just saying "DNSSEC is the answer" is cool, but we've (network/security community) been saying that for 10 years. How does this move forward?
Maybe this attack will help... More seriously -- unlike v6, the pieces here can be updated independently; they'll then DTRT when the proper bits start showing up on the wire. Enterprises can sign their own zones, and give (with help from Microsoft, of course) their employees resolvers and configurations that know to expect signatures for that zone. Enterprises and consumer-facing ISPs can start deploying caching resolvers that use the AD bit and TSIG when talking to clients. The pressure on ICANN and down from there can happen at the same time. Some day, they'll meet in the middle... --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 9 Jul 2008, Steven M. Bellovin wrote:
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.
Are these the same ISPs that haven't started implementing other anti-spoofing controls like BCP38++? What is the estimated completion date to stop all spoofed IP packets, included but only DNS spoofing?
On 9 Jul 2008, at 12:05, Christopher Morrow wrote:
On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin <smb@cs.columbia.edu
wrote:
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...
get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, that's not nanog... doh!
The timeline for signing ORG was presented by PIR at the recent ICANN meeting in Paris. http://par.icann.org/files/paris/RaadDNSSEC.pdf The estimated timeline expressed that slide would have a signed ORG zone containing some DS records by the beginning of next year, with full mainstream availability (such that any registrant could use a DNSSEC-capable registrar to request a secure delegation) in 2010. Joe
On Jul 9, 2008, at 9:05 AM, Christopher Morrow wrote:
Understanding that immediate DNSSEC deployment is not a realistic expectation..." I wonder what NANOG folk can do about the second part of that quote...
get the root zone signed, get com/net/org/ccTLD's signed.. oh wait,
There are 4 ccTLDs (se, bg, pr, br) that are signed. As Joe has indicated, ORG is moving towards signing their zone (as are several more ccTLDs).
that's not nanog... doh!
Pressure your local ICANN officers?
Mmph. https://ns.iana.org/dnssec/status.html (it's out of ICANN's hands) Regards, -drc
Pressure your local ICANN officers?
Mmph. https://ns.iana.org/dnssec/status.html
(it's out of ICANN's hands)
Huh!? Then what does this following statement refer to? (c) 2008 The Internet Corporation for Assigned Names and Numbers. I found that at the bottom of the IANA page whose URL you quoted. At the bottom of the IANA home page http://www.iana.org/ it is stated a bit more explicitly: IANA is operated by the Internet Corporation for Assigned Names and Numbers It sounds like ICANN has the matter well in hand to me given that it is only responsible for the common central bit of the DNS system. The rest of the job is everyone's problem. --Michael Dillon
On Jul 9, 2008, at 10:39 AM, <michael.dillon@bt.com> <michael.dillon@bt.com
wrote:
Pressure your local ICANN officers? Mmph. https://ns.iana.org/dnssec/status.html (it's out of ICANN's hands)
Huh!? ... It sounds like ICANN has the matter well in hand to me given that it is only responsible for the common central bit of the DNS system.
Two answers: 1) The term 'signing the root' means a whole lot more than running dnssec-signzone over zone data. Specifically, the URL I provided shows that IANA is _already_ signing the root (more or less) and has been for over a year -- IANA actually has a _very_ elaborate and secure infrastructure (including multiple FIPS 140-3 hardware security modules, air gaps, physical security, and all sorts of other stuff) for root signing. The fact that root zone data you receive from the root servers is not signed may suggest that there is a bit more that needs to be done and pretty much all of that is NOT something ICANN has direct control over. 2) You are exactly right when you say:
The rest of the job is everyone's problem.
Getting DNSSEC to be more than an academic exercise requires BOTH folks signing zones that form an unbroken chain of trust up to a trust anchor configured in validating name servers AND for the operators of those validating name servers to enable DNSSEC. Most of the thrust to date has been on one half of that requirement. How many ISPs represented here are in a position to turn on DNSSEC validation? How many are even running caches that are capable of doing DNSSEC? For DNSSEC to actually be useful, I suspect somebody needs to write software that provides the user with some indication other than a timeout that a name validation failed, but that's a separate issue. Regards, -drc
In a message written on Wed, Jul 09, 2008 at 12:30:08PM -0700, David Conrad wrote:
for root signing. The fact that root zone data you receive from the root servers is not signed may suggest that there is a bit more that needs to be done and pretty much all of that is NOT something ICANN has direct control over.
So David, who has control, and what do they need to do? Every time I've asked someone in the chain about what it takes to sign the root, their part is done, it's others who aren't doing their bits. Perhaps I'm too much of an engineer. Today there is a process for IANA (ICANN?) to say "update the IP for a.root-servers.net from x to y" and it makes it to someone who can run vi on the master file, and they insert a new entry, and boom the root has it. It seems to me if IANA (ICANN?) generates sigs, hands those same records to the same person with vi access to the file and they add them then boom, the root would have it. Signature records are no different than any other type of record in the root, and other records have been updated in the past. Since you already have the sigs on the web page why can't they be sent to the guy with vi access the same as any other record change? Please, let us know so people can go fix it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Love to. We can also put your trust anchors in the prototype ITAR (see the first part of https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf) . Regards, -drc On Jul 9, 2008, at 2:52 PM, Randy Bush wrote:
There are 4 ccTLDs (se, bg, pr, br) that are signed.
wanna crawl in a corner in dublin and i can sign a few?
randy
David Conrad wrote:
There are 4 ccTLDs (se, bg, pr, br) that are signed. wanna crawl in a corner in dublin and i can sign a few? Love to. We can also put your trust anchors in the prototype ITAR (see the first part of https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf).
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone? randy
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has... Regards, -drc
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone? If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
sounds like a plan. i volunteer to be victim. randy
David Conrad wrote:
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
Regards, -drc
Early please. I've got a tight schedule.
On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <drc@virtualized.org> wrote:
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well? -Chris
On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <drc@virtualized.org> wrote:
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well?
I'd rather see the IANA do it. I wouldn't say that they are 100% neutral, but they're more neutral than SPARTA. -M<
On Wed, Jul 9, 2008 at 11:27 PM, Martin Hannigan <hannigan@gmail.com> wrote:
On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well?
I'd rather see the IANA do it. I wouldn't say that they are 100% neutral, but they're more neutral than SPARTA.
I've got no particular want of sparta doing it, just mentioning that they had done at least one in the past... maybe DRC can roll out a preso/examples/docs for LAX/<next-location> :) I don't care as long as it'll help people start doing work on their part of the pie and it's applicable to the conference. -Chris
On Jul 9, 2008, at 8:27 PM, Martin Hannigan wrote:
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has... I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well? I'd rather see the IANA do it. I wouldn't say that they are 100% neutral, but they're more neutral than SPARTA.
Not taking the bait on neutrality (:-)), but I don't see this as either/or... Regards, -drc
-----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: Thursday, July 10, 2008 1:26 PM To: Martin Hannigan Cc: nanog@merit.edu Subject: Re: Multiple DNS implementations vulnerable to cache poisoning
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has... I think Sandy Murphy or other Sparta folks have presented some of
On Jul 9, 2008, at 8:27 PM, Martin Hannigan wrote: the
work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well? I'd rather see the IANA do it. I wouldn't say that they are 100% neutral, but they're more neutral than SPARTA.
Not taking the bait on neutrality (:-)), but I don't see this as either/or...
Regards, -drc
Not bait, but agreed. I was trying to indicate that I thought it would be interesting for the IANA to present something since it is an effort under the ICANN umbrella, regardless of it being bottom up or top down. Bad choice of words. Mea culpa. Best, Marty -- Martin Hannigan http://www.verneglobal.com/ Verne Global Datacenters e: hannigan@verneglobal.com Keflavik, Iceland p: +16178216079
Already gotten a hint that something along these lines would be desirable for LAX. I can propose something to the PC -- which would be more useful for folks, a more general DNSSEC signing workshop or a focused presentation on IANA's stuff? Regards, -drc On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote:
On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <drc@virtualized.org> wrote:
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well?
-Chris
Another test, that apparently was publicized on some dnsops list: dig +short porttest.dns-oarc.net TXT Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
On 07/10/08 11:03, Jay R. Ashworth wrote:
Another test, that apparently was publicized on some dnsops list:
dig +short porttest.dns-oarc.net TXT
The "some dnsops list" is the OARC public dns-operations list, and this posting explains the tool and briefly describes the results: http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html There's a healthy discussion of this vuln and DNSSEC going on over there, and that list is an appropriate forum for further discussion of this topic. michael
https://www.dns-oarc.net -----Original Message----- From: Michael Sinatra [mailto:michael@rancid.berkeley.edu] Sent: Thursday, July 10, 2008 1:13 PM To: Jay R. Ashworth Cc: nanog@nanog.org Subject: Re: Multiple DNS implementations vulnerable to cache poisoning On 07/10/08 11:03, Jay R. Ashworth wrote:
Another test, that apparently was publicized on some dnsops list:
dig +short porttest.dns-oarc.net TXT
The "some dnsops list" is the OARC public dns-operations list, and this posting explains the tool and briefly describes the results: http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html There's a healthy discussion of this vuln and DNSSEC going on over there, and that list is an appropriate forum for further discussion of this topic. michael
At 10:24 AM -0700 7/10/08, David Conrad wrote:
Already gotten a hint that something along these lines would be desirable for LAX. I can propose something to the PC -- which would be more useful for folks, a more general DNSSEC signing workshop or a focused presentation on IANA's stuff?
Regards, -drc
Folks might find the DNSSEC session at the recent ICANN meeting interesting since it focused on DNSSEC in the field and DNSSEC tools. Descriptions of the presentations as well as the slides are available at: http://par.icann.org/en/node/77 I imagine that folks might want something different at LAX but I's be happy to work with drc to put together a DNSSEC session of some sort if there was interest. Russ
On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote:
On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <drc@virtualized.org> wrote:
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well?
-Chris
I would love to get input on that be it in Dublin or elsewhere, both sides: the authoritative server and the recursive validator. We have ideas and want to do this but I will not claim to be the owner of THE TRUTH, so input is much desired. Joao PS: I would also want a copy of, or a secure method to access, the public part of the keys you use to sign those ccTLDs so I can place them in ISC's DLV registry On 10 Jul 2008, at 01:17, Randy Bush wrote:
David Conrad wrote:
There are 4 ccTLDs (se, bg, pr, br) that are signed. wanna crawl in a corner in dublin and i can sign a few? Love to. We can also put your trust anchors in the prototype ITAR (see the first part of https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf).
aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone?
randy
On Wed, Jul 09, 2008 at 12:05:38PM -0400, Christopher Morrow wrote:
get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, that's not nanog... doh!
Pressure your local ICANN officers?
One of the commenters on Slashdot, who did not sound entirely like a crank, says the root zone DNSKEYs and RRSIGs have been generated already, and his informant is waiting for the OK to deploy them. http://it.slashdot.org/comments.pl?sid=607413&cid=24106363 Cheers, -- jr 'yes, yes, I know; it's /. No, I don't believe in the Easter Bunny' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:
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.
We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html While this does not make the attack impossible, it does make it much harder. The same thing applies to those RST attacks circa 2004. Most of these blind attacks assume the source port numbers are easy to guess. But... why should they? Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote:
At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:
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.
We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html
While this does not make the attack impossible, it does make it much harder.
The same thing applies to those RST attacks circa 2004.
Most of these blind attacks assume the source port numbers are easy to guess. But... why should they?
Because many name servers use one port, or easily guessable sequence of ports? -- TTFN, patrick
Anyone using Infoblox DNSOne? They claimed to have fixed their BIND version but I still see issues with source ports staying the same. Eric Davis Sr. Network Technician Rockefeller University IT Dept. 212-327-7508 646-772-4667(cell) -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Wednesday, July 09, 2008 4:15 PM To: nanog@merit.edu Subject: Re: Multiple DNS implementations vulnerable to cache poisoning On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote:
At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:
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.htm l
) -- 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.
We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html
While this does not make the attack impossible, it does make it much harder.
The same thing applies to those RST attacks circa 2004.
Most of these blind attacks assume the source port numbers are easy to guess. But... why should they?
Because many name servers use one port, or easily guessable sequence of ports? -- TTFN, patrick
participants (33)
-
Andrews Carl 455
-
Brian Keefer
-
Buhrmaster, Gary
-
Chris Adams
-
Christian Koch
-
Christopher Morrow
-
David Conrad
-
Eric Brunner-Williams
-
Eric Davis
-
Fernando Gont
-
Jay R. Ashworth
-
Jean-François Mezei
-
Jeffrey Ollie
-
Jimmy Hess
-
Joao Damas
-
Joe Abley
-
Joe Greco
-
Leo Bicknell
-
Lynda
-
Martin Hannigan
-
Martin Hannigan
-
Michael C. Toren
-
Michael Sinatra
-
michael.dillon@bt.com
-
Owen DeLong
-
Patrick W. Gilmore
-
Phil Regnauld
-
Randy Bush
-
Russ Mundy
-
Sean Donelan
-
Simon Waters
-
Steven M. Bellovin
-
Tuc at T-B-O-H.NET