DNS Cache Poisoning Chris Racki CMPT-585 Dr. Robila 8 Dec 2008

Transcription

1 DNS Cache Poisoning Chris Racki CMPT-585 Dr. Robila 8 Dec 2008

2 Abstract Using the internet any computer can theoretically communicate with any other computer in the world so long as they are both connected to the internet. Amidst all of the computers connected to the internet, how do you know where the computer that you want to talk to is located? The answer is to use DNS which serves as an internet phone book of sorts linking us to anywhere that we might want to go. As many requests to DNS servers will be repeated it makes sense to cache the results and just reuse them to improve performance. This caching functionality opens up a risk of compromising the integrity of the DNS server by making it susceptible to DNS cache poisoning attacks. DNS cache poisoning attacks can potentially assign any IP address to any internet address. DNS cache poisoning is not new, but recently a new approach to the attack has been discovered that makes it much more effective and potent. Finally as a curiosity some commonly available DNS server safety check tools were tested to determine the current state of this author s internet service provider s DNS server. Introduction The internet has had a very colorful history so far. Its reach and influence continues to increase. We continually learn of new applications for the internet, and we continue to push more and more of our lives into the web. More and more electronic devices that we rely on in daily life are dependent on the internet in turn making us dependent on the internet to some degree. We are placing a tremendous amount of blind faith in the reliability of the internet. This would not be a problem if the internet was in fact reliable. However the internet is vulnerable to many points of weakness. One such point of Page 2 of 18

3 weakness is in the very foundation of the infrastructure of the internet. The internet is at its base flawed and vulnerable to severe compromise. The system on the internet responsible for navigating users to their appropriate locations, DNS, is exposed to attack by its very design. In the summer of 2008 a new threat to this system was discovered that drove fear and almost panic into the entire internet security community. This threat is a new application of the classic DNS Cache Poisoning attack. Internet navigation Using the internet any computer can theoretically communicate with any other computer in the world so long as they are both connected to the internet. The obvious question becomes, amidst all of the computers connected to the internet, how do you know where the computer that you want to talk to is located? We can find a very convenient real world analogy for this. If you want to telephone Dr. Robila at Montclair State University in New Jersey, how do you know which phone is his? Unless we call Dr. Robila on a regular basis we don t know his direct number. So in this case we need to perform a lookup of his number using a telephone book. Once we get his number from the phone book we can call him. The internet works in much the same way. When a user attempts to connect to a computer on the internet, in other words visit a website or access some other resource, the client computer sends that request to its internet service provider. When the request is to visit a commonly visited website, such as the internet service provider may already know where it is and it provides the connection information to the client. If the request is for something that the internet service provider doesn t know, then it must look it up much as we looked up Dr. Page 3 of 18

4 Robila s phone number in the telephone book. In technical terms, this phonebook is called a DNS (Domain Name System) [1]. DNS In the early days that pre-dated the internet as we know it today, there weren t very many computers interconnected and so the problem of locating computers was much simpler. Back then there was no internet, it was just ARPAnet (Advanced Research Projects Agency Network). Many people consider this to be the beginning of the internet. ARPAnet was a computer network developed by the United States Department of Defense to facilitate communication among computers [6]. When a computer wanted to connect to another in the network it would look up the receiving computer s address in a file called HOSTS.TXT [1]. This file was stored on a computer at SRI (Stanford Research Institute) which is now known as SRI International [7]. As networks began to grow it became apparent that this system would not be feasible. Using a host file to store lookup information has many drawbacks that become painfully more apparent as the network grows. The main drawback is that when there are many host files and the address of a computer changes, all of the host files that refer to it must be updated. The answer to this problem came in 1983 when the first DNS system was invented by Paul Mockapetris. In 1984 the first UNIX based implementation was developed at the University of California Berkley. The system was called BIND (Berkley Internet Name Domain). BIND has evolved greatly since that time currently existing at version 9. Page 4 of 18

