Re: [dns-operations] ATT DNS Cache Poisoning?
Thank you for your answer, Roy. Here follows my comments. On 29/10/2012 12:54, Roy Arends wrote: I did not say that. I asked DNSSEC does not defend against the Kaminsky hack?. I thought it was some sort of rhetoric question. My apologies. AFAIK, DNSSEC does not possess any revocation mechanism (an expiration mechanism does exist but I am really talking about _revocation_). Sure, CRL's are mostly only valid for 24 hours. So the revocation granularity for certificates is not real time and might have at least a 86399 second delay. If you'd want to beat that with DNSSEC, re-sign at least twice a day :-). I'm trying to argue that times can be 'gamed' to match CRL requirements. OCSP is a real time certificate checking method. Only realtime signing (Phreebird, etc) of TLSA records can match that, I think. Some say what's the matter anyway? Neither CRLs nor OCSP are checked in the real world.. I often answer that X509 have the merit to possess an already-designed revocation mechanism, which DANE cannot claim to have yet. But maybe this should be discussed off-list or on DANE WG mailing-list. Sorry. I have to admit this attack scenario is far-reached, as most DNSSEC-validatating servers do implement SPR and some even implement 0x20, but there is still the problem of middle boxes un-randomizing source ports. To me, DNSSEC protects the dns cache against Kaminsky's hack. It is not cache poisoning if you inject a cache with valid data. Naming convention problem then. My bad. Can you tell me how do you name a record no longer served by authoritative servers (removal is assumed to be a deliberate move) but whose signature are still valid? These pseudo-valid records can still be injected via a Kaminsky hack or MITM attack, which can be occasionally of concern. Best regards, Florian Maury ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On 29/10/2012 13:33, Paul Wouters wrote: The kaminsky attack has nothing to do with revocation. DNSSEC solves the kaminsky attack which relies on unsigned spoofable data. I may be the only one worried about replayed signed data, after it is removed from authoritative servers. Let's take an extreme example to illustrate: Alice rents Bob a server called AMX and uses this server as a MX for her domain. The MX record is configured with a TTL of 1 day and the record set is signed for 3 months. A month later, Alice's activity has grown exponentially, and the server has become undersized for her mailing activity, so she rents Bob a larger server, BMX. She configures BMX to be her new MX and give back to Bob the AMX server. The new MX record set no longer contains the AMX server. Mallory wants to read Alice's emails. He manages to rent Bob AMX. He, then, replays the old MX record set whose signature are not expired (the signature is still valid for 2 months) to Charlie, whose resolver is vulnerable to the Kaminsky hack. When Charlie will want to send an email to Alice, he will find in its cache the replayed record set (because the signature is valid, the DNSSEC-validator has no reason to reject it) and will send his email to Mallory. If Alice could have revoked her signature on the previous MX RRSet, her emails sent by Charlie would not have been redirected to Mallory's server. One can tell She should not have signed for a period that long. It's the eternal problem of zone survivability: the shorter the signature, the shorter the interval a slave server can serve data before it expires without signing the zone himself (which can be a problem if the slave server is administrated by a third party). This lack of revocation mechanism can be a problem for some usage of DNSSEC, as in DANE where usage type 2 or 3 induce a new risk: a cache could be poisoned via a Kaminsky attack with a TLSA record whose *BUZZER* TLSA records that are not protected with DNSSEC, MUST NOT be used. If implementations do this anyway, they are broken. Absolutely. I was talking about valid DNSSEC-signed TLSA record sets replayed after their removal from the zone but before their signature expires. I would be happy to be proven wrong. I'm only a not-so-young padawan, after all ;) Patience, my grass hopper. Thank you, Florian Maury ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
Florian Maury (pub-dnsop) writes: Let's take an extreme example to illustrate: [...] Mallory wants to read Alice's emails. He manages to rent Bob AMX. He, then, replays the old MX record set whose signature are not expired (the signature is still valid for 2 months) to Charlie, whose resolver is vulnerable to the Kaminsky hack. I use precisely this example in our workshops to illustrate why TTLs are included in the signatures, and why these are limited in duration. (Slight variation: old IP is rented by attacker to host a website that then does an SSL stripping attack, and Bob's your uncle[*]) You still control the validity of the data in the cache, though you don't control the cache behaviour. If Alice could have revoked her signature on the previous MX RRSet, her emails sent by Charlie would not have been redirected to Mallory's server. Revoking = have short signature lifetime, publish new ones regularly that will be preferred by validators. One can tell She should not have signed for a period that long. It's the eternal problem of zone survivability: the shorter the signature, the shorter the interval a slave server can serve data before it expires without signing the zone himself (which can be a problem if the slave server is administrated by a third party). It's an operational challenge, not a design one, and it remains: polluting caches with still-valid data is not cache poisoning (that data could have ended up in the cache in any number of ways; ceasing to publish signed data does not preclude it still being available somewhere). [*] No relation to to Alice's Bob. Cheers, Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On Sun, 28 Oct 2012, bert hubert wrote: It appears that source port randomization works. Probably the only vulnerable servers are those behind NAT that derandomizes the source port. But important servers are unlikely to suffer from network address translation. Which is everyone with a validating resolver on their laptop/phone. You missed the announcement of the 450 million downloads by iOS6 of the IANA root key? Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
Bert, On Oct 27, 2012, at 10:55 PM, bert hubert bert.hub...@netherlabs.nl wrote: Thus continuing the trend that all purported cache poisonings observed have been registry hacks. Looks that way, although it looks like this wasn't really a registry hack but rather what happens when a domain name expires these days. With that said, I still believe the most critical vulnerability in the DNS is in the security of the registrars. It appears that source port randomization works. Was there ever any doubt? The question wasn't (isn't?) whether source port randomization would work, it was how long it would work. Source port randomization simply protects the communication channel, not the data -- it kicks the can down the road (yet again). DNSSEC protects the data making the communication channel irrelevant. IMHO, it is a better long-term solution (folks who know my opinion on DNSSEC may now require smelling salts). Probably the only vulnerable servers are those behind NAT that derandomizes the source port. But important servers are unlikely to suffer from network address translation. Heh. Let me introduce you to CGN... :-) Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On Sun, Oct 28, 2012 at 02:22:04AM -0400, Paul Wouters wrote: On Sun, 28 Oct 2012, bert hubert wrote: It appears that source port randomization works. Probably the only vulnerable servers are those behind NAT that derandomizes the source port. But important servers are unlikely to suffer from network address translation. Which is everyone with a validating resolver on their laptop/phone. You missed the announcement of the 450 million downloads by iOS6 of the IANA root key? Paul, does that even *relate* to what I said? Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On Sat, Oct 27, 2012 at 11:43:40PM -0700, David Conrad wrote: It appears that source port randomization works. Was there ever any doubt? The question wasn't (isn't?) whether source Yes, people used the Kaminsky hack as a way to push DNSSEC. So perhaps doubt was *instilled*. making the communication channel irrelevant. IMHO, it is a better long-term solution (folks who know my opinion on DNSSEC may now require smelling salts). As an implementor, after two years, we keep finding DNSSEC corner cases that make the authors of the very RFCs swoon. The effort of implementing everything correctly is just staggering, our number of regression tests is exploding just to try to keep everything in check. It might have been easier all round to just start from scratch and not pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs exceeds the length of the standardizing RFCs of DNS. By the way, I know some people will immediately chime in DNSSEC isn't that hard, but you won't hear an implementor among them... Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On Sun, Oct 28, 2012 at 02:22:04AM -0400, Paul Wouters p...@cypherpunks.ca wrote a message of 20 lines which said: You missed the announcement of the 450 million downloads by iOS6 of the IANA root key? Poisoning the cache of an one-user iPhone is fun but less useful than poisoning the caches of ATT, Verizon or Comcast... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On 2012-10-28 5:55 AM, bert hubert wrote: ... the trend that all purported cache poisonings observed have been registry hacks. It appears that source port randomization works. it doesn't, though. Probably the only vulnerable servers are those behind NAT that derandomizes the source port. But important servers are unlikely to suffer from network address translation. DNS SPR is not universally deployed even among recursive name servers for large populations. and the de-randomization techniques described by shulman and herzberg (http://arxiv.org/pdf/1209.1482.pdf) work in what should be an alarming number of cases. but nobody is alarmed because attempted use of this vulnerability is at most not widespread and possibly also rare. DNS SPR does not work in the sense that its non-universal deployment leaves significant attack surface uncovered. the reason we're not seeing wide spread poisoning isn't that DNS SPR is preventing it. the reason is, wide spread poisoning is not being attempted. On 2012-10-28 7:40 AM, bert hubert wrote: ... people used the Kaminsky hack as a way to push DNSSEC. yes, we did. DNSSEC is a spend-money-to-save-money proposition, which is never compelling. those of us who knew that DNSSEC was needed and who had been working on it for over a decade by the time kaminsky came along were very happy to hear from kaminsky, and we rode the fear curve all the way to partial deployment, including seeing the root zone signed, seeing lots of TLD's signed, seeing DNSSEC as a requirement for all the new gTLD's, and seeing implementors who had previously eschewed DNSSEC decide to implement it after all. (for example, powerdnssec.) in that sense we were a bunch of fear-mongering opportunistic bastards. in our defense let me say that DNSSEC isn't an earn-money proposition for me or for most of the rest of the opportunistic bastards who climbed on the kaminsky band-wagon and trumpeted it as the reason why DNSSEC should be taken seriously. rather, we were concerned internet citizens who saw a long term problem that we knew others would not take seriously until the world's losses were significant. and, as DRC pointed out up-thread, DNS SPR is path protection and the path is already known to be corrupt (nxdomain redirection, dns filtering). the things DNSSEC prevents against are broader and more fundamental than kaminsky. so the geeks did some fear-based marketing to get a win. it's a win i'll take any way i can get it. we need DNSSEC. ... It might have been easier all round to just start from scratch and not pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs exceeds the length of the standardizing RFCs of DNS. we naively believed that we could get DNSSEC into production before Y2K if we tried hard to work within the existing system. the idea of the root not being signed until 2010 was unthinkable. had we known that we had that much time we would have cut much deeper. sixteen years into the effort, DNSSEC is still not ready to become ubiquitous. less naively, i now know that had we cut deeper, as in use a new port number, call it DNS V2, let initiators treat UDP/53 as a fallback path, then sixteen years would have been much too short. many people would have come out of the woodwork to help us. we would have unicode encoding of all names, XML encoding of all transactions, TLS security for all parts of the path, X.509 dependencies, no possibility of DANE, and most transactions would now use TCP. the result would never work outside anyone's lab, but would have been standardized anyway, several times over a twenty year span, by the end of which the world would have moved on to less open standards that could deliver usable functionality in fractional-year time frames. so it's probably for the best that we didn't know it would take sixteen years when we first started this. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
* Tim Huffman: Any ideas what I can do to help my customer? This is the first time we've ever had something like this... Have you checked if other domains you host are affected in a similar way? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
David Conrad wrote: Yep, assuming it is cache poisoning. I'm trying to think of alternative explanations, but given reports (e.g., from Frank) that the issue is affecting other resolvers, it's hard to see other answers. A bit odd, given ben.edu isn't very high up on the Alexa (et al) list... i don't think it's cache poisoning. note that there are two out-of-zone nameservers for ben.edu: Domain Name: BEN.EDU [...] Name Servers: NS1.BOBBROADBAND.COM NS2.BOBBROADBAND.COM and that bobbroadband.com was updated recently, in the past two days: Domain Name: BOBBROADBAND.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: NS1.BOBBROADBAND.COM Name Server: NS2.BOBBROADBAND.COM Status: clientTransferProhibited Updated Date: 25-oct-2012 Creation Date: 22-oct-2005 Expiration Date: 22-oct-2017 here's what was seen in DNSDB on the same day that bobbroadband.com was updated in whois: ;; bailiwick: com. ;; count: 114 ;; first seen: 2012-10-25 11:53:51 - ;; last seen: 2012-10-25 12:58:03 - bobbroadband.com. IN NS ns1.pendingrenewaldeletion.com. bobbroadband.com. IN NS ns2.pendingrenewaldeletion.com. ;; bailiwick: bobbroadband.com. ;; count: 2 ;; first seen: 2012-10-25 15:08:04 - ;; last seen: 2012-10-25 15:49:29 - bobbroadband.com. IN NS ns1432.ztomy.com. bobbroadband.com. IN NS ns2432.ztomy.com. taking over the nameservers for bobbroadband.com would thus allow taking over ben.edu: ;; bailiwick: ben.edu. ;; count: 2 ;; first seen: 2012-10-25 15:09:49 - ;; last seen: 2012-10-25 15:58:11 - ben.edu. IN NS ns1432.ztomy.com. ben.edu. IN NS ns2432.ztomy.com. i see the exact same pattern with cooperhealth.edu, and its nameservers, back in april: Domain Name: COOPERHEALTH.EDU [...] Name Servers: DNS01.CAVTEL.NET DNS02.CAVTEL.NET Domain Name: CAVTEL.NET Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: DNS01.CAVTEL.NET Name Server: DNS02.CAVTEL.NET Status: clientTransferProhibited Updated Date: 10-apr-2012 Creation Date: 08-apr-1999 Expiration Date: 08-apr-2013 ;; bailiwick: net. ;; count: 168 ;; first seen: 2012-04-10 08:30:35 - ;; last seen: 2012-04-10 12:34:40 - cavtel.net. IN NS ns1.pendingrenewaldeletion.com. cavtel.net. IN NS ns2.pendingrenewaldeletion.com. ;; bailiwick: cavtel.net. ;; count: 6 ;; first seen: 2012-04-10 14:23:47 - ;; last seen: 2012-04-12 08:16:30 - cavtel.net. IN NS ns1432.ztomy.com. cavtel.net. IN NS ns2432.ztomy.com. ;; bailiwick: cooperhealth.edu. ;; count: 2 ;; first seen: 2012-04-11 06:52:37 - ;; last seen: 2012-04-11 20:07:14 - cooperhealth.edu. IN NS ns1432.ztomy.com. cooperhealth.edu. IN NS ns2432.ztomy.com. -- Robert Edmonds edmo...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
Robert, On Oct 27, 2012, at 1:37 PM, Robert Edmonds edmo...@isc.org wrote: i don't think it's cache poisoning. note that there are two out-of-zone nameservers for ben.edu: ... and that bobbroadband.com was updated recently, Good catch! Makes sense. I checked the history on ben.edu but didn't think to check the rest of the delegation tree. D'oh. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
Any ideas what I can do to help my customer? This is the first time we've ever had something like this... Tim Huffman Director of Engineering Business Only Broadband 777 Oakmont Lane, Suite 2000, Westmont, IL 60559 Direct: 630.590.6012 | Main: 630.590.6000 | Fax: 630.986.2496 thuff...@bobbroadband.com | http://www.bobbroadband.com/ Cell: 630.340.1925 | Toll-Free Customer Support: 877.262.4553 Follow Us on LinkedIn | Follow Us on Twitter please consider the environment prior to printing -Original Message- From: Phil Pennock [mailto:dnsop+p...@spodhuis.org] Sent: Friday, October 26, 2012 11:14 PM To: Tim Huffman Cc: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] ATT DNS Cache Poisoning? On 2012-10-27 at 03:36 +, Tim Huffman wrote: We are the primary DNS servers for the ben.edu domain. We seem to be having an issue with an ATT server that is responding with incorrect A records for www.ben.edu and ben.edu. Definitely looks like a cache-poisoning attack. Further, compare and contrast: curl -vH Host: www.ben.edu http://208.91.197.132/ ua=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648) curl -vH Host: www.ben.edu -H User-Agent: $ua http://208.91.197.132/ There's some JavaScript fetching images via fwdservice.com ... looks like it might be Google click-fraud? -Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On 2012-10-27 at 04:23 +, Tim Huffman wrote: Any ideas what I can do to help my customer? This is the first time we've ever had something like this... Continue trying to reach ATT and the other operators of DNS servers in that link? You can look at deploying DNSSEC for their domain, so that those DNS resolver operators who deploy validating caches will be immune to this. The .edu zone is signed. If you get ben.edu signed as well, then you've done everything technical to help resolvers only get valid data. -Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
