DepenDNS: Dependable Mechanism against DNS ... - Semantic Scholar

DepenDNS: Dependable Mechanism against DNS Cache Poisoning Hung-Min Sun, Wen-Hsuan Chang, Shih-Ying Chang, and Yue-Hsun Lin Information Security Laboratory, Department of Computer Science, National Tsing Hua University, Taiwan R.O.C [email protected], {eifie,godspeed,tenma}@is.cs.nthu.edu.tw

Abstract. DNS cache poisoning attacks have been proposed for a long time. In 2008, Kaminsky enhanced the attacks to be powerful based on nonce query method. By leveraging Kaminsky’s attack, phishing becomes large-scale since victims are hard to detect attacks. Hence, DNS cache poisoning is a serious threat in the current DNS infrastructure. In this paper, we propose a countermeasure, DepenDNS, to prevent from cache poisoning attacks. DepenDNS queries multiple resolvers concurrently to verify an trustworthy answer while users perform payment transactions, e.g., auction, banking. Without modifying any resolver or authority server, DepenDNS is conveniently deployed on client side. In the end of paper, we conduct several experiments on DepenDNS to show its efficiency. We believe DepenDNS is a comprehensive solution against cache poisoning attacks.

1

Introduction

Domain Name System (DNS) provides name resolutions between memorable domain names and machine-friendly IP addresses. Almost all network applications have to resolve given domain names to the corresponding IP addresses, such as http, ftp, email, etc. However, design of DNS is prone to suffering attacks [1,2]. The most critical one is DNS cache poisoning attacks. Main concept of DNS cache poisoning is to alter cache records of a DNS resolver. While user machines query the DNS resolver, they would obtain poisoned mapping information and connect to the forged IP addresses. Nowadays, phishing is a huge threat on the Internet [3]. Traditionally, attackers often exploit the similar domain name to cheat the victims to access the faked websites. For instance, attackers can impersonate legal banks to despatch e-mails. While victims receive the mails, the mails ask them to provide private information on a phished website. When the victims login to conduct transaction, their bank accounts or authorized codes of credit cards are going to be stolen. The above attack is called URL obfuscation. However, URL obfuscation is hard to accomplish since those mails may be filtered by the spam-mail engine. Or users may observe this attack since they pay more attention. Compared to URL obfuscation, phishing becomes more practical and large-scale by leveraging DNS J.A. Garay, A. Miyaji, and A. Otsuka (Eds.): CANS 2009, LNCS 5888, pp. 174–188, 2009. c Springer-Verlag Berlin Heidelberg 2009

DepenDNS: Dependable Mechanism against DNS Cache Poisoning

175

cache poisoning attacks. An attacker does not need to deliver faked url links within spam mails. Instead, he only alters mapped IP addresses of banks cached in DNS resolvers. Moreover, the scale of phishing becomes larger since users who query to the poisoned DNS resolvers would be phished. Numerous researchers have proposed solutions to prevent DNS cache poisoning. Popular countermeasures are based on cryptography, e.g., DNSSEC [4], TKEY [5], TSIG [6], or based on SSL [7]. They provide integrity of DNS message through cryptographic functions. However, these approaches require a major overhaul to the current DNS infrastructure. For instance, DNSSEC uses public key cryptography to authenticate communications. It requires a public key infrastructure (PKI) to distribute public keys. Another approaches use traffic analysis or construct a model to detect DNS cache poisoning attacks [8,9,10,11]. These approaches do not work well due to high false positive. On the other hand, several solutions against cache poisoning attacks were implemented on DNS resolvers without cryptography. DoX [12] adopts the peerto-peer system(P2P) to enhance DNS security, the cache updating is based on the trust between resolvers. In 2008, Dagon et al. proposed DNS-0x20 [13] to raise the low bound of DNS cache poisoning attacks. They utilized case encoding of the queries to increase the attacked complexity. However, these two approaches still need to modify DNS resolvers. There is a proposed approach implemented on DNS clients, ConfiDNS [14]. ConfiDNS that utilizes cooperative DNS resolver systems, CoDNS [15], provides more security against DNS cache poisoning attacks. CoDNS groups mutuallytrusted nodes agreement to resolve each other’s queries while the local infrastructure is failed, but its security is weak since any corruption or misbehavior of a single resolver can easily propagate throughout the system. Although ConfiDNS improves the security of CoDNS, their mechanisms are not strong against Kaminsky’s DNS cache poisoning attacks. In this paper, we introduce the proposed security mechanism, DepenDNS, against DNS cache poisoning attacks. DepenDNS utilizes multi-DNS resolvers lookup mechanism, e.g., obtaining a dependable answer via querying multiple resolvers. In brief, DepenDNS has the following advantages. Practical. DepenDNS is a client program based on built-in DNS lookup utility. Without modifying any DNS resolver or back-end authority server, DepenDNS is convenient to be deployed on user machines. Efficient. DepenDNS is a lightweight approach. The average lookup time is only 241.8ms when DepenDNS queries 20 DNS resolvers. And the storage for history usage is also tiny, 0.0739KB for a single domain name with one IP address. Secure. Comparing with existing DNS security mechanisms, DepenDNS provides sufficient security. Since poisoning multiple DNS resolvers at the same time is difficult and infeasible, DepenDNS utilizes the IP addresses through querying multiple resolvers concurrently. Moreover, the IP addresses returned by multiple resolvers are verified by our algorithm π. Instead of returning queried IP addresses only, π chooses the trustworthy and dependable IP addresses as output.