5 There are other DNS systems available and in use, but BIND remains the most commonly used DNS on the internet [1]. How DNS works When we wanted to look up Dr. Robila s phone number we looked in the phone book. This assumes that we know which phone book to look in. There are in fact many different phone books to make all of the records more manageable. In certain cases we may not even know which phone book we should consult. DNS functions much the same way. DNS is composed of a number of servers. Each server knows something that the others don t, and combined they can offer us all of the information that we need. DNS can be viewed as a distributed database system. There are 13 DNS root servers scattered in locations throughout the world serving the internet. Since they are a sort of starting point for many DNS requests, their IP addresses do not change often. This makes their addresses relatively constant and quite reliable. They are named A.ROOT-SERVERS.NET, B.ROOT-SERVER.NET,, M.ROOT-SERVERS.NET [9]. Each root server is responsible to serve a particular geographical location and is operated independently. For instance A.ROOT- SERVERS.NET is located in two sites in Dulles, VA USA, and Ashburn, VA USA and is operated by VeriSign, Inc. B.ROOT-SERVERS.NET is located in Marina Del Ray, CA USA and is operated by Information Sciences Institute. Similarly all of the other root servers are distributed around the world [8]. The root servers don t know everything, and alone are not very helpful. However they do know where to find other servers that Page 5 of 18

6 have more information. The root servers are responsible for knowing where to find the Global Top Level Domain Servers. The Global Top Level Domain Servers know all about the top level domains. The top level domains include the following: COM, EDU, GOV, MIL, NET, ORG, ARPA, (country code), AERO, BIZ, COOP, INFO, MUSEUM, NAME, and PRO [9]. These servers know how to route requests further so that they can be answered. Beyond that there are lower level servers that know even more details to route a request. Eventually this granularity leads to the authoritative server for a domain. That is a server that knows directly how a local domain is organized because it s responsible for managing it [2]. What s in a request DNS servers are most famous for their ability to provide us with the IP address of computers that we want to find. And while this is their primary function they can perform others as well. Some of the common records that DNS servers work with are type A, type NS, type MX, type SOA, type CNAME, and type TXT [5]. For the purpose of this discussion we will only focus on type A and type NS records. A type A record is the IP address of a given URL. When we ask for the IP address of the DNS server will respond with an A record that has this information [5]. Page 6 of 18

7 An A record is what is returned when the server actually knows the address of what we are looking for. In cases where the server doesn t know directly about the address we are requesting it might respond with an NS record. A type NS record is what is returned when a server doesn t know directly about what we are requesting. Essentially it s a referral to a different server that might have more information. The NS record has the name of servers that might have further information. It also has what is called glue information which is the associated IP address of any referred server name. If the server returns just the domain name of another server it s likely that the requesting server may have to look that IP address up as well. So as a convenience the IP address of the referred server is also provided so that the requesting server can contact it directly [5]. A typical DNS lookup Let us follow the path of a typical DNS request. 1. A client issues a request to connect to by asking the local DNS for the location. If the local DNS server knows the location it supplies it and that s the end of the interaction with the DNS server for this request. 2. If the local DNS server doesn t know the location it has to look it up. What it will do first is send a request to its designated root server. It asks the root server if it knows the IP address of 3. The root server will respond that it does not know about but it does know about.com. It will respond with an NS record referring our server to Page 7 of 18

8 some top level domain servers that are responsible for the.com domain that might have more information. 4. Our requesting server now armed with the names and addresses of the.com servers will send the same request to each of them asking if they know the IP address of 5. Again, it is unlikely that any of these servers will know the whole address, but they will know about google.com. The responding server will send an NS record referring our server to a DNS server that handles the google.com domain. 6. With this information the requesting server will now ask the google.com DNS server for the IP address of This DNS server will know the IP address and will respond with an A record containing the appropriate IP address [5]. Caching for later When the IP address of a computer is not known to the local DNS server it requires a lot of work to resolve it as we see in the example above. If is a popular resource, and is accessed many times then this lookup needs to be performed very often. This is very time consuming, and inefficient. This is where the concept of caching comes in. When a DNS server goes through all of this work to resolve an IP address it will save the result in its cache. This way when a subsequent request is made for the same IP address the DNS server can simply check its cache rather than performing this costly lookup all over again [1]. Fresh data Page 8 of 18

