Protecting Against DNS Cache Poisoning Attacks

Transcription

1 Protecting Against DNS Cache Poisoning Attacks Jonathan Trostle Johns Hopkins University, APL Johns Hopkins Rd. Laurel, MD Bill Van Besien Johns Hopkins University, APL Johns Hopkins Rd. Laurel, MD Ashish Pujari Johns Hopkins University Information Security Institute 3400 Charles St. Baltimore, MD Abstract DNS is vulnerable to cache poisoning attacks, whereby an attacker sends a spoofed reply to its own query. Historically, an attacker only needed to guess a predictable, or more recently, a 16 bit pseudorandom ID in order to be successful. The Kaminsky attack [7] demonstrated successful poisoning attacks that required only 6 seconds on typical networks. Since then, source port randomization (spr) has been used for additional protection. Nevetheless, E. Polyakov demonstrated successful poisoning attacks against spr given a Gigabit network, on the order of 10 hours. Even with slower network speeds, an attack is likely to be successful in a moderate time period. DNSSEC [3] will provide a strong countermeasure to poisoning as well as other attacks against the DNS. However, until DNSSEC is actually deployed, there is a need for additional countermeasures that can be deployed in the near term. In this paper, we describe a new approach that is based on detecting a poisoning attack, then sending an additional request for the same DNS Resource Record. Since the defense is only activated when attacks occur, we expect the performance impact to be minimal. The countermeasure requires no changes to the DNS standards, and only requires modifications to the caching server. Thus it can be deployed incrementally in order to obtain immediate security benefits. We show that our proposed defense makes poisoning attacks substantially more difficult. We have implemented the countermeasure using a local proxy for the BIND caching server, and our tests show that the performance impact is minimal. I. INTRODUCTION The Domain Name Service (DNS) has long been subject to poisoning attacks. A poisoning attack is carried out as follows: (1) a DNS resolver sends a DNS request to a recursive server (2) the resolver sends an answer to its own query using the address of the authority server as the source address. This attack has been facilitated historically, since both the source port and destination port have been well known ports. Since the recursive server caches the answer, a spoofed incorrect answer will also be returned to every other DNS client that requests a RR (Resource Record) for the same name, for the duration of the TTL (time to live). Thus this attack can be used in conjunction with web spoofing [5] to spoof a heavily used ecommerce web site. Even careful users will be fooled since the web url will be correct. There have been several improvements to DNS that have increased the difficulty of mounting poisoning attacks from trivially easy to requiring substantial work on the part of the attacker. The latest approach is to use random transaction ID s together with source port randomization (spr) [1]. These all operate in a security model where the attacker is remote and does not have eavesdropping access to DNS messages over the network. There are also specifications for Internet standards that provide stronger cryptographic mechanisms for DNS security including DNSSEC and TSIG [3], [14]. DNSSEC and TSIG protect against on-the-wire attacks as well as preventing spoofing in the remote attacker model. However, deployment of DNSSEC has not yet occurred due to the initial deployment costs and policy/legal issues associated with public key certification. Thus there is value in solutions that can improve DNS security, provided they can be deployed immediately. We emphasize that DNSSEC provides security against a wider range of attacks, in addition to protecting against cache poisoning. In [2], a clever mechanism, 0x20, is proposed to give additional protection against DNS poisoning attacks. DNS requests are sent with a random mixture of lower case and upper case characters. Most servers will reply with the same random mixture of characters in the domain name. Thus one additional bit per character in the domain name is gained, for the entropy of the request. Given both spr and 0x20, the attacker has to guess the transaction ID, the source port number, and the particular mixture of cases in the request. 0x20 only gives limited protection for short domain names. A more significant limitation is that not all DNS servers are 0x20 compliant, and 0x20 is unlikely to advance as an IETF standard. The effectiveness of this countermeasure is greatly reduced given even a small percentage of non-compliant servers, since then a list of the non-compliant servers would have to be maintained by all DNS requestors. It would be difficult to ensure that this list is up to date and accurate. Given the current countermeasure, random ID s combined with spr, an attacker may need to send requests for a period of anywhere between 1-5 days in order to successfully poison a DNS cache (we have verified this attack in our lab). Unfortunately, a determined attacker could carry out such an attack. In this paper, we present a technique that greatly increases the difficulty of DNS cache poisoning. We will show that a persistent long-lived attack has a minimal chance of succeeding, even over a period of a year or longer. Our new technique is based on sending additional DNS queries when a likely poisoning attack is detected. The recursive DNS server (our implementation uses a proxy) initially listens on k random ports. A packet received on any of these ports indicates a potential spoofing attack. When such /10/$ IEEE 25