176

H.-M. Sun et al.

The rest of this paper is organized as follows. Section 2 presents some related background about DNS architecture and DNS cache poisoning attacks. Section 3 depicts the details of DepenDNS. Section 4 analyzes the security of DepenDNS. Section 5 shows our experiments about availability and overhead. Finally, discussion and conclusion are described in Section 6 and Section 7.

2 2.1

Backgrounds DNS Architecture Overview

DNS is commonly regarded as a distributed architecture in the form of an inverted hierarchical tree. Any DNS server containing a complete copy of the domain’s zone file is authoritative for that domain. These DNS servers are called authority servers. In DNS architecture, authority servers can delegate a sub-domain to another authority server and only maintain a referral to that server. Besides, two other components typically existed in DNS architecture, DNS clients and DNS recursive resolvers. Generally, user machines are capable of DNS client programs. When a DNS client wants to resolve a domain name, the client queries the DNS resolver via lookup procedure, instead of interacting with authority servers. Another component is DNS recursive resolver, also called resolver for simple. When a client sends queries to the resolver, the resolver will execute lookups processes from root authority server to leaf authority server. Once the resolver gets the response, the resolver sends the answer to the client and also maintains this answer in its cache. Here we use a brief instance to depict how DNS works. Resolving a domain name, e.g.,www.example.com., requires the following steps: 1. DNS client Dc sends the query to the DNS resolver Dr . This query is usually triggered by user applications, e.g. web browser. 2. Dr searches the corresponding domain name in its cache records. If a record is matched, the IP addresses would be returned to Dc . Otherwise, go to the next step. 3. Dr starts to hierarchically traverse down the DNS authority servers by querying sub-domain recursively until the original query is returned by a DNS authority server which is responsible for authoritatively answer. At the beginning, the root authority server (dot server, ”.”) points out a downward delegation of the com. to other DNS authority servers. Similarly, the com. authority server delegates to example.com. authority server. Then Dr obtains a response for www.example.com. which is returned by example.com. authority server. 4. The answer is returned to Dc , and cached by Dr to assist in further resolutions. Note that each answer of DNS authority servers would be cached until its TTL values expires. In the example, Dr caches the following IP addresses. (a) IP addresses of DNS authority servers which are responsible for com. (b) IP addresses of DNS authority servers which are responsible for example.com. (c) IP addresses of www.example.com.


2.2

177

DNS Cache Poisoning Attacks

