Cache Poisoning: Difference between revisions
Created page with "'''Cache Poisoning''' is the insertion of false data into recursive name server, which remember previous lookups. The attacker sends fake DNS answers in response to a..." |
No edit summary |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''Cache Poisoning''' is the insertion of false data into recursive [[ | '''Cache Poisoning''' is the insertion of false data into a recursive [[Name Server]]. | ||
==Overview== | ==Overview== | ||
The attacker sends fake [[DNS]] answers in response to a query and tricks it into thinking the wrong data is correct for a given domain. The server remembers the wrong answer in its cache and provides that wrong answer in future lookups.<ref>[https://www.iana.org/reports/2008/cross-pollination-faq.html Frequently Asked Questions on Cache Poisoning and Cross Pollination, IANA]</ref> | |||
==History== | ==History== | ||
In 1993, [[Christoph Schuba]] wrote "Addressing Weaknesses in the Domain Name System Protocol," which outlined DNS cache poisoning among other issues. The possibility of providing extra information in DNS reply packets allowed attackers to inject false information into the DNS cache, enabling [[man-in-the-middle attacks]].<br/> | |||
In 1997, [[CERT]] published [[CA-1997-22]] concerning the Berkeley Internet Name Domain ([[BIND]]) software, which used sequential transaction IDs rather than randomizing them. Following this advisory, all new versions of BIND were updated to use randomized transaction IDs. | |||
===Birthday Attack=== | |||
In 2002, [[Vagner Sacramento]] found that BIND would send multiple simultaneous recursive queries for the same IP address, making attacks not only possible but probable with simply a few hundred packets.<ref>[https://www.secureworks.com/blog/dns-cache-poisoning Cache Poisoning, SecureWorks]</ref> <br/> | |||
In 2008, [[Dan Kaminsky]] built on the security community's understanding of the birthday attack, showing that attackers can force the target resolver to initiate a query to an authoritative server of their choice; that modern attackers can generate a large number of unique spoofed responses, and that the malicious payload of each forged response is an additional section rather than the answer section. The attack introduces into the target resolver’s cache a false mapping for an authoritative server. Future queries from | |||
the compromised resolver go to the attacker-controlled IP address.<ref>[https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf Sooel Son and Vitaly Shmatikov, The Hitchhiker’s Guide to DNS Cache Poisoning]</ref><br/> | |||
==Mitigation== | ==Mitigation== | ||
Use a randomized source port to reduce the risk of a cache poisoning attack instead of using the same source port number for every DNS query. | ===Non-Cryptographic=== | ||
Use a randomized source port to reduce the risk of a cache poisoning attack instead of using the same source port number for every DNS query. Other defense options include: 0x20-bit encoding, [[XQID]], and [[WSEC-DNS]]. | |||
===Cryptographic=== | |||
[[DNSSEC]] | |||
==References== | ==References== | ||
[[Category:DNS Abuse]] | |||
Latest revision as of 20:49, 12 July 2021
Cache Poisoning is the insertion of false data into a recursive Name Server.
Overview
The attacker sends fake DNS answers in response to a query and tricks it into thinking the wrong data is correct for a given domain. The server remembers the wrong answer in its cache and provides that wrong answer in future lookups.[1]
History
In 1993, Christoph Schuba wrote "Addressing Weaknesses in the Domain Name System Protocol," which outlined DNS cache poisoning among other issues. The possibility of providing extra information in DNS reply packets allowed attackers to inject false information into the DNS cache, enabling man-in-the-middle attacks.
In 1997, CERT published CA-1997-22 concerning the Berkeley Internet Name Domain (BIND) software, which used sequential transaction IDs rather than randomizing them. Following this advisory, all new versions of BIND were updated to use randomized transaction IDs.
Birthday Attack
In 2002, Vagner Sacramento found that BIND would send multiple simultaneous recursive queries for the same IP address, making attacks not only possible but probable with simply a few hundred packets.[2]
In 2008, Dan Kaminsky built on the security community's understanding of the birthday attack, showing that attackers can force the target resolver to initiate a query to an authoritative server of their choice; that modern attackers can generate a large number of unique spoofed responses, and that the malicious payload of each forged response is an additional section rather than the answer section. The attack introduces into the target resolver’s cache a false mapping for an authoritative server. Future queries from
the compromised resolver go to the attacker-controlled IP address.[3]
Mitigation
Non-Cryptographic
Use a randomized source port to reduce the risk of a cache poisoning attack instead of using the same source port number for every DNS query. Other defense options include: 0x20-bit encoding, XQID, and WSEC-DNS.