9 Caching known IP address is a great timesaver that can eliminate unnecessary lookups and improve overall performance. However, there is a limit to this convenience. IP addresses change often and if this cached data is used perpetually it will eventually be out of date and point to the wrong resource. Because of this, cached data also has a Time To Live attribute associated with it. The Time To Live attribute is set by the authoritative server and allows DNS servers to recycle known data without letting it become outdated. The TTL can be anything from a few seconds to several weeks. As long as the cached data has not passed its TTL it can be reused by the DNS server for subsequent requests. When the TTL expires then any subsequent requests will need to be looked up [1]. Vulnerabilities of DNS DNS servers are extremely important to the proper functioning of the internet. Without DNS servers the internet would be like a road system without street signs. Computers would be unable to communicate with the resources that they are seeking to connect to. With such great responsibility it can be somewhat frightening how open DNS servers are. But after all, they have to be open by their very nature. If an attacker can subvert a DNS server then he can cause a lot of chaos and potentially a lot of damage. Phishing is a serious threat to people s personal information on the internet. One of the main mitigations to the threat of phishing is to avoid clicking links in s. Instead users are urged to type the name of the resource they want to reach in their browsers directly. We place a lot of faith in the fact that when we type in our web browsers that we will in fact arrive at Page 9 of 18

10 This is precisely why DNS cache poisoning is so dangerous. If an attacker can successfully poison a DNS cache he can assign any arbitrary IP address to Users trying to reach would then be unwittingly directed to the resource of the attacker s liking. The implications are staggering. Users can be sent to malicious websites or just randomly redirected away from their intended destination in an effort to cause chaos. This form of highly advanced phishing is cutely called pharming [4]. This has the soundings of a paranoid delusion. Unfortunately it s completely possible, probable, and in fact already done. In March of 2005 through the use of a cache poisoning attack people that were trying to access popular websites such as Google, EBay [3], CNN, and MSN were redirected to malicious sites that installed spyware on the victim computers [4]. Anatomy of a cache poisoning A Cache Poisoning attack is an attack where the attacker modifies the stored IP addresses in a DNS server cache. This causes all future requests to that DNS server for that resource to be sent to wherever the attacker chooses. To see how a cache poisoning attack works we need to revisit the DNS server request. When a DNS server doesn t know the IP address of a particular resource it sends a request to other DNS servers asking them about the resource. The DNS server attaches to this request a query ID sometimes called a transaction ID [5]. This ID serves as a signature for the request. When a response comes back to the requesting server, the server checks to make sure that the ID matches the ID that was sent with Page 10 of 18

11 the request. This serves two purposes. First it allows requests and responses to be associated to each other since after all a DNS server might be handling multiple requests concurrently. And second it helps prevent denial of service attacks. Since the DNS server will ignore all unsolicited responses it insulates itself from being flooded by pointless traffic [5]. Therefore if the attacker knows the query ID he can forge a reply to the DNS server, and if he can deliver his forged reply to the DNS server before the real reply arrives then the DNS server will accept it as being legitimate. That forged reply will then be forwarded back to the original requester and treated as a proper address. When the real reply finally arrives, the transaction has been closed with the arrival of the forged reply and the real reply is simply ignored as being unsolicited [5]. This is very much like a race. When a DNS server sends a request the attacker tries to beat the real reply with his forged one. But how does the attacker know what the query ID is, or when a DNS server is making a request? This requires a little bit of preparation before the actual attack. An attacker will set up his own domain and using the victim DNS server he will request access to a resource in his domain. Since the victim DNS server doesn t know about the attacker s domain, it needs to perform a lookup. That lookup request will eventually arrive at the attacker s domain s DNS server. The attacker s DNS server will oblige and reply to the request as expected, however at this point the attacker will also be able to see the query ID associated with the request. Now the attacker knows the victim DNS server s current query ID. Since many versions of DNS software use sequential query IDs or Page 11 of 18

