Re: [dns-operations] ALERT: .QA CCTLD in wrong hands currently
The TLD appears to be fine (that is, it hasn't been redelegated). Looks = like the registry might be having issues however -- the domain = referenced on the IANA page for registration information (domains.qa) = does not resolve (NXDOMAIN). But it does by number: http://184.106.140.247/en jaap ___ 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
[dns-operations] summary of recent vulnerabilities in DNS security.
Hi All, We (me and my phd advisor Prof Amir Herzberg) recently found a number of new DNS vulnerabilities, which apply to patched and standard DNS resolvers, and enable off-path attackers to foil [RFC5452] (and [RFC6056, RFC4697]) recommendations, allowing DNS cache poisoning attacks. The vulnerabilities are not related to a specific DNS software or OS implementation. Following some questions regarding which publication is related to what vulnerability, for your convenience, please find a summary of our findings and results below (concise conferences' publications are available on my site sites.google.com/site/hayashulman/publications - I will soon upload full versions). Please feel free to email me if you have questions related to these works. We are also interested in understanding the constraints and challenges that Internet operators and administrators are facing and therefore will appreciate your comments/feedback. --- Summary: we performed a study of DNS security (focusing on cache poisoning attacks) in the following settings: 1. Resolver-behind-Upstream (applies to resolvers that use upstream forwarders for their security against attacks). 2. Socket-overloading for port derandomisation (applies to network settings where attacker has a `good` and `stable` Internet connection and exploits side-channels in kernel handling of hardware interrupts on the resolver side). 3. Resolver-behind-NAT (applies to patched resolvers behind patched NAT devices). 4. Second-fragment IP defragmentation cache poisoning (this attack was discussed on this mailing list, and the idea is to replace the second authentic fragment with a spoofed one). --- [1, 2, 3] - present techniques to derandomise ports on systems that support algorithms recommended in [RFC6056]. We also tested a number of popular DNS checker systems, and their ability to detect the vulnerabilities. [2, 3] - show how to perform IP address derandomisation against resolvers conforming with recommendations in [RFC4697] (we then present applications of this technique for NS pinning). [4] - shows how to apply IP defragmentation cache poisoning to inject content into DNS responses for DNS cache poisoning. --- Details: --- 1. Resolver-behind-Upstream --- Resolver-behind-Upstream forwarder, is recommended by security experts and ISPs as a secure configuration to prevent DoS attacks against proxy resolvers (which typically have limited bandwidth), and to prevent Kaminsky DNS cache poisoning. The intuition is that DNS requests are never sent directly to the name servers, and thus the proxy resolver (that is configured to use a secure upstream resolver for its requests) is secure. We present different techniques allowing off-path attackers to find the IP address of proxy resolver (that uses an upstream forwarder for its DNS requests) and then to discover ports, allocated by the proxy to its DNS requests. These attacks are very efficient in particular when fragmentation (even of a single byte) is possible (i.e., if the proxy and upstream do not use TCP for communication). In contrast to 4, here we apply first fragment IP defragmentation cache poisoning, to discover the port assigned by the proxy to its requests to upstream forwarder. Surprisingly, we found that many proxies rely on their security for an upstream forwarder and simply send all requests from fixed, or sequentially incrementing, ports. Recommendations: 1. randomise ports selected by the proxy resolver. 2. use TCP between proxy and upstream forwarder. Published at ESORICS'13: http://link.springer.com/chapter/10.1007/978-3-642-40203-6_13#page-1 --- 2. Socket-overloading for port derandomisation --- In this work we present techniques to elicit side-channels enabling off-path attackers to discover the ports assigned by resolvers that support per-destination port allocation algorithms recommended in [RFC6056]. We also show how to apply socket overloading for NS pinning against resolvers compliant with [RFC4697]. The effectiveness and efficiency of socket-overloading based techniques depends on the quality of network connectivity of the attacker and proximity to the victim resolver, i.e., number of hops between the victim and the attacker. In particular, since this attack requires bursts of traffic, if the attacker does not have good connectivity, its attack may be detected by some IDS. On the other hand, the attacker can significantly increase its success probability (as well as reduce the volume of the burst) by distributing the burst among a number of nodes that it controls. To appear at ACSAC'13 (paper Socket Overloading for Fun and Cache-Poisoning on my site). Tested against Linux kernel 3.2 (with support for NAPI mechanism), and Windows server 2008. Recommendations: randomise ports. --- 3. Resolved-behind-NAT --- We showed techniques that use a user-space software (controlled by the attacker) that can send DNS requests to the victim resolver, and enable an off-path attacker to derandomise
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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] summary of recent vulnerabilities in DNS security.
P Vixie (paul) writes: M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie I was wondering about that, and went to look at the abstracts: http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 Security of Patched DNS [...] We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of DNSSEC (or other MitM-secure defenses). So at least this seems to be mentioned in the papers themselves (Id didn't pay to find out). But I agree that the summary would benefit from stating this, as it's currently only way to to avoid poisoning. Not stating it could lead some to believe that these attacks are immune to DNSSEC protection of the cache. 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] summary of recent vulnerabilities in DNS security.
From: Haya Shulman haya.shul...@gmail.com We (me and my phd advisor Prof Amir Herzberg) recently found a number of new DNS vulnerabilities, which apply to patched and standard DNS resolvers, ... Recommendations: ... The complete absense of any mention of DNSSEC among those recommendations (or elsewhere) reads like an implicit claim that DNSSEC would not help. Even if that claim was not intended, would it be accurate? Would DNSSEC make any of recommendations less necessary or perhaps even moot? If DNSSEC by itself would be effective against cache poisoning, then isn't it among the recommendations, especially for Resolver-behind-Upstream? Why aren't efforts to protect port randomization, hide hidden servers and so forth like trying to make it safe to use .rhosts and /etc/hosts.equiv files by filtering ICMP dedirects and IP source routing, and strengthening TCP initial sequence numbers? It's not that filtering ICMP redirects, etc. are wrong, but I think today those things are used for availability instead of data integrity (or authentication and authorization), and small leaks are not always and everywhere seen as catastrophes. In fact, haven't ICMP redirects been reborn as fundamental parts of IPv6? Vernon Schryverv...@rhyolite.com ___ 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] summary of recent vulnerabilities in DNS security.
You are absolutely right, thanks for pointing this out. DNSSEC is the best solution to these (and other) vulnerabilities and efforts should be focused on its (correct) adoption (see challenges here: http://eprint.iacr.org/2013/254). However, since partial DNSSEC deployment may introduce new vulnerabilities, e.g., fragmentation-based attacks, the recommendations, that I wrote in an earlier email, can be adopted in the short term to prevent attacks till DNSSEC is fully deployed. On Sat, Oct 19, 2013 at 5:53 PM, P Vixie p...@redbarn.org wrote: M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de ___ 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] summary of recent vulnerabilities in DNS security.
This is correct, the conclusion from our results (and mentioned in all our papers on DNS security) is to deploy DNSSEC (fully and correctly). We are proponents of cryptographic defenses, and I think that DNSSEC is the most suitable (proposed and standardised) mechanism to protect DNS against cache poisoning. Deployment of new Internet mechanisms is always challenging (and the same applies to DNSSEC). Therefore, we recommend short term countermeasures (against vulnerabilities that we found) and also investigate mechanisms to facilitate deployment of DNSSEC. On Sat, Oct 19, 2013 at 6:05 PM, Phil Regnauld regna...@nsrc.org wrote: P Vixie (paul) writes: M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie I was wondering about that, and went to look at the abstracts: http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 Security of Patched DNS [...] We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of DNSSEC (or other MitM-secure defenses). So at least this seems to be mentioned in the papers themselves (Id didn't pay to find out). But I agree that the summary would benefit from stating this, as it's currently only way to to avoid poisoning. Not stating it could lead some to believe that these attacks are immune to DNSSEC protection of the cache. Cheers, Phil -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de ___ 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] summary of recent vulnerabilities in DNS security.
From: Haya Shulman haya.shul...@gmail.com IMHO, DNSSEC is simply the natural defense against the attacks, which is why I did not explicitly mention it, but I definitely had it in mind :-) In that case, on what should an organization spend time or money first, on DNSSEC or the recommendations in the mail message? Would it be better if each of the recommendations in the mail message started with something like this? Deploy DNSSEC, and consider the follow to help protect cached data not yet protected with DNSSEC. Regarding the proxy-behind-upstream: to prevent the attacks DNSSEC has to be deployed(and validated) on the proxy. Currently it seems that there are proxies that signal support of DNSSEC (via the DO bit), but do not validate responses, and validation is typically performed by the upstream forwarder. That sounds like a more significant bug than port obscurity or randomization. If it is a bug, which should be addressed first in that software or those installations, this DNSSEC bug or the recommendations in the mail message? It it is a significant DNSSEC bug, it would be good if a future version of the mail message mentioned it. Vernon Schryverv...@rhyolite.com ___ 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] ALERT: .QA CCTLD in wrong hands currently
* Kauto Huopio: And facebook.qa and tons of .qa govt domains etc. Note also this: google.com.qa. 14400 IN MX 0 google.com.qa. That would actually be valid (but redudant). It causes mail for google.com.qa to be delivered to the host at google.com.qa, based on the A/ records of the domain. ___ 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
