Technical Brief V2.0

How to Detect DNS Cache Poisoning Using Peakflow SP

Overview

In July of 2008, a security researcher named Dan Kaminsky(1) of IOActive, Inc discovered a new vulnerability in the DNS protocol that could be exploited via an attack known as “DNS Cache Poisoning”. Mr. Kaminsky and his team proceeded to notifying key DNS vendors and operators of this new vulnerability(4). When patches were made public in early summer of 2008 they were distributed with minimal background information. This set off the flurry of analysis and the eventual leakage of the attack vector to the public. Much media attention was garnished(5,6), and a much broader worldwide DNS server patching exercise commenced(7) . But this is not the end of the story. The recommended “patch” is not a fix, but merely a way to slow down a successful DNS Cache Poison attack from hours to days. As a result much has been written about the new vulnerability, specifically from members of Arbor Networks’ ASERT(2,3). There will most certainly be more written until an actual fix can be found. In the meantime, companies like Arbor Networks will continue to offer products and services that will assist customers in detecting and mitigating DNS Threats. This document will provide a brief overview of the new DNS Cache Poisoning exploit and how Arbor’s Peakflow SP solution can be used to detect and potentially stop this type of attack.

Brief DNS Primer DNS is a hierarchical technology relying on both the advantages of the a distributed system to scale to the size of the Internet today as well as provide a resilient, fault tolerant mechanism to translate canonical resource addresses (e.g. www.example.com ) to Internet Protocol (IP) addresses.

Fig. 1

All applications that recognize Uniform Resource Locators (URLs) or Uniform Resource Identifiers (URIs) rely on the accuracy and validity of the DNS records to properly translate canonical addresses to the IP address locations of content. DNS relies on a client - server model of communication. Each time any application needs to map a canonical name (See Figure 1) to a machine IP address or its reverse mapping, that system makes a client request to its local Domain Name Server (some

times referred to as a DNS Resolver). If the local DNS Resolver has the answer to this question, it will respond directly to the requesting client with the answer either an IP address or with the reverse mapping of a name. However if the local DNS server does not know the answer locally, it will begin a series of recursive requests to search out the answer requested by the client. The local server, not having an answer to a request in its local cache of answers, will first try to decipher what system is the known DNS authority to answer the question. For example, let’s look at a request from a client looking to browse to an online resource known as www.example.com. The local DNS Resolver will first attempt to answer the request with the IP address of www.example.com. If this answer is not available to it in its local DNS cache, then the local DNS Resolver will next attempt to resolve what DNS name server (known as the DNS Authoritative Server) has the authoritative answer for example.com. If this is not known, then the local DNS server will look deeper into the DNS name tree to find the DNS name server for .com. The .com DNS Authoritative server will provide an answer to the local DNS Resolver for the address of example.com DNS Authoritative server. The local Resolver then has an IP address to send its original request searching for the address of the www.example.com server. The authoritative domain server for example.com will provide an answer for the address of www.example.com. (See Fig. 2) The messages between the local DNS Resolver and the DNS Authoritative system originate on a source port from the Resolver and contain a transaction ID to identify the requests received from the authority. With this transaction ID the Resolver will be ensured that the outstanding requests have actually been answered. It’s this combination of the source port and transaction ID which is

the vulnerable part of the DNS protocol and is exploited by the DNS Cache Poisoning attack. This next section will describe how this attack exploits the source port and transaction ID vulnerability.

Brief Explanation of DNS Cache Poisoning DNS cache poisoning attempts to replace valid records on a DNS server with incorrect IP addresses in an attempt to seamlessly redirect client systems to locations that masquerade as legitimate resources on the Internet. With the DNS server “poisoned” with an incorrect IP address to name mapping, the hacker can leverage a number of vectors to infect or gather data from the innocent, redirected client. Transaction ID Race and TTL The DNS Cache Poison attack is not new. In 1997, CERT released advisory CA-1997-22, describing a vulnerability in BIND (Berkeley Internet Name Domain) software which is used by the majority of the name servers on the Internet. This time a very basic principle was finally realized: BIND did not randomize the source ports of its requests, instead it used the same source port for each request and only relied on the Transaction ID to differentiate outstanding requests. Aside from layer 3 and 4 protocol checking (source and destination IP addresses and ports must match), the transaction ID is the sole form of authentication for a DNS reply. Because an attacker was only tasked in guessing the next transaction ID after making their own request, a cache poisoning attack could be carried out using a spoofed query followed by a spoofed answer. In essence the attacker was racing the authoritative DNS server to respond to the DNS Resolver with a matching transaction ID. (see Fig 3) If the attacker won the race, they would “poison” the DNS cache with a bogus DNS entry - which the attacker could then exploit.