12 easily predicted random IDs the attacker can predict what the query IDs will be in the near future. Now comes the real assault. The attacker makes a request to the victim server for a resource; let s say The victim server goes to perform the lookup and the attacker immediately begins flooding the victim DNS server with forged A record replies. The attacker doesn t know the exact query ID that the victim DNS server is using for this request, but he has a good idea from the preliminary work that he already performed. So the attacker sends many forged A record responses each signed with a different, but highly likely query ID. The victim DNS server will of course ignore the unsolicited replies, but if the attacker manages to guess the proper query ID before the real reply returns, then the victim DNS server will accept it. It will also cache the forged result for future use. Now the victim DNS server is poisoned. When any subsequent users try to access using the this DNS server they will be treated to whatever the attacker has placed into the victim DNS s cache [5]. Why isn t the security community panicked? This is the way in which a DNS cache poisoning attack goes down. The results are profound, but can this attack be effectively, reliably, and consistently pulled off? The answer is no, and for as long as DNS cache poisoning has been around it wasn t touted as a common threat. It s a theoretical nightmare, but a practical improbability. There are several problems with successfully executing this attack. The first problem is that there is a possibility that the attacker won t guess the proper query ID in time. If the real response comes back before the attacker can succeed then the attack is thwarted. Another problem is that once a lookup is performed the IP address is cached, so future Page 12 of 18

13 requests will be satisfied using cached data and not through DNS lookups. The attacker needs to know precisely when a cache entry TTL expires so that he can try to forge a request when the victim server has to perform a DNS lookup. This all requires perfect timing and incalculable amounts of luck. The scope of this attack is also quite limited. If in fact it succeeds as planned, the attack only poisons one IP address. The other IP addresses in that domain are still intact. So the net effect of the attack (if it even succeeds) are not terribly great [5]. So this is why we are not terribly worried about cache poisoning. Ok, now they re panicked! In 2008 Dan Kaminsky, renowned internet security expert, was researching improved methods of streaming video to users by modifying the way the associated DNS entries are treated. To his shock Kaminsky stumbled upon a new way that could yield the classic DNS cache poisoning attack much more effectively, much more reliably, much more readily, and with much greater reach. Keeping his discovery close to his chest Kaminsky worked closely with other security experts to quickly fashion a fix for his newly discovered threat which was deployed during the summer of 2008 [10]. A more toxic poison Kaminsky s discovery meant that DNS cache poisoning attacks could now be executed more reliably and with much more devastating effects. The classic DNS cache poisoning attack was limited because it had to be timed perfectly with the expiration of the TTL and, if successful, it could only affect one resource at a time [5]. Kaminsky discovered that he didn t have to wait for the TTL to expire on a cached entry. He was Page 13 of 18

14 able force a DNS server to perform a lookup at will. This meant that he could perform his attack any time and that he could repeat it as often as he liked in case of failure. He also discovered that he could take over an entire domain with one shot with his new attack whereas the classic version was only able to pick off one resource in a domain at a time [10]. The new attack is essentially the same as the classic DNS cache poisoning attack but with some minor modifications. Firstly the attacker needs to perform some preparation. The attacker needs to set up a fake authoritative DNS server for whatever domain he is trying to target, in this case our attacker is hoping to attack google.com. His creating a fake google.com DNS server is useless because all DNS servers will always point to the legitimate google.com DNS server and not his. His fake DNS server won t be seen by anyone (yet). We ll come back to the purpose of this fake DNS server later. The next issue is overcoming the TTL expiration. After all, if the cache entry is not expired then the server will not perform a lookup and will not offer the attacker a chance to be poisoned. This attack forces a lookup every time. The old attack targeted a specific resource such as It s very likely that will be cached therefore limiting the window of opportunity for the attacker. However, RandomThingThatDoesNotExist0001.google.com will not be cached because first, it does not exist, and second, no one is trying to access it. So with that in mind if the attacker requests to get the IP to that resource, the DNS server has no choice but to perform a DNS lookup. So now, just as with the classic attack the attacker floods the victim DNS server with forged replies. The difference is in what the response is. In the classic attack the response was a forged A record which is the IP address of a Page 14 of 18

