[dns-operations] summary of recent vulnerabilities in DNS security.
haya.shulman at gmail.com
Sat Oct 19 13:54:22 UTC 2013
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
3. Resolver-behind-NAT (applies to patched resolvers behind patched NAT
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).
 - shows how to apply IP defragmentation cache poisoning to inject
content into DNS responses for DNS cache poisoning.
--- 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
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.
1. randomise ports selected by the proxy resolver.
2. use TCP between proxy and upstream forwarder.
Published at ESORICS'13:
--- 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:
--- 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.
Technische Universität Darmstadt****
FB Informatik/EC SPRIDE****
Tel. +49 6151 16-75540****
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations