DNS cache poisoning

From Wikipedia, the free encyclopedia

DNS cache poisoning is a technique that tricks a Domain Name Server (DNS server) into believing it has received authentic information when, in reality, it has not. Once the DNS server has been poisoned, the information is generally cached for a while, spreading the effect of the attack to the users of the server.

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.

Contents

[edit] Details

To perform a cache poisoning attack, the attacker exploits a flaw in the DNS (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 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. He then 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.

As part of the Golden Shield Project, China regularly engages in DNS Poisoning for particular sites or networks which violate the policies that the project operates under. [1]

[edit] Variants

In the following variants, the entries for the server ns.wikipedia.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 wikipedia.org is ns.wikipedia.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.

[edit] 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.wikipedia.org.

Additional section:
ns.wikipedia.org. IN A w.x.y.z

A vulnerable server would cache the additional A-record (IP address) for ns.wikipedia.org, allowing the attacker to resolve queries to the entire wikipedia.org domain.

[edit] Redirect the NS record to another target domain

The second variant of DNS cache poisoning involves redirecting the nameserver of another domain unrelated to the original request to 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:
wikipedia.org. 3600 IN NS ns.example.com.

Additional section:
ns.example.com. IN A w.x.y.z

A vulnerable server would cache the unrelated authority information for wikipedia.org's NS-record (nameserver entry), allowing the attacker to resolve queries to the entire wikipedia.org domain.

[edit] 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 [2]. This modification is a form of birthday attack.

[edit] 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. Unlike PowerDNS, and Djbdns, BIND binds to a static udp listen port upon startup and thus is unable to randomize source port numbers.

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.

[edit] See also

[edit] External links