 In this set of slides, we will look into cache poisoning attacks. In the introduction, we have seen the typical name resolution process. In practice, for efficiency reasons and to keep the number of DNS messages on the Internet lower, only part of this process might take place. Resolvers have a local cache of recently retrieved records that is used to answer frequent queries. Imagine students in a campus dormitory all accessing Facebook. It would be a waste of time and resources to resolve Facebook.com for each one of those requests. The result of this query can be served directly from the local resolver cache. However, caches are subject to aging, meaning that an entry, even when it is frequently requested, cannot reside in cache forever. Otherwise, the local resolver might miss updates to the record. DNS avoid aging by using a time-to-live field, or TTL, which gives an upper bound to the validity of a cache record. Once the TTL is expired, the resolution process needs to be repeated. Cache poisoning attacks aim at corrupting the information in the caches. Let's look to a first variant of a cache poisoning attack. In the past, alternative name servers could send, together with their request resource record, also so-called additional action with external information. The additional action could contain, for example, a resource record for a domain not related to the one that was requested. Let's see how this work. Assume that a malicious host issues a query for doblot.eckers.com, a forged domain. The local resolver will ask the authoritative name server of Eckers.com the a record for doblot.eckers.com. The malicious-alternative-the-name-server answers with the IP addresses of ...acres.com and an additional section containing a fake A record for another domain, say ..example.com. The local resolver will then cache both the information about ..acres.com and information about ..example.com. From this moment on, the cache of the local resolver stores unverified information. This means that all queries to ...example.com will now be redirected to a possibly malicious IP address. This issue has been solved by introducing the so-called Bayley-Wick Check, meaning that the local resolver checks that the additional section only contains information about the same domain as the requested one. If this measure is in place, the local resolver will ignore the update about ...example.com because it was carried into a reply related to ...acres.com. Let's now see another way of implementing a cache poisoning attack. Let's assume, in this case, that a legit host issues a query for ..example.com. Eventually, the local resolver will receive a reply from the authoritative-name-server for ..example.com. As we know, this answer will be cached by the local resolver for possible later use. Let's assume now that an attacker succeeds in forging a fake DNS reply for ..example.com. If the local resolver is fully intercepting the answer, it will cache the malicious mapping, and this is another instance of cache poisoning. Two aspects are key here. One, this is a timing attack. The attacker needs to be faster than the legit answer. Two, the forged answer needs to be well-formed to be accepted. To understand how this can happen, we need first to know when a local resolver accepted the DNS answer. A resolver implements the following mechanism to accept a response. An answer is accepted if the UDP port is the expected one. If this is actually an answer for a request we issued. If the answer has the right query ID, which is a field used for matching requests to replies. And last, if additional data are present, those must be related to the domain of the request. With this mechanism in place, how is then cache poisoning still possible? Cache poisoning is harder, but not impossible. Clearly, there is quite some guessing to be done from the attacker's side. Think about the UDP port and query ID, and the malicious answer needs to arrive at the right time as well. Let's rework our example in more detail. First of all, the malicious host can prompt a query about the domain it wants to poison. In this way, the attacker gains an advantage, because it does not need to guess a query. While the local resolver goes through the resolution process, the attacker has time to brute-force the query ID. The port number is often not a problem for the attacker, since it is often the same for all queries from the local resolver. Things were even easier in the past when resolver incremented the query ID by one for each request. If the attacker knew one valid query ID, it could simply brute-force a range of query, close of the initial value, and wait until its answer could eventually be accepted. This points us to a first observation on how to mitigate such attacks. Randomization of the query ID can get you a long way in making the guessing harder. It does not solve the attack, though. Let's see more. Let's add even more details to our example. This version of cache poisoning attacks was discovered in 2008 by Dan Kaminski, and it is considered one of the biggest vulnerabilities in DNS seen so far. These attacks require more preparation from the attacker side, but the gain makes it worth it. Let's assume the attacker has set up an authoritative name server for the target domain. This is allowed in DNS, because if everything works okay, queries for the domainexample.com will be asked only to the legitimate authoritative name server. This assumption is actually the problem. As in the previous version, the attacker prompts the resolution process. However, this time it does so for a random cell domain of example.com. This has two advantages. First, a random cell domain is unlikely to be already in the cache. And second, if the attacker does not guess the answer parameters in time, it can try again with another random cell domain. Again, as in the previous case, the attacker brute forces the answer hoping it gets accepted. The crucial difference in these attacks is in the content of the forge answer. The attacker can use the additional section of the answer to delegate the resolution process to another server. In this case, the malicious authoritative name server. If this query is accepted, the attacker captures the entire domain because from that moment on, any query to a subdomain of example.com will be answered by the malicious authoritative name server. If you're now asking yourself how the situation can be solved, a few considerations are important. First, as first response once the attack has been discovered, the resolver port has been randomized. Together with the query ID randomization, this blows up the number of tries an attacker should make to now guess both a random query ID and a random port. In theory, this should solve the issues. A study conducted at the University of Amsterdam has looked into how the query ID and the ports are distributed in real DNS traces. The scatter plot on the right based on data collected at one of the authoritative name server in surfnet shows that there is a good degree of randomization of those two elements. However, the picture also shows that some patterns can occasionally emerge like horizontal or vertical lines or higher density zones. This suggests that although the mechanisms for randomization are in place, they can occasionally not be used or there might be occasionally less entropy than we think. Let's now wrap up with two more considerations about mitigation. First, although we have not said it explicitly, the last two examples of cache poisoning attacks works because the attacker is able to spoof the IP of the authoritative name server. Blocking spoofing is therefore also part of the solution. Second and last, a considerable effort has been put into developing DNSSEC, which allows the resolver to authenticate the answers, therefore checking if they really are generated from the legitimate authoritative name server.