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 ports recommended in [RFC6056]. We also showed techniques to perform NS pinning against resolvers that support recommendations in [RFC4697]. Notice, that the user-space software is not essential for our attacks, and in practice one can replace it with other techniques, e.g., Flash. We use it to open a (user-space) UDP socket to the victim name server. The attacker controlled software is assumed not to have root privileges, e.g., it cannot perform ARP spoofing. We use it to send three packets: (1) to trigger a DNS request, (2) to perform hole-punching in the NAT device, and (3) to send a packet to the attacker. The attacks apply to resolvers residing behind secure and patched NAT devices, and were tested against common and standard systems (see paper). Tested against popular NAT devices, including linux kernel, CISCO (IOS and ASA), and others (details in paper). Recommendations: randomise ports. Published at ESORICS'12: http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 --- 4. Second Fragment IP defragmentation cache poisoning -- We showed how to exploit IP defragmentation cache poisoning to inject spoofed DNS records into DNS responses, for DNS cache poisoning. We validated this attack against patched and up-to-date Bind and Unbound resolvers that we ran, using requests and responses to/from real name servers; recently, other groups performed validation of our attack in a similar lab setting. We are currently in a process of studying the fraction of networks vulnerable to our attack(s). A number of recommendations (see paper on my site). To appear at IEEE CNS'13. -- Best regards. 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 [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