DNS cache poisoning attacks are tampering with the cache records stored in resolvers. In Section 2.1, the resolver caches IP addresses to facilitate further queries. Once other clients query the same domain names, the resolver would directly return the IP addresses from cache records. If attackers could tamper with the cached records of resolvers, clients would receive malicious IP addresses and be phished to the malicious websites. The poisoning attacks could be achieved as follows. In Step 3 of the lookup procedure in Section 2.1, resolvers starts recursively querying with the backward authority servers when there is no matching records. Then authority servers would return appropriate answer to the resolver. Concurrently, the attacker could generates counterfeit packets and forwards them to the resolver before the legal packets of authority server reaches. To defend against such attacks, researchers proposed two well-known countermeasures, transaction ID authentication and port randomization. In the first approach, transaction ID is to authenticate connections between authority servers and resolvers. The attacker should forge legal answer packets with matched 16bit ID. However, the probability of guessing the matched transaction ID could be much higher based on weaknesses in the random number generators and birthday attacks [13,12]; even if there are 216 = 65536 possibilities, it is feasible to guess the ID value successfully. The second approach is port randomization which also increases the computation overhead on DNS cache poisoning. In port randomization, DNS resolvers would randomly choose a 16-bit source port number in the query packet. Once it receives the answer packet from authority server, this field is also adopted for authentication. However, several source ports could not be utilized, such as the well-known ports, e.g., port numbers less than 1024. Leveraging these two approaches concurrently, an attacker only guess about 230 to 232 combinations. Nevertheless, not all DNS resolvers are capable of port randomization, especially the DNS resolvers in embedded systems [13]. Thus, existing mechanisms are not secure enough for current DNS architecture. 2.3

Dan Kaminsky’s DNS Cache Poisoning

The primitive DNS cache poisoning attack spends a large amount of time for waiting for TTL value to expire. The attacker will have to wait for TTL value to expire when the targeted DNS resolvers have already the specific records (the records are for some domain names which were targeted by the attacker). In 2008, Dan Kaminsky substantially reduces the attack time of DNS cache poisoning attacks. The skill is called nonce query. The attacker queries a series of nonce queries to a DNS resolver. Each query is with a different random prefix and contains additional records with genuine owner domain names but malicious IP addresses. If the DNS poisoning attack fails to match the correct transaction ID, a new nonce query with a distinct prefix is generated. Because each round of the attacks has the different prefix of domain name, the DNS resolver will consult with the backward DNS authority servers each time, no need to wait for

178

H.-M. Sun et al.

Query Packet: Query Section - Domain Name: .example.com Spoof Response Packet: Query Section - Domain Name: .example.com Answer Section - Resource Data: arbitrary IP addresses Authority Section - Resource Data: example.com Additional Section - Additional Data: 123.456.78.90

Fig. 1. Example of Dan Kaminsky’s DNS Cache Poisoning

TTL value expiration. Here we use a brief instance to depict how Kaminsky’s DNS cache poisoning works (See Fig. 1). At the beginning, an attacker sends a nonce query of victim domain name (e.g., example.com) to the target resolver. The prefix of a nonce query is randomly generated, for domain www.example.com, could be abc. Hence, the nonce query is abc.example.com. Because the records of this nonce query are always not exist in target resolver, the resolver will consult with the backward DNS authority servers every time. Concurrently, the attacker sends a large number of spoofed response packets to the target resolver. These spoofed response packets include malicious informations in authority section and addition section. The functionality of authority section and addition section are used to update corresponding records in the resolvers. However, the attacker utilizes these two sections to tamper with the records in resolvers. Kaminsky substantially reduces the attack time from weeks to seconds. An attacker could succeed to launch attacks within about 6 seconds on most networks [13]. 2.4

Attack Model

We assume that attackers can generate any packet forged and forward the packet to any resolver targeted. The goal of the attackers is to tamper with the cache records in resolvers and direct clients to malicious websites. The patterns of such attacks are similar even in Dan Kaminsky’s DNS cache poisoning attacks. The attackers exhaustively generate and forward the forged answer packets to the resolver, until a answer packet is same as that one generated from the authority server. Therefore, several countermeasures against such attacks is to increase complexity of guessing correct answer packets, e.g., random transaction ID and port randomization. In other words, if the complexity gets higher, the countermeasure is stronger against cache poisoning attacks.


179

Besides that, we assume that the caches of the resolvers are poisoned with independent success probability. This assumption is reasonable because the most countermeasures are randomized algorithms. The attackers hardly take advantage of the previous success attacks since the countermeasures in each query are usually with different randomness.

3 3.1

DepenDNS Multi-DNS Resolvers Lookup

