- DNS cache poisoning
-
DNS cache poisoning is a security or data integrity compromise in the Domain Name System (DNS). The compromise occurs when data is introduced into a DNS name server's cache database that did not originate from authoritative DNS sources. It may be a deliberate attempt of a maliciously crafted attack on a name server. It may also be an unintended result of a misconfiguration of a DNS cache or from improper software design of DNS applications.
When a DNS server has received such non-authentic data and caches it for performance optimization, it is considered poisoned, supplying the non-authentic data to the clients of the server.
A domain name server translates a domain name (such as example.com) into an IP address that Internet hosts use to contact Internet resources. If a DNS server is poisoned, it may return an incorrect IP address, diverting traffic to another computer.
Contents
Cache poisoning attacks
Normally, a networked computer uses a DNS server provided by the computer user's organization or an Internet service provider (ISP). DNS servers are generally deployed in an organization's network to improve resolution response performance by caching previously obtained query results. Poisoning attacks on a single DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.
To perform a cache poisoning attack, the attacker exploits a flaw in the DNS software. If the server does not correctly validate DNS responses to ensure that they are from an authoritative source (for example by using DNSSEC) the server will end up caching the incorrect entries locally and serve them to other users that make the same request.
This technique can be used to direct users of a website to another site of the attacker's choosing. For example, an attacker spoofs 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 files on the server he controls with names matching those on the target server. These files could contain malicious content, such as a computer worm or a computer virus. A user whose computer has referenced the poisoned DNS server would be tricked into accepting content coming from a non-authentic server and unknowingly download malicious content.
Variants
In the following variants, the entries for the server ns.target.example would be poisoned and redirected to the attacker's nameserver at IP address w.x.y.z. These attacks assume that the nameserver for target.example is ns.target.example.
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.attacker.example?
subdomain.attacker.example. IN A
Attacker's response:
Answer: (no response)
Authority section: attacker.example. 3600 IN NS ns.target.example.
Additional section: ns.target.example. IN A w.x.y.z
A vulnerable server would cache the additional A-record (IP address) for ns.target.example, allowing the attacker to resolve queries to the entire target.example domain.
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.attacker.example?
subdomain.attacker.example. IN A
Attacker's response:
Answer: (no response)
Authority section: target.example. 3600 IN NS ns.attacker.example.
Additional section: ns.attacker.example. IN A w.x.y.z
A vulnerable server would cache the unrelated authority information for target.example's NS-record (nameserver entry), allowing the attacker to resolve queries to the entire target.example domain.
Prevention and mitigation
Many cache poisoning attacks can be prevented on DNS servers by 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, versions of BIND 9.5.0-P1[1] and above perform these checks.[2] 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 cryptographic nonce, can greatly reduce the probability of successful DNS race attacks.
However routers, firewalls, proxies, and other gateway devices that perform network address translation (NAT), or more specifically, port address translation (PAT), often rewrite source ports in order to track connection state. When modifying source ports, PAT devices typically remove source port randomness implemented by nameservers and stub resolvers
Secure DNS (DNSSEC) uses cryptographic electronic signatures signed with a trusted public key certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks, but as of 2008 was not yet widely deployed. In 2010 DNSSEC was implemented in the Internet root zone servers.
This kind of attack may also be mitigated at the transport layer or application layer by performing end-to-end validation once a connection is established. 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 secure shell 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 signing certificate locally and validate the signature stored in the software update against the embedded certificate.
Intelligent Anycast Cache Appliancees from Dell and TCPWave have watchdogs, which ensure that the DNS processes do not get a cache poison by predefining the roots in the watchdogs. Source port randomization via BIND backed up by a non-BIND DNS server software with intelligence blended into the BGP routing protocol mitigates the DNS Anycast cache poisoning attacks from malicious users.
See also
References
- ^ "BIND Security Matrix". ISC Bind. http://www.isc.org/software/bind/security/matrix. Retrieved 11 May 2011.
- ^ "ISC Bind Security". ISC Bind. http://www.isc.org/software/bind/security. Retrieved 11 May 2011.
External links
- BIND 9 DNS Cache Poisoning - Discovered by Amit Klein (Trusteer)
- Predictable transaction IDs in Microsoft DNS server allow cache poisoning
- Microsoft Knowledge Base: How to prevent DNS cache pollution
- SANS DNS cache poisoning update
- DNS Threats & Weaknesses: research and presentations
- Blocking Unwanted Domain Names Creative Usage of the Hosts File
- Dnsstuff.com's DNS Vulnerability Check Test to see if you are Vulnerable
- Steve Gibson of GRC's ISP DNS testing tool Check your ISP's DNS resolvers for vulnerabilities
- Security-Database Tools Watch PorkBind Scanner for 13 DNS Flaws including the DNS Poisoning
- Movie explaining DNS Cache Poisioning
- An Illustrated Guide to the Kaminsky DNS Vulnerability
- US CERT advisory : Multiple DNS implementations vulnerable to cache poisoning
- Secret Geek A-Team Hacks Back, Defends Worldwide Web An article about defending against DNS poisoning
Categories:- Computer security exploits
- Domain name system
Wikimedia Foundation. 2010.