2 a packet is received, the server enters the secure mode for a short period (e.g., 20 seconds). The server sends two DNS queries for each recursive request that it receives during this period. If the intersection of the RR s in the responses is nonempty (the common case), those RR s are cached and returned to the requestor. Since an attacker has to guess the transaction ID s and random ports for both of the requests, it is exponentially harder to successfully send a spoofed reply during the secure mode period. The attacker s optimal strategy is to keep guessing, in which case the server keeps re-entering the secure mode. We show that the attacker s probability of success is sufficiently low, given proper choices for the parameters k and w where w is the number of seconds that the server is in secure mode. (Stronger security is obtained with larger values of k and w.) The set of k ports is also updated as packets are received on them to prevent the adversary from identifying these ports in order to avoid them. Some DNS techniques vary the A records for content distribution, load balancing, and security. Our technique handles these cases since a nonempty intersection usually occurs in the first two responses. If not, an additional query can be sent. Most of the time, most DNS servers are not under attack, and thus overall performance impact should be minimal (servers operate as they do currently when not under attack). Our solution has the following properties: 1) It can be implemented and deployed immediately to obtain immediate security benefits. The deploying organization obtains the benefits. 2) It requires no changes to the DNS protocol or standards. 3) It requires no changes to the authority servers or DNS resolvers. 4) It greatly increases resistance against DNS poisoning attacks. 5) Performance impact is minimal. 6) No additional management overhead or cost. The main contributions of this paper include the following: We propose a new countermeasure against DNS poisoning attacks and we have implemented it using a proxy server. We have analyzed the security of our countermeasure given the natural model for DNS poisoning attacks. Our countermeasure greatly increases resistance against DNS poisoning attacks over spr plus random TID s. We analyze the performance of the countermeasure given our DPS (proxy) implementation, including the additional latency for the DNS client. We also discuss the additional load on the authority server and its network. The paper is organized as follows: in Section II, we give background on DNS operation and poisoning attacks. We also chronicle the evolution of countermeasures. In Section III, we present our countermeasure and its operation. Section IV analyzes both the security and the performance. We discuss our results in Section V, and we conclude in Section VI. II. BACKGROUND The DNS (Domain Name Service) is a critical part of the Internet infrastructure; it s main function is to map domain names to IP addresses. Thus an application is able to map a domain name (frequently entered by a user) into an IP address which can be used to send packets to the application server. The DNS protocol was originally specified in [8], [9], but more recent IETF RFC s specify additional functionality. DNS domain names consist of labels separated by periods. Each label is a domain and the concatenation of the labels is a fully qualified domain name (FQDN). The domains are nodes in a tree structure. A zone consists of a collection of nodes and is its own administrative unit. The root node for each zone is called the Start of Authority (SOA). For each zone, there are DNS authority servers which maintain the Resource Records (RR s) for the zone. There are several types of DNS RR s, but the two of interest for this paper are A RR s and NS RR s. The A RR s give IP addresses corresponding to the domain names, and the NS RR gives the domain name of the DNS authority server. There are three main entities in typical (recursive) DNS protocol exchanges, the stub resolver, the recursive server (also known as the recursive resolver or caching server), and the authority server. The stub resolver sends DNS queries (usually to obtain A RR s) to the recursive server. The recursive server attempts to locate the RR in the cache, otherwise it makes a series of recursive requests in order to locate the proper authority server and obtain the requested RR. We now give an example showing the operation of these three entities for a typical request. We will assume that no RR s are initially cached. 1) The stub resolver makes a request for to the recursive server. 2) The recursive server initially sends a request to the root server (authority for.). The root servers would send a reply indicating a delegation to.org by sending a NS RR and A RR for the.org nameserver. 3) Next, the recursive server would contact the nameserver for.org and receive a delegation to example.org including the NS and A RR s for a nameserver in example.org. 4) The recursive server now contacts the nameserver in example.org which returns an A RR for the server 5) Finally, the recursive server returns the A RR (which has the IP address for to the stub resolver. All of the RR s that the recursive server obtained are cached, up to the period indicated by the TTL (time to live) in the RR s. Some larger domains have multiple DNS servers. In our testing (described below), we noticed that some DNS authority servers return 6 A RR s per DNS query, and that subsequent queries may return distinct intersecting sets of A RR s (a set of RR s is called a RRset). 26

3 A. DNS Poisoning Here we briefly overview DNS poisoning attacks including their history. Figure 1 shows the three network entities discussed above together with a typical poisoning scenario. Here we assume the DNS recursive server does not have a RR with the name in its cache. In this case, the stub resolver makes a request for to the recursive server. The recursive server then sends a DNS query for to the authority server (the nameserver for example.org). to mount a successful poisoning attack. Although this raises the bar, as discussed earlier, an adversary can still successfully mount a poisoning attack. III. COUNTERMEASURE OPERATION Fig. 2. Overview of DNS Proxy Countermeasure Fig. 1. DNS Poisoning Attack In DNS poisoning the stub resolver is controlled by the attacker. The attacker s goal is to send the DNS query and then answer the query with a RR containing the IP address of a server that it controls. The DNS recursive server will accept the first answer that it receives where the transaction ID of the DNS answer equals the transaction ID of the DNS query. Thus the attacker s goal is to send DNS answer packets in between the time the recursive server sends the DNS query to the authority server and when it receives the answer from the authority server. This time window is the attacker s opportunity to poison the DNS server. The transaction ID field is a 16 bit field. Earlier DNS recursive resolvers simply incremented the transaction ID field. Thus it was very easy for an attacker to conduct a successful poisoning attack. Subsequently, DNS implementations randomized the transaction ID in their queries. With the random transaction ID, the attacker s probability of poisoning a name is roughly n/2 16 if it can send n answers in response to its query within the time window (in some earlier implementations it was easier for the attacker due to flaws in random number generation, and also birthday attacks [12], [13]). In 2008, Kaminsky [7] demonstrated a more efficient attack. The attacker sends queries for random names and attempts to answer the queries during the time window as discussed above. But the answers also include an update for the nameserver. When the attack succeeds, the nameserver is now a host controlled by the attacker. The key idea is that since the names are random, the attack can be mounted continuously since even if a name gets cached, the attack isn t affected. This attack only requires 5-10 seconds until success. Vendors responded by using spr (source port randomization) [1] which consists of sending the query from a random source port. Thus an attacker must now match both the source port and the transaction ID Here we overview the operation of our DNS poisoning attack countermeasure (see Figure 2). For ease of implementation, we have separated the new code into a separate process (DNS Proxy Server or DPS) from the caching server. 1) DPS initially listens on the standard DNS ports, UDP 53 and TCP 53, plus k additional randomly selected ports (not low numbered reserved ports though). The purpose of listening on these additional ports is to detect spoofing attacks, as early as possible. The set of k randomly selected ports is secret and should be modified as spoofing is detected as an attacker can identify this set over time. In particular, once a particular port receives a spoofed packet it becomes a candidate for removal from the set. If removed, it is replaced with another randomly selected port. Let P be the set of ports eligible to be amongst the k ports. When one of the k ports, a, receives a spoofed packet (most likely identified due to an incorrect ID value), then with probability k/ P, a remains in the set of k ports. With probability ( P k)/ P, another port is uniformly randomly selected from the remaining unused ports in P to replace a. Thus a is likely to be a member of the k ports with the same probability both before and after the attacker learns that a was a member. In other words, the attacker gains no information about which ports are in the set of k ports. This property is important for ensuring that the attacker does not achieve any advantage for evading detection during the spoofing attack. 2) Normal Operation: DPS acts as a proxy between BIND and the set of external DNS clients. Note that BIND configuration must be changed so that BIND listens on a different port (other than 53). 3) Suppose DPS receives a DNS answer on one of the k ports. It assumes this packet is part of a spoofing attack. It sets POISON DEFENSE to TRUE, and timer for w seconds. It enters the DNS question (name, type, and class) into a data structure S. It sends a new request out for the same DNS question (it uses a random source 27

4 port). It has the proper destination IP address to send it to (it was the source IP address in the spoofed answer). 4) When POISON DEFENSE is TRUE, every received DNS question is entered into S. DPS forwards the DNS request to BIND and sends its own request as well, for the same DNS question. 5) When POISON DEFENSE is TRUE, DPS checks to see that both DNS answers match (i.e., it checks for a nonempty intersection between the two returned RRsets. Two IP addresses are considered equal if they are on the same subnet which we have conservatively selected as being determined by the first 24 bits. Therefore one address can match multiple addresses in another DNS response. We give a real example below.) If there is a match, the addresses in the intersection are cached (with a TTL equal to the minimum of the TTL s for the associated RRsets) and forwarded to the client. In any case, the first received answer is entered into S. If there is no match (which is an event we haven t encountered in our testing), DPS sends an additional request in order to obtain another response for matching purposes. DPS also contacts a special handler that we have implemented in BIND, in order to remove the relevant RR s from the cache (the RR s that aren t in the intersection are removed). DPS will indicate which RR s should be removed. 6) When the timer expires, DPS sets POISON DEFENSE is FALSE. DPS will still process through all the remaining DNS questions and answers in S. When S is empty, it resumes normal operation. 7) DPS only caches high level names (e.g.,.com,.org, etc.) 8) If an answer is returned immediately from BIND, then it must be in the cache, and DPS will omit sending a 2nd request. 9) DPS does not send extra requests for PTR queries. DPS defers to DNSSEC/TSIG: if any returned RRset is signed, then that RRset is used without modification. IV. ANALYSIS We analyze our countermeasure with respect to security and performance. A. Security Analysis We analyze the effectiveness of our countermeasure against poisoning attacks. In particular, the attacker will attempt to reply to its own query by guessing the correct translation ID and port number. If successful, the attacker s DNS answer will be accepted and cached by the recursive server. The attacker is able to mount a Kaminsky-style attack by requesting RR s for random domain names and also including a NS (nameserver) update. Alternatively, the NS update can be omitted if there are a significant number of names of interest to the attacker; the attacker can cycle through these names for its recursive DNS requests. Our goal is to identify the most efficient attacker strategy and give a bound on its success rate. We will give an upper bound on the probability of the attacker successfully spoofing an answer to one of its queries, over a given time period. As above, we let k by the number of ports that the recursive server listens on (or the DPS listens on for our implementation). We let w be the number of seconds that DPS stays in secure mode, once it enters secure mode. From [2], the attacker has a certain time window to send answers to its own query to the recursive server, prior to when the authority server replies to the recursive server. The length of this time window determines the number of packets that the attacker can send. Once the authority server replies, the recursive server will accept this answer and cache it for the TTL period (which could range from 1-24 hours or even less see Section V). The attacker cannot spoof answers to a query for this domain name again until the TTL has expired. Let n be the number of packets in the time window, and we let t be the length of the time window in seconds. Prior to the attack, the recursive server is not in secure mode (it s in normal mode). Thus the attacker only needs to match the transaction ID and source port number of its DNS request. We let α = be the total number of possible ports that the random k ports can be drawn from. The probability that the attacker sends its spoofed reply to one of the k ports is k/α. We expect to receive a packet on one of the k ports after the attacker has sent α/k packets. Now we assume that the recursive server is using spr plus random transaction ID s. Following [2], we also assume that the authority server has three public IP addresses (this value is common but may vary slightly); the attacker must also guess the correct one of these addresses. Thus the attacker s probability of matching these three fields in its spoofed reply is α. Since n is the number of packets that can be sent in the time window, we have that the probability of obtaining a match is bounded by < n i P r[i packets sent before match] 2 16 (3α) i P r[i packets sent before match] 2 16 (3α) i=1 i=1 = α/k α 1 = 2 16 (3k) where we have used the union bound, and since α/k is the expected number of packets sent before a match on one of the k ports is obtained. Once DPS enters secure mode, then the attacker must match the 3 fields in each of two queries. The probability of this 28

