DNS cache poisoning 1507752 226109063 2008-07-16T21:24:30Z MrOllie 6908984 [[WP:UNDO|Undid]] revision 226107219 by [[Special:Contributions/12.203.80.61|12.203.80.61]] ([[User talk:12.203.80.61|talk]]) '''DNS cache poisoning''' is a maliciously created or unintended situation that provides data to a [[Name Server|Domain Name Server]] that did not originate from authoritative [[Domain Name System|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'', extending the effect of the situation to the clients of the server. ==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. 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 [[computer worm|worm]] or a [[computer virus|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. [http://www.adsale.com.hk/tw/iframe/anews-s3-n4.asp] ==Variants== In the following variants, the entries for the server <tt>ns.wikipedia.org</tt> would be poisoned and redirected to the attacker's nameserver at IP address <tt>w.x.y.z</tt>. These attacks assume that the nameserver for <tt>wikipedia.org</tt> is <tt>ns.wikipedia.org</tt>. 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 <tt>subdomain.example.com</tt>? 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 <tt>ns.wikipedia.org</tt>, allowing the attacker to resolve queries to the entire <tt>wikipedia.org</tt> 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 <tt>subdomain.example.com</tt>? 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 <tt>wikipedia.org</tt>'s NS-record (nameserver entry), allowing the attacker to resolve queries to the entire <tt>wikipedia.org</tt> domain. ===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 [[cryptographic nonce|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 [http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html]. This modification is a form of [[birthday attack]]. ==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 [[cryptographic nonce|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 [[Public key certificate|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 signature]]s. 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|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. ==See also== * [[Domain Name System]] * [[Root nameserver]] * [[Pharming]] ==External links== * [http://www.trusteer.com/docs/bind9dns.html BIND 9 DNS Cache Poisoning - Discovered by Amit Klein (Trusteer)] * [http://www.scanit.be/advisory-2007-11-14.html Predictable transaction IDs in Microsoft DNS server allow cache poisoning] * [http://support.microsoft.com/default.aspx?scid=kb;en-us;241352 Microsoft Knowledge Base: How to prevent DNS cache pollution] * [http://isc.sans.org/diary.php?date=2005-04-07 SANS DNS cache poisoning update] * [http://www.dnssec.net/dns-threats.php DNS Threats & Weaknesses: research and presentations] * [http://www.hackernotcracker.com/2007-01/blocking-unwanted-domain-names-creative-usage-of-the-hosts-file.html Blocking Unwanted Domain Names] Creative Usage of the Hosts File [[Category:Security exploits]] [[Category:Domain name system|Cache poisoning]] [[de:Cache Poisoning]] [[es:DNS Poisoning]] [[fr:Empoisonnement du cache DNS]] [[it:DNS cache poisoning]] [[pl:Zatruwanie DNS]]