Introduction
Contents
1 Introduction
The correctness and availability of information in the Domain Name System are crucial for the operation of the Internet.
In particular, DNS poisoning is a significant threat to Internet security, and can be used for phishing, credentials stealing (e.g., XSS), sending spam and phish- ing emails, eavesdropping, and more.
Due to its wide use and universal availability, the DNS is also abused in other ways for different goals, including Denial of Service, fast-flux, covert botnet communication, and more.
Most DNS (poisoning and other) attacks ‘in the wild’, as well as most research, considered an off-path adversary that is able to send spoofed packets (but not to intercept, modify or block packets).
The most well known is Kaminsky’s DNS poisoning attack [21], which was exceedingly effective against many resolvers at the time (2008). Kaminsky’s attack, and most other known DNS poisoning attacks, allows the attacker to cause resolvers to provide incorrect (poisoned) responses to DNS queries of the clients, and thereby ‘hijack’ a domain name.
We refer to this type of attack as Domain-hijacking DNS poisoning, to distinguish between it and two other variants of DNS poisoning, to which we also present off-path attacks; more below (and see Table 1).
The increased awareness to the risks of DNS poisoning, following the publication of Kaminsky’s attack, was one of the factors helping to speed-up the (long-overdue) adoption of the DNSSEC standard [2–4].
DNSSEC uses digital signatures to prevent poisoning of the DNS responses, and is hence secure even against man-in-the-middle (MitM) adversaries. DNSSEC had a long and thorough design and evaluation process, and its security is based on extensive evaluation by many experts, as well as on results of formal analysis, e.g., by Bau and Mitchell [5]. (There are also alternate proposals for security against MitM, e.g., DNS Curve [7]).
However, deployment of DNSSEC is challenging and would take considerable time. Hence, as a more immediate response to Kaminsky’s attack, resolvers were rapidly ‘patched’ to protect against it, mostly following RFC5452 [19]. The ‘patches’ include source port randomisation, source and destination IP randomisation, and query randomisation:
- case toggling (‘0x20 encoding’, [9]) and addition of a random prefix to queries [30].
These ‘patches’ increase the entropy of ‘unpredictable’fields copied from DNS requests to DNS responses, and hence are trivially insecure against MitM attackers. However, these patches are considered best‘practice’, since they are believed to provide sufficient security against off-path attackers (which is considered as sufficient defenses for many systems).
We show that, under common scenarios - which seem likely to become even more common in the future, an off-path attacker can efficiently circumvent all of these mechanisms. Namely, an off-path attacker can perform effective ‘domain-hijacking’ DNS poisoning attack, circumventing all the ‘patches’, and with even better efficiency than Kaminsky’s poisoning technique. However, our domain-hijacking attack fails when DNSSEC is correctly and fully deployed. This attack works in scenarios where DNSSEC is partially or incorrectly deployed, such as permissive resolvers and islands of trust; currently, such scenarios are rather common.
We also present three other attacks, which apply even if DNSSEC is correctly and universally deployed:
../Subdomain Injection, is a poisoning attack which causes resolvers to accept, cache and provide to clients a mapping for a non-existing (child) domain, of a DNSSEC-protected parent domain.
As [5] observed, when the parent zone supports NSEC3 opt-out, the attacker can create fake (non-existing) sub-domains; this can lead to attacks on Same Origin Policy such as XSS, phishing and cookie stealing. We show how an off-path attacker can achieve the same effect.
/Name Server (NS) Hijacking, is a poisoning attack which causes resolvers to cache and use incorrect name servers for a DNSSEC-protected domain, typically, pointing them to name servers belonging to the attacker.
We show how this attack provides new, efficient off-pathmethods for traffic analysis, covert channels and Denial of Service; notice the attack and its applications are viable, even if DNSSEC is universally and correctly deployed, since the delegation NS and A resource records (RRs) are not signed.
./Name Server (NS) Blocking, allows the attacker to force resolvers to query name servers of his choice, and stop using other name servers, by corrupting fragmented responses from those name servers. This is not a poisoning attack, since it does not involve a resolver accepting fake resource records. In fact, one application of this attack is to facilitate poisoning, by causing resolvers to use specific name servers, possibly known to be vulnerable; this provides an effective mechanism to deploy the attack of [32], which was, so far, considered impractical. Under certain situations, this attack can also be used for off-path Degradation of Service and traffic analysis.
We summarise all our attacks, with their requirements, in Table 1.
The requirements are explained in Section ../2; for now, it suffices to mention that they all reflect common situations in the current DNS, many of which are not expected to change, even if DNSSEC is fully, universally and correctly deployed.
The main exception is attacks which require partial or incorrect DNSSEC deployment; however, not only is this requirement currently often satisfied, but it is also required only for the ‘domain hijacking’ attack.
In fact, ironically, the use of DNSSEC is often what provides necessary requirements for our attacks to work.
Specifically, all of our attacks require ‘Fragmentable zone’, implying fragmented DNS responses; and three of the attacks require ‘Poisonable zone’, implying that the second fragment contains complete resource record(s), from the ‘authority’ and/or ‘additional’ sections. More details on the requirements are presented within.
DNSSEC requires long resource records (RRs) which results in long DNS responses.
Long DNS responses (i.e., above 512 byte) require support of the EDNS extension mechanism, [35], and often fragmented when sent over UDP, since their size exceeds the path MTU. It is exactly this fragmentation that facilitates our attacks; e.g., we show that off-path attackers can often replace the second fragment of a packet, resulting in a seemingly-valid, yet fake, DNS response, or ‘merely’ causing corruption of the DNS response.
Fragmentation is known to be problematic or ‘harmful’, mainly due to the negative impact on performance; see the seminal paper of Kent and Mogul [23]. As a result, fragmentation is usually avoided, e.g., by use of path MTU discovery [28, 29], mainly for connection-based transport protocol (TCP). However, DNS traffic is usually sent over UDP; while several significant name servers, e.g., com, edu, send long responses over TCP, this may not be a good long-term solution, since the use of TCP results in significant overhead.
Related Work
Our work builds upon previous disclosures of vulnerabilities due to the design or implementations of the fragmentation mechanism;
we next mention few of the most relevant. Zalewski [37] suggested that it may be possible to spoof a non-first fragment of a (fragmented) TCP packet. However, using such non-first-fragment injec- tions to TCP packets seems challenging. Furthermore, currently almost all TCP implementations use path MTU discovery [28, 29] and avoid fragmentation.
Several vulnerabilities related to IP fragmentation, and specifically to predictable fragment identifiers (IP-ID) values, are covered in [14, 15]. Later, predictable IP- ID values were shown [12] to allow interception and injection of fragments, as well as dropping of fragmented packets.
While for our purposes, a simple, randomised modification of fragments suffices, we modify the technique from [12] to improve the efficiency of the attack in some scenarios; details within.
Attacks DNS Poisoning (Section 4) Name Server Domain Hijacking Subdomain Injection NS Hijacking Blocking Requirements
Section 4.1 Section 4.2 Section 4.3 Section 3.2 IP-ID √ √ √ √ ‘Fragmentable zone’ √ √ √ √ ‘Poisonable zone’ √ √ √ ‘Permissive or Island’ √ NSEC3 opt-out √ RFC 4697 √ Table 1: Our attacks and requirements.
Attacker Capabilities.
The required attacker capabilities include an arbitrary off-path, spoofing-only adversary, that controls a ‘puppet’, i.e., malicious (but sandboxed) script which can query the resolver; see Figure 1.
Figure 1: Simplified network topology and attacker capabilities. The spoofing attacker uses a puppet to invoke the query.
Contributions.
Incremental DNSSEC Deployment is Vulnerable
We show that incremental deployment of DNSSEC is risky, and exposes resolvers to cache poisoning at- tacks. We present techniques which allow efficient and effective Kaminsky-style [22] cache poisoning attacks, using off-path spoofing adversaries. Our techniques (exploiting fragmentation) allow to circumvent the entropy (randomisation of query, source port and IP) in DNS responses, as those entropy fields remain in the first fragment. This exact technique of circumventing the entropy fields allows us to revive the Kaminsky attack, and to replace the authentic records in a DNS response with spoofed records.
Subdomain Injection
We show that an off-path at- tacker can perform the attack that was believed to be feasible for MitM.
Unsigned Delegation
We suggest attacks exploiting unsigned NS and A delegation records, breaching privacy and anonymity, and inflicting denial/degradation of service.
Name Server (NS) Blocking
We introduce the name server blocking technique, which allows an attacker to force the resolver to stop using a particular name server, and eventually, to query a name server of attacker’s choice, e.g., a compromised name server, when resolvers strictly follow RFC 4697 [25].
We performed an experimental evaluation of our attacks against standard resolver software and issuing queries to real TLD name servers, such as org, and against the name server of the domain of our university, i.e., sec.cs.biu.ac.il.
Organisation.
In Section ../2 we outline the assumptions which are required for our attacks and in Section ../3.1 we provide the basic mechanisms for our attacks.
Then, in Section ../3.2, we show techniques for name server blocking, and in Section ../4 we present the poisoning attacks.
We then conclude and propose defenses in Section /5.