In the world of the Internet and TCP/IP, IP addresses are used to route packets from source to destination. A single IP address, for example, 203.192.135.234, is not difficult to remember. But trying to learn or track thousands of these addresses, including which server/node is associated with each address, is a daunting task. So instead, we use domain names to refer to systems with which we want to communicate.
A real-world Internet domain name example is google.com. When you enter the Google domain name into the address bar of your browser, the Google page appears. This is because your PC executed a process to resolve google.com to an IP address. Only by having the IP address is a system able to initiate a session with another system across the Internet. Let‘s look at two ways IP address resolution can occur.
DNS Resolution Process
Figure 1 depicts the domain name/IP address resolution process when the target system and DNS server are internal. In this example, a workstation must establish a session with a server with a domain name of farpoint.company.com. In order for a workstation to implement DNS, it must be running a DNS Client or Client Resolver. The resolver initiates the following process, resulting in the conversion of the domain name to an IP address.
Figure 1
Step 1: The resolver checks the resolver cache in the workstation‘s memory to see if it contains an entry for Farpoint.company.com. The entry would be present if the workstation had resolved the name to an IP address since the last time it was powered on, and the Time to Live of the entry had not been exceeded. In this example, no entry is found.
Step 2: Having found no entry in the resolver cache, the resolver sends a resolution query to the internal DNS server.
Step 3: When the DNS server receives the query, it first checks to see if it‘s authoritative for the company.com domain. In other words, is it responsible for managing the zone in which the company.com domain resides? If it is, the server performs a lookup in its internal zone table. In this case, it finds a host Resource Record (RR) that includes the IP address for Farpoint.company.com.
Step 4: The IP address of Farpoint.company.com is returned to the resolver.
Step 5: The resolved domain name and IP address are placed into the resolver cache. Figure 2 is an actual listing of the contents of a workstation‘s resolver cache. The IP address is used to contact farpoint.
Figure 2
What is DNS Cache Poisoning?
DNS cache poisoning is a maliciously created or unintended situation that provides data to a Domain Name Server that did not originate from authoritative DNS sources. This can happen through improper software design, misconfiguration of name servers and maliciously designed scenarios exploiting the traditionally open-architecture of the DNS system. Once a DNS server has received such non-authentic data and caches it for future performance increase, it is considered poisoned, supplying the non-authentic data to the clients of the server. 9. DNS cache poisoning consists of changing or adding records in the resolver caches, either on the client or the server so that a DNS query for a domain returns an IP address for an attacker‘s domain instead of the intended domain. How this might work is shown in Figure 3
Step 1: The resolver checks the resolver cache in the workstation‘s memory to see if it contains an entry for farpoint.companyA.com.
Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.
Step 3: When the DNS server receives the request, it first checks to see if it‘s authoritative. In this case, it isn‘t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for farpoint.companyA.com exists. It doesn‘t. So in Step 4, the internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it‘s clear that the domain name entry doesn‘t exist.
Step 4: A request is sent to one of the Internet root servers. The root server returns the address of a server authoritative for the.COM Internet space.
Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the companyA.com domain is returned.
Step 6: A request is sent to the authoritative server for companyA.com. This is identical to the standard process for an iterative query – with one exception. A cracker has decided to poison the internal DNS server‘s cache. In order to intercept a query and return malicious information, the cracker must know the transaction ID. Once the transaction ID is known, the attacker‘s DNS server can respond as the authoritative server for companyA.com. Although this would be a simple matter with older DNS software (e.g. BIND 4 and earlier), newer DNS systems have built-in safeguards. In our example, the transaction ID used to identify each query instance is randomized. But figuring out the transaction ID is not impossible. All that‘s required is time. To slow the response of the real authoritative server, cracker uses a botnet to initiate a Denial of Service (DoS) attack. While the authoritative server struggles to deal with the attack, the attacker‘s DNS server has time to determine the transaction ID. Once the ID is determined, a query response is sent to the internal DNS server. But the IP address for farpoint.companyA.com in the response is actually the IP address of the attacker‘s site. The response is placed into the server‘s cache.
Step 7: The rogue IP address for Farpoint is returned to the client resolver. Step 8: An entry is made in the resolver cache, and a session is initiated with the attacker‘s site. At this point, both the workstation‘s cache and the internal DNS server‘s cache are poisoned. Any workstation on the internal network requesting resolution of Farpoint.companyA.com will receive the rogue address listed in the internal DNS server‘s cache. This continues until the entry is deleted.
Another method used to poison a DNS cache is the use of a recursive query sent by the attacker. The query can force the target server to connect to the authoritative source of the domain in the query. Once connected, rogue information about one or more domains might be sent to the querying server and posted to the server‘s cache.
Potential Consequences of Cache Poisoning
The following are the consequences of using a poisoned DNS cache:-
(a) Pharming. This is the primary risk associated with cache poisoning. Crackers employ pharming for four primary reasons namely identity theft, distribution of malware, dissemination of false information, and man-in-the-middle attacks.
(b) Identity Theft. Once an attacker gets you to his site, he‘ll try to trick you into leaving behind information he can use to impersonate you. One way to do this in the first example is to create a site identical to the real Farpoint.companyA.com. When the user connects using the poisoned cache information, he might be fooled into entering information about himself through apparently legitimate requests for his name, address, etc.
(c) Distribution of Malware. Another objective of attackers using cache poisoning is the automatic distribution of malware. Instead of releasing malicious code into the Internet and realizing random results, the use of rogue IP addresses to redirect unsuspecting users to the attacker‘s site can be a more focused attack vector. Once a workstation initiates a session with the malicious site, malware is uploaded to the workstation without intervention by or the knowledge of the user.
(d) Dissemination of False Information. This aspect of pharming is useful to attackers who want to spread self-serving information about an organization.
(e) Man-in-the-middle Attack. In this attack type, the workstation initiates a session with the attacker‘s server. The attacker‘s server initiates a session with the actual target site. All information flowing between the workstation and the genuine site passes through and is intercepted by the cracker‘s server.
There can be serious consequences when security is an afterthought during the configuration and deployment of DNS servers. The next section provides guidelines that can help prevent cache poisoning.
Cache Poisoning Attacks
Normally, an Internet-connected computer uses a DNS server provided by the computer owner's Internet Service Provider or ISP. This DNS server generally serves the ISP's own customers only and contains a small amount of DNS information cached by previous users of the server. A poisoning attack on a single ISP DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable. The analogy is applicable to the intranet also. To perform a cache poisoning attack, the attacker exploits a flaw in the Domain Name Server software that can make it accept incorrect information. If the server does not correctly validate DNS responses to ensure that they have come from an authoritative source, the server will end up caching the incorrect entries locally and serve them to users that make the same request. This technique can be used to replace arbitrary content for a set of victims with the content of an attacker's choosing. For example, an attacker poisons the IP address DNS entries for a target website on a given DNS server, replacing them with the IP address of a server he controls. Then the attacker creates fake entries for files on the server they control with names matching those on the target server. These files could contain malicious content, such as a worm or a virus. A user whose computer has referenced the poisoned DNS server would be tricked into thinking that the content comes from the target server and unknowingly download malicious content.
Variants
In the following variants, the entries for the server ns.mywebsite.org would be poisoned and redirected to the attacker's nameserver at IP address w.x.y.z. These attacks assume that the nameserver for mywebsite.org is ns.mywebsite.org. To accomplish the attacks, the attacker must force the target DNS server to make a request for a domain controlled by one of the attacker's nameservers.
Redirect the Target Domain's Nameserver
The first variant of DNS cache poisoning involves redirecting the nameserver of the attacker's domain to the nameserver of the target domain, then assigning that nameserver an IP address specified by the attacker.
DNS server's request: what are the address records for subdomain.example.com?
subdomain.example.com. IN A
Attacker's response:
Answer:
(no response)
Authority section:
example.com. 3600 IN NS ns.mywebsite.org.
Additional section:
ns.mywebsite.org. IN A w.x.y.z
Responding Before the Real Nameserver
The third variant of DNS cache poisoning, which is called DNS Forgery, involves beating the real answer to a recursive DNS query back to the DNS server. DNS requests contain a 16-bit nonce, used to identify the response associated with a given request. If the attacker can successfully predict the value of the nonce and return a reply first, the server will accept the attacker's response as valid. If the server randomizes the source port of the request, the attack may become more difficult, as the fake response must be sent to the same port that the request originated from.
By sending a number of simultaneous DNS requests to the server to force it to send more recursive requests, the probability of successfully predicting one of the request nonces increases.
Steps for DNS Protection
The first layer of defense against cache poisoning is the use of the latest version of DNS. DNS based on BIND 9.3.x or Microsoft Windows Server 2003 is far more secure than DNS implemented with earlier versions. Successful completion of the first poisoning example would have been more difficult because these systems also randomize the port used for the DNS query in addition to the transaction ID.
Recursive queries should be limited to internal DNS servers. If Internet-facing recursive queries are required, only queries from internal addresses should be accepted. This will help prevent outside systems from sending queries with malicious intent. The following steps provide additional guidance:- (a) Physically separate external and internal DNS servers. (b) Restrict zone transfers to authorized (secondary servers) devices. (c) Use TSIG to digitally sign zone transfers and zone updates – one of the best ways to prevent poisoning is to force identification of the sending authoritative source. (d) Restrict dynamic DNS updates when possible. (e) Hide the version of BIND being used on the DNS servers. (f) Remove unnecessary services running on the DNS servers. (g) Where possible, use dedicated appliances instead of multi-purpose servers.
Prevention and Mitigation
Many cache poisoning attacks can be simply prevented by DNS servers being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back which are not directly relevant to the query. For example, recent versions of BIND now contain code that performs these checks. As stated above, source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit nonce, can greatly reduce the probability of successful DNS race attacks. A secure version of DNS, DNSSEC, uses cryptographic electronic signatures signed with a trusted digital certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks, but as of 2008 is not widely deployed.
This kind of attack may also be mitigated at the transport layer or application layer to perform end-to-end validation once a connection is set up to an endpoint. A common example of this is the use of Transport Layer Security and digital signatures. For example, by using the secure version of HTTP, HTTPS, users may check whether the server‘s digital certificate is valid and belongs to a website‘s expected owner. Similarly, the SSH remote login program checks digital certificates at endpoints (if known) before proceeding with the session. For applications that download updates automatically, the application can embed a copy of the data‘s signing certificate locally and validate the signature stored in the software update against the embedded certificate.
Conclusion
DNS cache poisoning is a large risk for organizations running early versions of DNS solutions. The elevated risk extends to organizations that carelessly deploy DNS, regardless of the DNS software version used. Careful attention to version management and the secure configuration of DNS devices should reduce risk from cache poisoning to an acceptable level.