15 particular resource. In this case, the forged reply is an NS record. An NS record is a referral to a different DNS name server for further resolution. In this case the forged NS record refers the victim DNS server to the attacker s fake google.com DNS server. The victim server will now use the attacker s fake google.com DNS server instead of the real one. When someone requests anything inside the google.com domain from this poisoned DNS server, they will be actually making requests to the attacker s fake google.com domain DNS server. As part of the forged NS record the attacker also sets a very long TTL so that the fake entry remains in the cache as long as possible before the DNS server performs another lookup resetting the entry to the legitimate google.com domain DNS server [10]. This is a devastating attack now. You can imagine how it can be taken a step higher to redirect all.com traffic or all.net traffic. In the hacker lexicon the attacker has just pwned the whole internet. Mitigation Short of changing the DNS server protocols there is not much that can be done to completely protect against this threat. The best solution currently available, and the one that was implemented by Kaminsky and colleagues this past summer was to increase the entropy in the way query IDs are generated and to also use more randomness in the communication port that is used. Typically DNS servers would exclusively operate on port 53. To thwart attackers, the port can be randomized making it more difficult for attackers to exploit this weakness [10]. Experiment Page 15 of 18

16 After learning about DNS cache poisoning and the recent developments in the way this attack can be carried out I became a little curious as to how susceptible my internet service provider s DNS server was to these threats. As a result I performed some informal tests using web based tools to check my DNS server, and here are the results. From Dan Kaminsky s website I tested my DNS server with the tool seen on the right. Based on the results of this test, my DNS server appears to be reasonably safe from DNS cache poisoning attacks. In addition to the above test I also wanted to compare the result against another tool. For this test I used the DNS Vulnerability Check tool found at seen below. The result of using this tool was not as reassuring as the previous. Curiously the tool yielded different results when the test was performed several times. On certain occasions it reported more problems than on other attempts. Since this test was performed for more of a curiosity than an actual analysis no further investigation was invested in identifying the different results. Page 16 of 18

17 Conclusion In conclusion there are many security threats on the internet, and one of the most frightening is DNS cache poisoning. If a DNS server is compromised then effectively the entire internet has been compromised for the affected user. Even though DNS server cache poisoning is not new and has been with us for a long time, we saw recently that it is not an old threat with nothing new to offer. The threat is alive and well, and may very well come back in the future with new threats. Page 17 of 18

18 Works Cited [1] "Domain Name System". Wikipedia. 06 Dec 2008 < [2] "Name Server". Wikipedia. 06 Dec 2008 < ver>. [3] Evers, J. (2005, August) DNS servers--an Internet Achilles' heel. CNET News. Retrieved December 6, 2008 from < [4] Evers, J. (2005, March). Phishers using DNS servers to lure victims? CNET News. Retrieved December 6, 2008 from < [5] Friedl, S. (2008) An Illustrated Guide to the Kaminsky DNS Vulnerability. Retrieved 06 Dec 2008 from < [6] ARPANET". Wikipedia. 06 Dec 2008 < [7] SRI International". Wikipedia. 06 Dec 2008 < [8] root-servers.org. 06 Dec 2008 < [9] Du, W. (2007) DNS Protocol and Attacks. Retrieved 06 Dec 2008 from < [10] Naone, Erica (2008, November). The Flaw at the Heart of the Internet. Technology Review, 111(6), Retrieved December 7, 2008, from ABI/INFORM Global database. Page 18 of 18