5 TABLE I ATTACKER SUCCESS PROBABILITY BOUNDS, FOR VALUES OF k AND w, GIVEN SUSTAINED 1 YEAR ATTACK k w prob. bound seconds 1/ seconds 1/ seconds 1/ seconds 1/ seconds 1/ seconds 1/ event, given n attacker reply packets for the single attacker request, in the t second time window, is We have that p 2 = ( n 2) ( (2 16 ) 3α) 2 q = (1 p 2 ) (w)(1/t) is the probability of attacker failure during the w second time window (see Fig. 3). Fig. 4. Probability bound as a function of k and w. B. Implementation and Performance Analysis For our prototype, we implemented DPS in Java 1.6. We consider overall latency to be the most accurate performance metric since it is most dependent on the network environment. One hundred websites were selected randomly from the global 1,000 most-popular websites. Each test was conducted about fifteen to twenty minutes apart to allow cached results to expire in recursive DNS servers upstream. While the proxy increased latency by an average of 150ms from the control, there is little extra latency introduced when in poison mode. We believe that the 150ms figure can be substantially reduced by improving the design of the proxy, or by integrating the proxy to be a part of BIND. Table II and figure 5 provide performance metrics for each of the three tests. Fig. 3. Relationship between parameters w, n, and t. Thus 1 q is the probability of attacker success during the w second time window. Using the union bound, we have that the total attacker probability of success, prior to secure mode and during the w second secure mode period is bounded by (1 q) + 1 3k2 16 For a period consisting of lw seconds, using the union bound, we can therefore bound the attacker probability of success by l[(1 q) + 1 ]. 3k216 We may use the values from [2] where t = 1/10, and n = (the attacker has a 100Mb/sec. connection). Table I gives some success probabilities, given lw equal to one year. If we consider the bound above, we see that as k increases, the amount of reduction in the probability bound caused by increasing w decreases. Each doubling of w leads to almost a 1/2 reduction in the probability bound as long as w isn t too large. When k is small, then the reduction is by more than 1/2. The probability bound function (of k and w) is depicted in Fig. 4. Fig. 5. The distribution of DNS query latency, in seconds, for each of three modes. n = 100 samples. Our testing indicates that about 10% of the DNS servers returned different (but intersecting sets) across multiple DNS queries. If there was no intersection between two requests, we would send an additional request (but this did not occur during our tests). Table III provides an example of a DNS server providing three different responses for the same request. 29