Fig. 3

To solve this, all new versions of BIND were updated to use randomized 16 bit transaction IDs and a range of port numbers(0-65535). This made it harder for an attacker to match the correct port/ transaction ID combination, but still not impossible. More over, in DNS wrong answers are simply silently discarded and as such the attacking system can send as many guesses to the Transaction ID (TXID) value as possible before the real answer is received by the resolver from the true DNS authoritative server. If the attacking system is unsuccessful in guessing the answer before the true authority actually responds with the right answer, and correct TXID, then the answer record is cached in the resolver for a period of time determined by the Time To Live (TTL) value. The TTL is not a security feature, but rather a mechanism to reduce the overhead of the distributed DNS system. Common TTLs are set for 24 hours, meaning that any record’s data is deemed valid for a period of 24 hours following its last update. The TTL function therefore will reduce the need for the Resolving DNS system to further query the Authoritative DNS server for the duration of the TTL. Therefore any attacker who fails to guess a port / transaction ID combination before the real authoritative system responds will simply have to wait for 24 hours, or the length of the TTL, before attempting an attack on that record again. This may slow down an attack on a particular record but certainly does not secure this record from future poisoning attempts. In fact if the record or DNS zone is valuable enough, the attacking system will simply generate false records in order to force the Resolver to open its request to an authoritative system. DNS Pointer Record Writing/Overwriting The TTL does add some suppression of any particular name record from being exposed to continuous bombardment of poisoning attempts. However, as stated above, TTL is not a security mechanism nor is it something that would prevent this attack from being leveraged against non-existent domains or from repeated attempts after the TTL expires. In other words, the TTL function does not limit the ability of the attacker to create their own list of bogus domains which creates a huge number of opportunities for the attacker to force the Resolver to open their request and inject one or more poisoned DNS Pointer records, otherwise known as DNS Pointer Record Writing/Overwriting. Let’s look at how an attacker could conduct a DNS Cache Poison attack using the DNS Pointer Recording Writing/Overwriting exploit. In the example below, let’s assume the attacker wants to poison the example.com domain name. The attack would work as follows (see Fig 4).

1) The attacking system asks the Resolver for the answer to a bogus domain name such as pork.example.com, milk.example.com etc.

2) The Resolver, not knowing the answer for this FQDN, opens its own request to the upstream DNS Authoritative Server for pork.example.com.

3) The attacking system then issues a series of attempts to answer the Resolver with a correct TXID for pork.example.com. All of these attempts use the poisoned answer record of pork.example.com and a second poisoned DNS pointer record update for the bogus address of the authoritative DNS server of the domain example.com.

Fig. 4

3a-3b) When the TXID is correct for the Resolver’s session for pork.example.com, the additional pointer records contained in the response are injected into the Resolver’s DNS cache - one of them being the poisoned address of the Authoritative server for the entire domain of example.com. This is what’s known as “DNS Pointer Recording Writing/Overwriting”.

In addition, the message contains a high value TTL. This allows the attacker to retain control of the poisoned DNS cache for a longer duration of time and control the TTL Refresh rate in an attempt to maintain control of the poisoned domain or record. A good example of the fact that the TTL is not a security measure as it begins to work against the legitimate Authoritative DNS system in regaining control of the domain example.com. The Resolver then answers the original question from the attacker of “where’s pork.example.com?” This provides the attacker validation that the attempts were successful and now the domains pork.example.com, example.com and milk.example.com are now cached on that Resolver – in other words the primary target domain of example.com is now poisoned on that Resolver. The attacker now owns this domain for all clients who contact that Resolver for DNS services. 4-6) From now on, when any client asks the Resolver for example.com, the Resolver will provide a response from it’s poisoned DNS cache. (example.com =1.2.3.2) and the attacker executes their attack vector. (e.g. Pharming)

