Security of Patched DNS: Amir Herzberg and Haya Shulman
Security of Patched DNS: Amir Herzberg and Haya Shulman
Security of Patched DNS: Amir Herzberg and Haya Shulman
We show how attackers can circumvent source port randomisation, in the (common) case where the resolver connects to the
Internet via different NAT devices.
We show how attackers can circumvent IP address randomisation, using some (standard-conforming) resolvers.
We show how attackers can circumvent query randomisation, including both randomisation by prepending a random nonce and
case randomisation (0x20 encoding).
We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of
DNSSEC (or other MitM-secure defenses).
Index TermsDNS security, DNS poisoning, Kamisky attack, Network Address Translator, NAT, DNS server selection, Internet security.
I NTRODUCTION
Furthermore, even a weaker - and more common off-path, spoofing attackers, may be able to send valid
DNS responses and cause DNS poisoning, when the
validated values are predictable or limited. For example,
some DNS implementations use predictable identifiers
(sequential, or produced by a weak pseudorandom generator); e.g., in [3], Klein shows how to predict the
identifier for the then-current version of Bind 9, a widelyused DNS server, and how this can be exploited for
highly-efficient DNS poisoning by off-path attackers.
Indeed, as pointed out by Vixie [4], already in 1995,
the identifier field alone is simply too short (16 bits) to
provide sufficient defense against a determined spoofing
attacker, who can foil it by sending (not too) many fake
responses.
To improve DNS security, the IETF published DNSSEC
[5], [6], [7], an extension to DNS, using cryptography (signatures and hashing) to ensure security (even)
against MitM attackers. However, in spite of the publication of DNSSEC more than a decade ago, in 1997 [8],
and the wide awareness to its existence, deployment is
still limited - e.g., less than 2% as reported in [9] for
April, 2012. There are also many caching DNS resolvers
that still do not support, or do not perform validation
of, DNSSEC [10]; see discussion of the deployment status
of DNSSEC in [11]. Furthermore, due to implementation
errors DNSSEC protection may fail, even when both the
resolver and zone deploy it: validation of signatures of
important top level domains, e.g., mil, fails since the root
does not delegate the public signature verification key
of mil but instead provides an (incorrect) indication that
mil does not support DNSSEC. This results in resolvers
falling back to a non-validating mode.
Indeed the deployment of DNSSEC is progressing slowly, due to challenges (see [11]), and possibly
due to the recent improvements (patches) to noncryptographic defenses, causing the if it aint broke,
dont fix it response. These patches are mainly by
deploying new sources of unpredictability in DNS requests and responses, such as use of random source
ports [12], [13], random DNS server selection [2] and
random capitalisation of the domain name [14].
This manuscript investigates such non-cryptographic
patches, that are deployed as countermeasures against
DNS cache poisoning. Our goal is twofold: (1) to help
improve these patches, since evidently they will remain
widely used for years; and (2) to further motivate adoption of more secure solutions such as DNSSEC, by pointing out weaknesses in the patches. While these specific
weaknesses can be fixed (and we show how - often,
easily), their existence should motivate the adoption of
better security measures such as DNSSEC, providing
defense against a MitM attacker and allowing for better
validation of security, e.g., see [15].
1.1
Attacker Model
In our attacks, we assume an off-path, spoofing adversary connected to the Internet and a host, compromised
by the adversary), on the local network; the attacker
model is depicted in Figure 1. Depending on the attack,
Fig. 1.
1.3
Contributions
Vendor
Port Allocation
Vulnerability [Section]
per-destination
sequential
preserving
(sequential if collide)
preserving
(random if collide)
preserving
(random if collide)
first random
then sequential
preserving
(random if collide)
preserving
(random if collide)
random
GREAT
Predict attack
[Section 2.2]
Predict attack
[Section 2.3]
Trap attack
[Section 2.1]
Trap attack
[Section 2.1]
Predict attack
[Section 2.2]
Trap attack
[Section 2.1]
Trap attack
[Section 2.1]
Trap attack
[Section 2.1]
Windows XP ICS
(Service Pack 3)
Windows XP WinGate
(Release 2.6.4)
CISCO IOS (release 15)
CISCO ASA (release 5500)
GREAT
GREAT
GREAT
GREAT
GREAT
GREAT
GREAT
TABLE 1
Summary of the source port derandomisation attacks presented in this work, against different types of NAT devices that were tested.
The attack in this section relies on the fact that the NAT
implements outbound refresh mapping for UDP connections, as specified in requirement 6 of RFC 4787 [32] (and
implemented in most NATs). Namely, the NAT maintains the mappings from an internal (source) SIP : Sport
pair to an external port NATport , for T seconds since a
packet was last sent from SIP :Sport (on the internal side
of the NAT) to the external network, using this mapping.
We further assume that the NAT device selects an external port at random for each outgoing packet, e.g., CISCO
ASA. The NAT device silently drops outgoing packets,
sent from SIP :Sport to DIP :Dport , when all external ports
for DIP :Dport are currently mapped to other sources; this
is the typical expected NAT behaviour, see [32].
The attack begins when the zombie contacts the attackers command-and-control center, identifies its location, and receives a signal to initiate the attack. We
next describe the steps of the attack; also illustrated with
simplifications in Figure 2.
1) The zombie, at address 10.6.6.6, sends UDP packets
to 1.2.3.4:53, i.e., to the DNS port (53) of the
name server of the victim domain, whose fully
qualified domain name (FQDN) is ns.V.com, from
each port p in the set of available ports Ports. To
Step
Zombie
10.6.6.6
Alice
10.0.0.1
Resolver
10.0.0.2
NAT
7.7.7.7
Eve
6.6.6.6
ignored
refresh
ignored
5
If fail: repeat
from step 1
ignored
7
8
Fig. 2.
DNS trap-then-poison attack with random ports allocation, for configuration in Figure 1.
Step
Zombie
10.6.6.6
Alice
10.0.0.1
Resolver
10.0.0.2
NAT
7.7.7.7
Eve
6.6.6.6
x$
ignored
3
d$
5
If fa il: re p e a t
fro m s te p 1
ignored
q$
q'$
7
8
Fig. 3.
Predict-then-poison DNS attack, for configuration in Figure 1, assuming per-destination port sequential NAT.
Experimental Evaluation
2.5
IP A DDRESSES ( DE )R ANDOMISATION
DNS resolvers can increase the entropy in DNS requests by randomising the IP addresses, i.e., selecting
the source/destination IP addresses in a DNS request
at random, and then validating the same addresses in
the DNS response. Selecting random source IP address
is rare, and the resolvers are typically allocated one (or
few) IP address as IPv4 addresses are a scarce resource.
Furthermore, resolvers behind NAT devices use the IP
of the NAT for their requests, and the address of the
resolver is generally known [2].
8. A pseudo-random permutation will provide as efficient data
structure and lookup, as when using sequential allocation.
9. This approach was supported only by the Checkpoint NAT which
allowed it to evade our trap attacks.
In contrast, most operators of DNS zones use a number of authoritative name servers for performance, robustness, and enhanced resilience to cache poisoning
attacks. We found that the majority of top level domains
(TLDs) use 5 to 7 authority name servers, and important
domains, e.g., com, use 13 authority servers10 ; see Figure 4.
When zone operators employ multiple authority
servers, the resolver should send the query to the one
with the shortest response time, and avoid querying nonresponsive name servers, see [36], [37], [38].
We present techniques that enable an off-path attacker
to predict the target name servers IP, for resolvers
which avoid querying unresponsive name servers, as per
the recommendations in [38], [37]; i.e., when the target
name server is not responsive, i.e., queries time-out, the
resolver does not send subsequent queries to it, but only
periodically, probes the target server until it becomes
responsive. The (standard-conforming) Unbound (1.4.18)
resolver sets this probing interval to 15 minutes. A
similar behaviour was observed by [38] in PowerDNS,
with the exception that PowerDNS sets the interval to
3 minutes. It appears that relying on the DNS server IP
address randomisation for additional entropy requires
careful study of particular resolver in question.
70
60
50
40
TLDs
30
20
10
0
14
13
12
11
10
Number of servers
Fig. 4.
Fig. 5.
10
Puppet
Puppet
1.2.3.6
1.2.3.6
Recursive
Recursive
DNS
DNSresolver
resolver
1.2.3.4
1.2.3.4
A?$123.404.GOV
Name
Name
Name
NameServer
Server
NameServer
Server
NameServer
Server
falcon.sec.GOV
falcon.sec.GOV puffin.sec.GOV
puffin.sec.GOV crow.sec.GOV
crow.sec.GOV
162.138.191.11
162.138.191.23
162.138.183.11
162.138.191.11 162.138.191.23 162.138.183.11
Spoofer
Spoofer
6.6.6.6
6.6.6.6
A?$123.404.GOV
1
Attack initiated
2
SrcIP: 162.138.191.11 dstIP:1.2.3.4
IP-ID: 777 Offset: 1480
Reassembled with
attacker's fragment
(sent in step 3).
Malformed DNS
response discarded by
resolver. Server marked as
non-responsive. Query resent
to next server.
Reassembled with
attacker's fragment
(sent in step 4).
Malformed DNS response
discarded by resolver. Server
marked as non-responsive .
Query resent to next server.
Response correct. During
next15 minutes queries are
sent to that server.
SrcIP:162.138.191.11 dstIP:1.2.3.4
IP-ID: 777 Offset:0
4
SrcIP:162.138.191.11 dstIP:1.2.3.4
IP-ID: 777 Offset:1480
A?$123.404.GOV
6
SrcIP:162.138.191.23 dstIP:1.2.3.4
IP-ID: 888 Offset:0
SrcIP:162.138.191.23 dstIP:1.2.3.4
IP-ID: 888 Offset:1480
A?$123.404.GOV
SrcIP:162.138.183.11 dstIP:1.2.3.4
IP-ID: 555 Offset:0
SrcIP:162.138.183.11 dstIP:1.2.3.4
IP-ID: 555 Offset:1480
Fig. 6.
The destination IP address prediction attacks: spoofing attacker crafts a forged second fragment that gets reassembled with the authentic first fragment and
results in a malformed packet, which is discarded by the resolver.
In linux, the reassembly cache is limited to n fragments per source, destination and protocol tuple via the
ipfrag max dist parameter, and is 64 by default; see [43].
Legacy kernel versions of Linux OS allow buffering of
up to few thousands of fragments.
IP-ID A SSIGNMENT M ETHODS . The strategy that the
attacker employs to predict the IP-ID value depends on
the IP-ID assignment method.
We carried out a study14 of the IP-ID allocation methods implemented by the name servers of the top level
domains (TLDs), i.e., a total of 271 TLDs, served by
1139 distinct IP addresses (407 IPs serve more than one
domain). Figure 7 summarises our findings15 related to
the IP-ID allocation algorithms supported by servers authoritative for TLDs: 0.51% servers could not be reached,
8.99% of the name servers assign a constant zero IP-ID
value16 in the IP header of DNS responses; 56.63% of
the servers assign per-destination incrementing IP-ID;
13.85% of the servers assign globally incrementing IPID, and 0.26% use some other allocation (under other
allocation we include (a seemingly) random IP-ID assignment); 19.74% support a mixed IP-ID allocation.
The mixed allocation is an indication of name servers
that support load balancing, [44]. When using DNS
server-side load balancing, several physical machines are
located behind the same IP address, and each physical
machine may be implementing a different IP-ID allocation mechanism at the IP layer. We extend more on this
14. During this study we sent 50 requests to each name server with
a 500 milliseconds delay between each request; we added the delay
since some name servers would return server failure response when
more than 10 packets were sent without any delay, and we found he
500 millisecond delay to be sufficient to receive the required responses.
15. It is important to emphasise that our study was conducted
from within the network of our university, and findings may vary
when performed from a different network, e.g., due to anycast routing
supported by DNS servers.
16. The zero IP-ID is assigned to DNS responses that do not get
fragmented.
Fig. 7.
Per-destination
Global
Other
Non-responsive
Mixed
The IP-ID allocation methods among the DNS servers authoritative for
(271) Top Level Domains (TLDs).
11
Fig. 8.
IP-ID hitting success rate for two domains each implementing a different
IP-ID allocation method.
12
44
55
7 8
98
Fig. 9.
Experimental Evaluation
13
Fig. 10. The wireshark capture of the attack, presenting only the packets exchanged between the name server 162.183.191.23 and the resolver. As can be observed,
after two malformed responses the resolver refrains from sending further queries to that name server for 15 minutes. Fragmented packets are coloured in white, DNS
requests in black, and reassembled DNS fragments in blue.
C ONCLUSIONS
Currently, the popular protection used by most DNS resolvers against poisoning relies on echoing the validation
fields in DNS response. Such mechanisms are clearly
insufficient to prevent poisoning by MitM attackers. A
20. A random prefix is a variation of the defense proposed in [17].
ACKNOWLEDGEMENTS
We are grateful to Wenke Lee and Dieter Gollmann for
their extensive and elaborate feedback on the earlier
version of this work. We also thank the anonymous
referees for their comments on the conference version.
This research was supported by grant 1354/11 from the
Israeli Science Foundation (ISF).
R EFERENCES
[1]
14
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
15
September 7-9, 2011, Proceedings, ser. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecomm.
(LNICST), Springer, Ed. Springer, 2011.
[48] , Antidotes for DNS Poisoning by Off-Path Adversaries, in
ARES, 2012.