6 TABLE II DNS QUERY LATENCIES (SEC.) BIND BIND+DPS BIND+DPS poison mode average median std dev min max TABLE III RESPONSE TO THREE DNS QUERIES FOR TWITTER.COM ;; ANSWER SECTION: twitter.com. 16 IN A twitter.com. 16 IN A twitter.com. 16 IN A twitter.com. 16 IN A twitter.com. 16 IN A twitter.com. 16 IN A ;; ANSWER SECTION: twitter.com. 18 IN A twitter.com. 18 IN A twitter.com. 18 IN A twitter.com. 18 IN A twitter.com. 18 IN A twitter.com. 18 IN A ;; ANSWER SECTION: twitter.com. 5 IN A twitter.com. 5 IN A twitter.com. 5 IN A twitter.com. 5 IN A twitter.com. 5 IN A twitter.com. 5 IN A V. DISCUSSION Recent studies (e.g., [10]) indicate that DNS caching servers may cache RR s for less than the advertised time period. Some CDN (Content Distribution Network) servers cache RR s for only 20 seconds. Given a 20 second TTL. Then we can mount a poison attack against a small set of names, more efficiently. Suppose the target set has 200 names. Then we can guess against each of the 200 names during every 20 second period. Given guesses per 100 millisecond time window per the description in Section IV. We obtain guesses against each name during the 20 second period. Given 200 names, we need on average 2 32 /2 7 = 2 25 guesses against one of the names. We have 2 25 /13000 < 2 12 so 4000(20) = seconds or 22 hours will be sufficient. Here we are not using the Kaminsky attack of updating the nameserver RR cache entry. Thus, if we used our countermeasure to only check high level names and NS (nameserver) updates, the poison problem would still remain. Our countermeasure does make Distributed Denial of Service (DDoS) attacks easier. In particular, since an extra DNS request is sent for each request received by the recursive server during the secure mode, there is an amplification by almost a factor of 2 during the secure mode. DDoS attacks against DNS are mitigated through the use of anycast [6]. In summary, we believe the amplification of DDoS attacks is acceptable since (1) there are other protocols that can also be used for amplification (e.g., SIP [11], or overlay network based protocols). (2) Successful DDoS attacks are fully realizable (for services that don t use anycast) without our poisoning defense. (3) DDoS attacks against DNS are harder given the use of anycast for authority servers. (4) DNS poisoning attacks are a persistent threat, and there is a need for a defense. VI. SUMMARY DNS is vulnerable to cache poisoning attacks, whereby an attacker sends a spoofed reply to its own query. The Kaminsky attack [7] led vendors to utilize source port randomization (spr) together with random transaction ID s. This combination eliminates the poisoning attacks that take less than 10 seconds, but slower poisoning attacks are still possible. As network speeds increase, the threat from these attacks will grow. DNSSEC [3] will provide a strong countermeasure to poisoning as well as other attacks against the DNS. However, until DNSSEC is actually deployed, there is a need for additional countermeasures that can be deployed in the near term. We have presented a new countermeasure against DNS poisoning attacks which is based on detecting a poisoning attack, then sending an additional request for the same DNS RR. Since the defense is only activated when attacks occur, the performance impact is minimal. The countermeasure requires no changes to the DNS standards and only requires modifications to the caching server. Thus it can be deployed incrementally in order to obtain immediate security benefits. We have implemented the countermeasure using a local proxy for the BIND caching server, and our tests show that the performance impact is minimal. Our analysis shows that we significantly increase resistance against poisoning attacks. REFERENCES [1] D. J. Bernstein. The dns random Library Interface. random.html [2] D. Dagon, M. Antonakakis, P. Vixie, T. Jinmei, W. Lee. Increased DNS Forgery Resistance Through 0x20-Bit Encoding. In Proceedings of the ACM CCS 2008 Conference October, [3] D. Eastlake 3rd. Domain Name System Security Extensions. RFC 2535, Internet Engineering Task Force, March [4] D. Eastlake 3rd. Secret Key Establishment for DNS (TKEY RR). September [5] E. W. Felten, D. Balfanz, D. Dean, and D. S. Wallach. Web Spoofing: An Internet Con Game. 20th National Information Systems Security Conference, October, [6] T. Hardie. Distributing Authoritative Name Servers via Shared Unicast Addresses. April [7] D. Kaminsky. Its the End of the Cache As We Know It. BO2K8.ppt [8] P. Mockapetris. Domain Names - Concepts and Facilities. November [9] P. Mockapetris. Domain Names - Implementation and Specification. November [10] M. A. Rajab, F. Monrose, A. Terzis, and N. Provos. Peeking Through the Cloud: DNS-based Estimation and its Applications. In Proceedings of the Conference on Applied Cryptography and Network Security (ACNS 2008), New York, NY, USA, June [11] J. Rosenberg et. al. SIP: Session Initiation Protocol. June [12] V. Sacramento. Vulnerability in the sending requests control of BIND versions 4 and 8 allows DNS spoofing. 19 Nov Dec [13] J. Stewart. DNS cache poisoning - the next generation [14] P. Vixie, O. Gudmondsson, D. Eastlake 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May