What exactly did Dan Kaminsky’s discovery? Dan Kaminsky didn’t find a new vulnerability in DNS. As noted previously, failure to randomize 16 bit transaction IDs and the range of port numbers (0-65535) is a known, major DNS server configuration error that exposes the server to this exploit. Dan Kaminsky discovered how an attacker could exploit this vulnerability further by using DNS Pointer Record Writing/Overwriting. With the understanding of the use of Pointer records, Kaminsky was able to demonstrate that:

1) It’s easier to poison than was originally thought. 2) The DNS Resolver server will happily update with arbitrary information even if it has the

answer. 3) You can use this acceptance to introduce new mappings via “glue records” and poison far more than just the one request. In other words not only could an attacker grab a single FQDN, but they could also grab a Registered Domain (RD) such as example.com.

Mr. Kaminsky tried to do the right thing by working with multiple DNS vendors on a patch. But when word leaked out, a patching frenzy ensued around the world, much of it fueled by the media. In reality, the patch simply checks to see if the 16 bit transaction IDs and the range of port numbers are randomized. If they aren’t, the patch enables randomization. In other words, the patch doesn’t fix the problem, but simply slows down a potential hacker. To make matters worse, there have been some instances of environments utilizing port address translation (PAT), which may actually undo the effects of the DNS patches.

So the question remains.… “ If there is no fix for this vulnerability, how do you detect if your DNS system is being tampered with or has been a victim of a DNS Cache Poison attack?” There are two answers to this question. The first is a short term answer and second is the long term fix to this situation. The first answer is to use Peakflow SP to help detect and alert when DNS records come under poisoning attempts and attacks by malicious systems on the Internet. This is something that Peakflow SP and TMS can provide specific and actionable data to discover and block attackers attempting to poison DNS records. Fortunately there are tell tale signs that you can look for. The next section of this document will describe exactly how Arbor’s Peakflow SP products can be used to detect a DNS Cache Poison attack. The second is the long-term approach of using DNS-SEC(8) on Authoritative and Resolving Systems to ensure that the response of the Authoritative system is authenticated through a chain of trust. Without this capability, the DNS systems remain vulnerable to poisoning attempts and hijacks of domains through the methods described above. However it is clear that the scope of deploying and building authenticated trust chains in the DNS infrastructure is not something that is likely to happen overnight. Therefore detection and mitigation solutions should play a roll in this second, long term step to protect Resolving and Authoritative systems from poisoning attacks while DNS-SEC becomes more widely deployed and adopted.

How to detect a DNS Cache Poison Attack Using the Arbor Peakflow SP Solution The Peakflow SP solution leverages multiple types of data sources on the network. These data sources can be put into two major groups.

1) Information from IP Flow (e.g. NetFlow, sFlow), SNMP and BGP. This information enables broad, cost effective network visibility, distributed threat detection (i.e DDoS or DNS attacks) and mitigation.

2) Network packets. More specifically, the Peakflow SP Threat Management System

(TMS) analyzes network packets to detect and surgically mitigate application layer attack traffic. By leveraging both major groups of data, the Peakflow SP solution enables cost effective, broad visibility into network and routing traffic, infrastructure security and can simultaneously serve as a platform for in-cloud managed security services (i.e DDOS or DNS Protection services)

The Peakflow SP solution has the capability to detect many different types of network or service threats, but for the purposes of this document, we’ll describe how the Peakflow SP solution can be used to detect and help mitigate a DNS Cache Poison attack. Two Network Locations for Detection There are two locations in the network where you can detect a DNS Cache Poison attack using the Peakflow SP solution.

Fig. 5

Location #1: In front of DNS Resolvers. (See Fig 5) If you are the owner of one or more DNS Resolvers you can detect high rates of DNS answer records (i.e Poisoning Attempts against a FQDN or non-existent FQDN) Poisoning attempts require the attacking system to issue a single request for a Fully Qualified Domain Name (FQDN) to a resolving server and then follow that request with a flood of poisoned answers each attempting to guess the Transaction ID of the recursive request to the Authoritative system. This is the race condition previously explained and could be seen as a large spike of DNS Responses coming into the Resolver.

Each of these responses may or may not be sourced from the same IP address (likely they will not be, but they all will constitute a total aggregate larger volume of traffic into the resolving system.) Location #2: Between a DNS Resolver and DNS Authoritative Sever. (see Fig. 6) There you can see the backscatter from your domain’s Authoritative server to DNS Resolvers as a flurry of ICMP type 3 (Destination Unreachable) code 3(port unreachable) error messages. Unfortunately this means that the attacker has most likely succeeded in his attempt to poison the DNS cache of the Resolver.

