<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hi All,</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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 <a href="https://sites.google.com/site/hayashulman/publications" style="font-family:arial">sites.google.com/site/hayashulman/publications</a> - I will soon upload full versions). Please feel free to email me if you have questions related to these works.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">We are also interested in understanding the constraints and challenges that Internet operators and administrators are facing and therefore will appreciate your comments/feedback.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">---</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Summary: we performed a study of DNS security (focusing on cache poisoning attacks) in the following settings:</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">1. Resolver-behind-Upstream (applies to resolvers that use upstream forwarders for their security against attacks).</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
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).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
3. Resolver-behind-NAT (applies to patched resolvers behind patched NAT devices).</div><div class="gmail_default" style="font-family:tahoma,sans-serif">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).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">---</div><div class="gmail_default" style="font-family:tahoma,sans-serif">[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.<br>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif">[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).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">[4] - shows how to apply IP defragmentation cache poisoning to inject content into DNS responses for DNS cache poisoning. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">---</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Details:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">--- 1. Resolver-behind-Upstream ---</div><div class="gmail_default" style="font-family:tahoma,sans-serif">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. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Recommendations: </div><div class="gmail_default" style="font-family:tahoma,sans-serif">
1. randomise ports selected by the proxy resolver.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">2. use TCP between proxy and upstream forwarder.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Published at ESORICS'13: <a href="http://link.springer.com/chapter/10.1007/978-3-642-40203-6_13#page-1" style="font-family:arial" target="_blank">http://link.springer.com/chapter/10.1007/978-3-642-40203-6_13#page-1</a> </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">--- 2. Socket-overloading for port derandomisation ---</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
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].</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">To appear at ACSAC'13 (paper "Socket Overloading for Fun and Cache-Poisoning" on my site).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Tested against Linux kernel 3.2 (with support for NAPI mechanism), and Windows server 2008.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Recommendations: randomise ports.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">--- 3. Resolved-behind-NAT ---<br>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].</div>
<div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">We use it to open a (user-space) UDP socket to the victim name server. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">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. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The attacks apply to resolvers residing behind secure and patched NAT devices, and were tested against common and standard systems (see paper).<br>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Tested against popular NAT devices, including linux kernel, CISCO (IOS and ASA), and others (details in paper).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Recommendations: randomise ports.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Published at ESORICS'12: <a href="http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16" style="font-family:arial" target="_blank">http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16</a></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">--- 4. Second Fragment IP defragmentation cache poisoning --</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">We are currently in a process of studying the fraction of networks vulnerable to our attack(s).</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">A number of recommendations (see paper on my site).</div><div class="gmail_default" style="font-family:tahoma,sans-serif">To appear at IEEE CNS'13. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">--</div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Best regards.</div><br><div dir="ltr"><div><p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Haya Shulman</font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Technische Universität Darmstadt<u></u><u></u></font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">FB Informatik/EC SPRIDE<u></u><u></u></font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Morewegstr. 30<u></u><u></u></font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">64293 Darmstadt<u></u><u></u></font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Tel. <a value="+4961511675540">+49 6151 16-75540</a><u></u><u></u></font></span></p>
<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><a href="http://www.ec-spride.de/" target="_blank"><font color="#000000">www.ec-spride.de</font></a></span></p>
</div></div>
</div>