The multi-DNS resolvers lookup mechanism protects users against DNS cache poisoning attacks. Traditionally, when a user visits a site www.example.com, the browser sends the query to one default resolver provided by ISP. Instead of querying single resolver, DepenDNS duplicates the query and sends them to multiple resolvers according to the predefined DNS resolver list. Once DepenDNS gathers multiple responses from the resolvers, it will choose some trustworthy IP addresses according to the proposed matching algorithm π. (See Section 3.2) DepenDNS executes the following actions when a user wants to visit a website through network applications, e.g., web browser. These actions are shown in Fig. 2. 1. The browser triggers DepenDNS to handle the domain name x of website. 2. DepenDNS sends the duplicated queries of x to multiple resolvers from the resolver list. Without loss of generality, we assume the number of resolvers is t. 3. DepenDNS looks up the history data Hx for x. If a matching record is found, this means there was the same query in the past. 4. Let R = R1 ∪ R2 ∪ ... ∪ Rt where Ri is the set of IP addresses returned from ith resolver. Given R and Hx as inputs, run algorithm π. 5. According to algorithm π, DepenDNS chooses a set of trustworthy IP addresses A ⊆ R. 6. Based on A, the browser will connect to the trustworthy IP addresses. 7. Store A into history data for further utilization. The successful probability of poisoning multiple resolvers is quite lower than that of poisoning one resolver in a time period. The more resolvers we query, the higher accuracy of queried IP addresses we obtain. The detail analysis is presented in Section 4. 3.2

Matching Algorithm π

If we only consider the countermeasure against DNS poisoning attacks, choosing the most appeared IP addresses is intuitive. However, this approach may destroy the load-balance mechanisms since users all connect to the most appeared IP address [16,17,18]. Instead, algorithm π picks up a set of IP addresses A which are dependable and trustworthy.

180

H.-M. Sun et al. User Computer Application e.g, ftp, http browser DepenDNS

AX

Domain X

DNS Resolver 1 X DNS Resolver 2

X

Lookup Program

X AX

. . .

R1

HX

Store AX History Data

Matching Algorithm

R2

π

DNS Resolver t

Rt

Fig. 2. The Proposed Multi-DNS Resolvers Lookup Scheme

To design algorithm π, we observe some properties of IP addresses returned from multi-DNS resolvers according to the experiments (See Section 5). We exploit these properties to select IP addresses. First, we define nij , ni , and ck as follows. ⎧ t ⎨ 1, if IPi ∈ Rj . nij . , and ni = nij = ⎩ 0, otherwise. j=1

ck =

ni , where IPi exists in the k th class B IP address.

According to the above definitions, ni counts the number of IPi appearing in the responses from all resolvers, and ck counts the number of IP addresses in k th class B. Furthermore, let nmax = M ax(n1 , n2 , ..., n|R| ), where M ax(.) outputs the max value of a set and |R| denotes the size of set R. Next, we define the following three policies according to the properties. Each unique IP address is individually verified, and the following shows the verification of IPi . – α: Because each domain name has different number of IP addresses, and the associated authority servers decide how many number of IP addresses is returned by the resolvers in each query. The authority servers not always return all IP addresses but instead they return a subset of all IP addresses according to their load-balance mechanisms. This means that the responses from multiple DNS resolvers will be dispersed to each IPi . According to our observation, when we query to multiple resolvers, each ni will be quite closed if the load-balance mechanism is to averagely allocate traffic to each IPi (such as Round-Robin DNS [17]). The following is the evaluation of α,


181

where 20% is the tolerance of ni . We can decrease the tolerance to increase security. 1, if ni ≥ nmax (1 − 20%). α= 0, otherwise. – β: According to our experiments, almost all domain names did not change their IP addresses at all in one week. It implies that the IPi is trustworthy if this IPi exists in history data at the same domain name. The following is the evaluation of β: 1, if IPi exists in history data at the same domain name. β= 0, otherwise. – γ: A domain name may have several IP addresses but these IP addresses usually belong to some same class B, which means the first 2-octet prefix of the IP addresses are the same. Although the returned IP addresses will not be all the same in each query, the proportion of specific class B IP addresses will be almost the same in each query (See the example in Table 2). The following is the evaluation of γ, where 10% is the tolerance of ck . We can decrease the tolerance to increase security. ckcurrent and ckhistory represent the ck of current query and history data, respectively. ⎧ ⎨ 1, if IPi belongs to k th class B and −10% ≤ ckcurrent − ckhistory ≤ 10% γ= ⎩ 0, otherwise. Next, we define the regions of IP addresses, denoted by N, as follows. – N : As we mentioned above, the responses from multiple DNS resolvers will be dispersed to each IP address, and we use N to represent the dispersion strength. For example, if a domain name totally has three IP addresses (IP1 , IP2 , IP3 ) and returns only one IP address to each resolver. We say that this domain name has three regions, N = 3. The following is the calculating of N: |Rα ∪ Rβ ∪ Rγ | N= M ode(|R1 |, |R2 |, ..., |Rt |) In the denominator, M ode(.) outputs the value that occurs the most frequently in the set. We use M ode(.) to reduce the effect of that the attacker uses some poisoned Ri to affect the value of N , namely, reducing the effect of outliers. According to the above definitions, N means the regions of IP addresses, and each ni will be smaller if N is bigger. However, attacker is easier to pass the verification of α if N is bigger (nmax is smaller). Therefore, we decrease the weight of α and instead increase the weight of β and γ when N increases. In this way, besides passing verification of α, the attacker should pass β, γ or both to pass the verification of π.

182

H.-M. Sun et al.

Next, we calculate a grade G for each IPi according to the three policies. The grade represents the strength of reliability about IPi . Gα and Gβγ represent the weights of α and βγ where Gα + Gβγ = 100. We set Gα and Gβγ to 60 and 40 respectively in our experiment. G = α ∗ (Gα − (N − 1) ∗ 10)% +

1 2

∗ (β + γ) ∗ (Gβγ + (N − 1) ∗ 10)%

Finally, we select the IP addresses whose grades are greater than or equal to 60, store these IP addresses in set A and return A to browser. We set Gα = 60 because we think a IP address is undoubtedly trustworthy if most resolvers return this IP address. More specifically, when N = 1, passing verification of α is enough. According to our experiments (See Section 5), the grades of more than 94.67% IP addresses are over 60 in normal cases. Although some IP addresses of a website fail the verification, the experiments show that at least one IP address would pass the verification. In other words, the IP addresses which fail the verification would not result in unreachable websites. Furthermore, it is extremely difficult to obtain a high grade of malicious IP address in DNS cache poisoning attacks (See Section 4). 3.3

History Data Records

Because DepenDNS utilizes the history data in algorithm π, the reliability of history data is an important issue. If a name-to-IP mapping has been the same for an extended period of time, the history data may be reliable. On the contrary, a frequently changed name-to-IP mapping may indicate that a server frequently migrated to other IP addresses and this causes the history data unreliable. In previous study [19,14], more than 85% of domain names did not change their IP addresses in one month and only 2% of domain names change IP addresses more than once per week. Therefore, it is very likely that the attack occurs if some IP addresses which does not exist in 7-day history data are returned.

4

Security Analysis