Fig. 6

Note: You will not be able to see these messages if there are more than one level of DNS Resolvers. (see Fig. 7)

Fig. 7

Configuring Peakflow SP to look for DNS Cache Poisoning Attempts In front of DNS Resolvers(Location #1) In this scenario you can use the Peakflow SP solution in front of the DNS Resolvers to detect an abnormally high rate (as compared to your network’s normal rate) of DNS answer records which is indicative of an attacker’s poisoning attempts against a FQDN or non-existent FQDN. You have two Peakflow SP product deployment options.

Option #1) Your first option is to rely solely upon IP flow data and simply use a Peakflow CP device. Option #2) Your second option is to use a Peakflow SP TMS device in combination with Peakflow CP device to analyze packets (i.e from a SPAN/mirror).

Deployment Option #1: Configuring Peakflow SP for use with IP Flow Data For this scenario create a Profile Managed Object configured as follows:

Step 1: Create a proper description. For example: “DNS Cache Poisoning Attempts: This managed object will look for a high rate of DNS A record requests. Monitor router interfaces that see the traffic to and from a DNS Resolver”

Step 2: Configure a Match for: Match 1 = CIDR block of DNS Resolver server

Now you have two options to consider. Option #1: You can create a 2nd Match using a Flow Filter. For example: Match 2 = Flow filter Use Finger Print Wizard to configure: DNS traffic on port 53 using both TCP and UDP.

This second match is useful if your DNS Resolver server may have large bursts of other traffic, for example when backups run. These bursts of traffic will be excluding from the traffic baselines. Option #2: You can stop here and not create a 2nd Match. If you do not create a 2nd match, Peakflow SP will track all traffic to the DNS Resolver IP, not only the DNS traffic on UDP and TCP ports.

Fig. 9

Step 3: Next you will configure Detection settings. This will depended upon how you configured your Match settings above. In both cases you enable Profile and Misuse Detection. 3a. Profile Configuration Enable Automatic Rate Calculation(see Fig 9) 3b. Configuring Misuse Detection If you chose to create a Flow Filter using Option #1 above, configure Misuse Detection on Total Traffic Flow. This will look for the total PPS and BPS of DNS traffic to your DNS Resolver.

If you chose to skip the Flow Filter using Option #2 above, configure Misuse Detection on DNS. This will match port 53 traffic on UDP or TCP.

Step 4: After you have configured and saved all your settings for your managed object, make sure hit the CONFIG COMMIT button. Deployment Option #2: Configuring Peakflow SP Threat Management System (TMS) In this section we’ll describe how you can use Peakflow SP Threat Management System (TMS) device and packets to detect a DNS Cache Poison attack. To begin, follow the same Steps 1-3 as noted above in Detecting DNS Cache Poison attacks using Peakflow SP and IP Flow Data. Step 4: Select the Mitigation tab and configure the DNS Flood Protection User Initiated Template. Your DNS Flood Protection Template should be configured as follows: 4a. Change description as you wish. 4b. Disable everything except for DNS Mitigations and Zombie Removal Countermeasures.

Note: Other TMS mitigation infrastructure configurations are not covered in this document and should be discussed with an Arbor Networks Consulting Engineer. Step 5: After you have configured and saved all your settings for your managed object, make sure hit the CONFIG COMMIT button.

Using Peakflow SP to Look for Backscatter Caused By a Successful DNS Cache Poisoning In between Authoritative Server and DNS Resolvers (Location #2) The Peakflow SP solution could be used to monitor the router interfaces between an Authoritative DNS Server and the DNS Resolver(s). Detecting the presence of backscatter traffic between the Authoritative Server and the DNS Resolver is another indication that there is an attempt to poison a domain or domains located on the Authoritative Server. These side effects will manifest themselves as a high rate of backscatter from your domain’s Authoritative server to DNS Resolvers in the form of ICMP type 3 (Destination Unreachable) code 3(port unreachable) error messages. You have two Peakflow SP product deployment options.

Option #1) Your first option is to rely solely upon IP flow data and simply use a Peakflow CP device.

Option #2) Your second option is to use a Peakflow SP TMS device in combination with Peakflow CP device to analyze packets (i.e from a SPAN/mirror). In this case, not only would you be looking for the same DNS Cache Poison side effects, but you’d also have the ability to track much more information regarding DNS traffic.

Deployment Option #1: Configuring Peakflow SP for use with IP Flow Data For this scenario create a Profile Managed Object configured as follows: Step 1: Create a proper description. For example: “DNS Cache Poisoning Backscatter: Large volume of ICMP Error code traffic that indicates downstream cache poisoning ”

Step 2: Configure a Match for: Match 1 = CIDR block of DNS Authoritative server

AND Match 2 = Flow filter Use Finger Print Wizard to configure: ICMP Type = ICMP-UNREACH ICMP Code = 3

Step 3: Next you will configure Detection settings. Enable Misuse Detection. Disable all misuse detection except for Total Traffic. In the example, the traffic rates are intentionally set very low to show that you will need to adjust traffic rates according to your network environment. There aren’t any mitigation configuration options for this managed object as the objective is to detect signs of an already poisoned DNS Resolver. Step 4: Don’t forget to save and apply your changes by hitting the CONFIG COMMIT button.

Deployment Option #2: Configuring Peakflow SP Threat Management System (TMS) In this section we’ll describe how you can use Peakflow SP Threat Management System (TMS) device and packets to detect a DNS Cache Poison attack. To begin, follow the same Steps 1-3 as noted above in Detecting DNS Cache Poison attacks using Peakflow SP and IP Flow Data. For this scenario create a Profile Managed Object configured as follows:

Step 4: Create a proper description. For example: “DNS Cache Poisoning Backscatter TMS: Catch Backscatter from a DNS Resolver to my Authoritative DNS Server via the TMS span port generating flow.”

Step 5: Configure a Match for: Match 1 = CIDR block of DNS Authoritative server

AND Match 2 = Flow filter

Use Finger Print Wizard to configure: ICMP Type = ICMP-UNREACH ICMP Code = 3

Step 6: Configure a Boundary for: The TMS port that is attached to a SPAN/Mirror port on a router receiving packets.

Since the Peakflow SP TMS devices conducts deep packet inspection, you can also enable other Actions such as “DNS” to gather other DNS related information for analysis and reporting purposes. Note: There aren’t any mitigation configuration options for this managed object as the objective is to detect signs of an already poisoned DNS Resolver. Step 7: Don’t forget to save and apply your changes by hitting the CONFIG COMMIT button. Conclusion Millions of people and businesses depend upon the DNS infrastructure for world wide Internet communication. Unfortunately this service, like many others, is vulnerable to exploits like DNC Cache Poison attacks. This paper has tried to educate you on the basics of DNS, the latest regarding the DNS Cache Poison attack and ways you can use the Peakflow SP solution to detect and possibly protect yourself from a compromised DNS infrastructure. But as we have mentioned, the recommended patches and detection methods are not a fix for the problem, but merely ways to deal with the known vulnerability. The recommended long term fix is to deploy DNS-SEC, but this is much easier said than done. In the meantime expect more rely upon Internet security experts like Arbor Networks to help protect you and your organizations from further DNS exploits. For more information regarding the Peakflow SP solution or DNS Cache Poison exploit mentioned in this documents visit our website at www.arbor.net or Blog at http://asert.arbornetworks.com/

Online Resources 1) Dan Kaminsky Vulnerability Research Blog http://www.doxpara.com/?p=1162 2) ASERT Blog – Danny McPherson http://asert.arbornetworks.com/2008/07/30-day-of-dns-attack-activity/http://asert.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/ 3) ASERT Blog – Jose Nazario http://asert.arbornetworks.com/2008/07/dns-updates-the-cat-a-now-empty-bag-and-poison/http://asert.arbornetworks.com/2008/07/267/ 4) US-CERT VU#800113 http://www.kb.cert.org/vuls/id/800113 5) Wall Street Journal Online http://online.wsj.com/article/SB121557348238938533.html 6) BBC News Online http://news.bbc.co.uk/2/hi/technology/7496735.stm 7) Visualization of DNS Patch http://www.youtube.com/watch?v=cRVMrV_ZE6A 8) DNS Security Extensions (DNS-SEC) http://www.dnssec.net/