DNS Poisoning Attack

Posted by: Guowen May 5, 2013.

 

First to understand DNS Poisoning we first must have an understanding on how DNS works. DNS stands for Domain Name System; it’s used to resolve URL and company name queries on the internet to IP Addresses. So a user types in www.google.com the DNS sees the query and translates www.google.com to 152.62.24.254. Then the browser connects you to 152.62.64.254 and all you see in the URL is www.google.com. An authoritative DNS server is assigned to be responsible for their particular domains. Companies have multiple DNS servers to handle the amount of internal queries from their users shown in Figure 1. Now that we have a quick understanding on how DNS works we can now go over the DNS poisoning attack.

(Figure 1)

DNS poisoning is accomplished by the hacker gaining control over the desired authoritative DNS server. The hacker mainly needs to change or add records in the resolver cache so the DNS query from a user or a server can be translated to an IP address that is to be the hacker’s domain instead of the intended domain (Olzak, March 2006). Once the hacker has poisoned the DNS cache, the main risks is identity theft, distribution of malware, dissemination of false information, and man-in-the-middle attacks which will be covered later in this paper (March 2013).

History of DNS Poisoning use in real world attacks

Before one of the largest synchronized fix to the internet’s infrastructure of all time back in 2008 security researcher Dan Kaminsky helped work on the patch. There was a major problem with the current DNS systems. The transaction ID field which is one of the key pieces of information that a hacker needs to successfully poison a company’s DNS cache; the transaction ID field was updated to 16 bits (Dougherty, 2008).

The attack would require at least 32,728 attempts to successfully predict the ID. The previous versions used smaller number of bits for the transaction ID meaning fewer attempts by the hacker (Dougherty, 2008).  With this major security vulnerability over 98% of the internet was affected and just to name a few, “Apple Computer, Inc.Vulnerable 2008-05-05, AT&T Unknown 2008-04-21 Belkin, Inc.Unknown 2008-07-13, and Cisco Systems, Inc. Vulnerable2008-05-01” (Dougherty, 2008).

DNS Poisoning Dissected

Now we are going to take a look in depth on how DNS poisoning works. The first step in the attack is the hacker checks the resolver cache in the workstation to see if a resolution request to the DNS server is there. If there is no entry in the resolver cache then the hacker sends a resolution request to the DNS server (Olzak, March 2006). Now the DNS server receives the request and first checks to see if it’s the authoritative DNS server. If the DNS server is not authoritative the next procedure it will perform is to check its local cache and see if there is an entry for the authoritative DNS server (Olzak, March 2006). Now the server begins the process of interactively querying external DNS servers until it either resolves the domain name or reaches a point where it’s clear the domain entry does not exist (Olzak, March 2006).

The request is sent to internet root servers then the root server returns the address of the authoritative for the .com internet. Another request is then sent from the authoritative for .com and the address of the DNS server authoritative for the company domain is returned ( March 2013).

Another request is sent to the authoritative server for the company. This is the same query process with one exception; the hacker now wants to poison the DNS server’s cache. In order for the hacker to intercept a query and return malicious information, the hacker must know the 16 bit transaction ID (Olzak, March 2006). If the DNS server is running an out of date version of BIND, then the transaction ID becomes very predictable. But in newer DNS systems have built in safe guards, for instance the transaction ID for each query instance is randomized. To slow the response of the real authoritative server, the hacker uses a botnet to begin a DOS (Denial of Service) attack (Olzak, March 2006). Now the authoritative DNS server is trying to deal with the attack, the hackers DNS server has time to figure out the transaction ID. Once the ID is determined a query is sent to the internal DNS server but from the IP address of the hackers server ( March 2013).

The response is placed into the server’s cache, the rogue IP address from the hackers server is returned to the client resolver and any entry is made and a session is initiated with the attackers site. Now any workstation on the internal network requesting resolution to the company’s site will receive the rogue address listed in the DNS server’s cache. Now taking users to the hacker’s fake website so the hacker can steal information and distribute malware to the unsuspecting users ( March 2013). This scenario is depicted in Figure 2 with arbitrary names.

(Figure 2)

Review Risk and Mitigation for DNS Poising

The main risk if a company’s DNS server’s cache gets poisoned is unwanted distribution of malware, user information, identity theft, man in the middle attacks. Also any user on the internet that searches for their website will be redirected to the rogue DNS server resulting further damages. There is a very high risk of malware infections spreading to potentially infect a majority of a company’s computers. If a CEO logged into the rogue DNS server and did not realize it, then the hacker has executive rights to any data in the organization and can steal his identity. Companies need to have DNS; it’s too difficult for everyone to remember the IP address for every domain server and every website on the internet that also uses DNS.

To help mitigate this attack is to use the latest version of DNS. DNS based on BIND 9.8.x is far more secure than previous early versions of DNS. Physically separate external and internal DNS servers, restrict zone transfers to authorized devices, and use TSIG to digitally sign zone transfers and updates, restrict dynamic DNS updates, and hide the version of BIND being used on the DNS server.