In this section, we analyze the probability of passing α, β and γ verification according to the attack model. The probability of passing α verification (P α ). We assume that there are t selected DNS resolvers d1 , d2 , ..., dt , whose probabilities of poisoning their caches are p1 , p2 , ..., pt , respectively and p¯i = 1 − pi . Let J(d1 d2 d¯3 ...d¯t ) denotes that the probability of poisoning exact d1 and d2 in a time period. Let Ei denotes the probability of poisoning any i of t resolvers, e.g., E0 = J(d¯1 d¯2 d¯3 ...d¯t ) and ¯ dt ). Let Pi denotes the E1 = J(d1 d¯2 d¯3 ...d¯t ) + J(d¯1 d2 d¯3 ...d¯t ) + ... + J(d¯1 d¯2 ...dt−1 probability of poisoning at least i of t resolvers. Pi = 1 −

i−1 j=0

Ej .

(1)


183

Recall that for a IPi , α is set to 1 while ni is greater than nmax (1 − 20%). The best case, the least number of resolvers the attacker should poison, occurs while nmax = nj and ni = 1, i = j. In this best case, the attacker should poison at least x resolvers to pass α where x ≥ (nmax − x)(1 − 20%). Consequently, we can infer P α ≤ Px where x ≥ 49 nmax . To simplifying estimation, we assume that these probabilities p1 , p2 , ..., pt are equivalent and independent. Namely, we assume p1 = p2 = ... = pt = p and J(d1 d2 ...dt−1 d¯t ) = p1 p2 ...pt−1 p¯t = pt−1 p¯. (1) is simplified to (2). Pi = 1 −

i−1

(tj )pj p¯t−j .

(2)

j=0

In most cases, N is fixed and determines nmax . If we assume that t = 20 and N = 1, 2, 3, 4, nmax is about 20, 10, 7, 5, respectively and the numbers of resolvers the attacker should poison are 9, 5, 4, 3 in the best cases, respectively. If we assume that p = 2−16 , the success probabilities are 2−126.64 , 2−66.080 , 2−51.758 , 2−37.845 , respectively. For p = 2−32 , the success probabilities are 2−270.64 , 2−146.08 , 2−115.76 , 2−85.844 , respectively. Since all probabilities are quite smaller than that of poisoning single resolver, α in DepenDNS is significant for security if nmax is in a reasonable range. The probability of affecting N . N determines the weights of α, β and γ in grade G. It threatens the security of the proposed scheme that attackers can easily adjust the value of N . More specifically, if the attackers set bigger N , they have higher probability to pass α verification. Therefore, N should be hardly affected. According to the calculation of N , the probability of affecting numerator is P α∨β∨γ and that of affecting denominator is usually close to P 2t because the values of |Ri |, i = 1, 2, ..., t are usually all the same according to our experiments. In short, affecting N is infeasible. The probability of passing β verification (P β ). P β is equal to P π since all IP addresses in history data should have ever passed the verification of DepenDNS. The probability of passing γ verification (P γ ). P γ refers to the hardness of applying a specific class B IP address. In practice, to apply such a IP address is not trivial because the application for specific class B IP address needs some licenses. In addition, even if the attacker gets the same class B IP address with legal owner’s class B IP address, she still needs to let the value of ckcurrent close to ckhistory . Therefore, the attacker is difficult to pass the verification of γ. The probability of passing DepenDNS (P π ). For an attacker, P π is equal to the probability of obtaining a grade which is equal or greater than 60. Since the malicious IP address would not be in history data before and N , which is hard to affect, is less than 6, the IP address should pass α and γ. Therefore, P π = P α P γ . According to the above analysis, P π would be quite smaller than that of poisoning a single resolver. This demonstrates that DepenDNS is more

184

H.-M. Sun et al.

secure than other conventional mechanisms whose security depends on a single resolver.

5

Experiment Conduction

The history data was collected in 7 days - from 26th Mar, 2009 to 2nd Apr, 2009, and we query 20 resolvers for different domain names once per half an hour in this week, so each site has 336 lookup records in history data. After that, we use DepenDNS to query the same sites 200 times. 5.1

Availability

We assume that α ¯ denotes the cases of failing the verification of α, α ∧ β denotes the cases of passing both verifications of α and β, and β|α denotes the cases of passing the verification of β in the condition of passing the verification α already. Table 1 shows the percentage of IP addresses matching our policies α, β and γ in the varied conditions. In the result, most of the IP addresses matches the policies so the policies are consistent with the way that the authority servers handle the domain name queries. More specifically, α refers to that the responses from multiple resolvers are dispersed to each IPi . β refers to that the authority servers rarely change the IP addresses in one week. γ refers to that the authority servers usually use the IP addresses in some same class B and the proportions of different class B IP addresses are usually fixed each time. In addition, none of α, β and γ is removable because each of them has its importance. We explain some special cases as follows. β ∧ γ|¯ α represents that even if some legal IPi with small ni fail the verification of α, they still probably pass the verification of DepenDNS. As shown in the example in Table 2, when N is big (N = 6), some legal IP addresses are hard to pass the verification of α but these addresses can get sufficient grades from the verification of β and γ. α ∧ γ|β¯ represents the cases of new IP addresses (maybe the domain name adopts dynamic IP addresses). We notice that over 80% new IP addresses are accepted according to the successful verification of α and γ. Furthermore, the Table 1. The percentage of IP addresses passing DepenDNS verification (G ≥ 60). ” − ” denotes non-existed condition and ”x” denotes the cases of G < 60. Policy α β γ α|β¯ ∧ γ¯ β ∧ γ|α ¯ α ∧ γ|β¯ α ∧ β|¯ γ α∧β∧γ

N =1 1