Editing DNS spoofing

{{Short description|Cyberattack using corrupt DNS data}}
{{More citations needed|date=January 2012}}
{{Use dmy dates|date=February 2024}}
'''DNS spoofing''', also referred to as '''DNS cache poisoning''', is a form of computer security [[Security hacker|hacking]] in which corrupt [[Domain Name System]] data is introduced into the [[DNS resolver]]'s [[DNS cache|cache]], causing the [[name server]] to return an incorrect result record, e.g. an [[IP address]]. This results in [[Man-in-the-middle attack|traffic being diverted]] to any computer that the attacker chooses. Put simply, a hacker makes the device think it is connecting to the chosen website, when in reality, it is redirected to a different website by altering the [[IP address]] associated with the [[domain name]] in the DNS server.<ref>Hanley, Sinéad (2000-11-06). [http://ogobin.de/internet/%5bPaper%5d%20dns_spoofing.pdf "DNS Overview with a discussion of DNS Spoofing"] (PDF).</ref>

==Overview of the Domain Name System==
{{Main|Domain Name System}}

A [[Name server|Domain Name System server]] translates a human-readable [[domain name]] (such as <code>[[example.com]]</code>) into a numerical [[IP address]] that is used to [[Route (command)|route]] communications between [[Node (networking)|nodes]].<ref>{{Cite journal |last1=Wu |first1=Hao |last2=Dang |first2=Xianglei |last3=Wang |first3=Lidong |last4=He |first4=Longtao |date=2016 |title=Information fusion-based method for distributed domain name system cache poisoning attack detection and identification |url=https://onlinelibrary.wiley.com/doi/10.1049/iet-ifs.2014.0386 |journal=IET Information Security |language=en |volume=10 |issue=1 |pages=37–44 |doi=10.1049/iet-ifs.2014.0386 |s2cid=45091791 |issn=1751-8717|url-access=subscription }}</ref> Normally if the server does not know a requested translation it will ask another server, and the process continues [[Recursion|recursively]]. To increase performance, a server will typically remember (cache) these translations for a certain amount of time. This means if it receives another request for the same translation, it can reply without needing to ask any other servers, until that cache expires.

When a DNS server has received a false translation and caches it for performance optimization, it is considered ''poisoned'', and it supplies the false data to clients. If a DNS server is poisoned, it may return an incorrect IP address, diverting traffic to another computer (often an attacker's).<ref>{{cite news |url=https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf |access-date=3 April 2017 |title=The Hitchhiker's Guide to DNS Cache Poisoning |publisher=[[Cornell University]] |first1=Sooel |last1=Son |first2=Vitaly |last2=Shmatikov |archive-date=14 August 2017 |archive-url=https://web.archive.org/web/20170814024945/http://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf |url-status=live }}</ref>

==Cache poisoning attacks==
Normally, a networked computer uses a DNS server provided by an Internet service provider (ISP) or the computer user's organization. DNS servers are used 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 those serviced indirectly by its downstream server(s) if applicable.<ref>{{Cite journal|last=Storms|first=Andrew|date=2006|title=Don't Trust Your Vendor's Software Distribution Methodology|journal=Information Systems Security|volume=14|issue=6|pages=38–43|doi=10.1201/1086.1065898X/45782.14.6.20060101/91858.8|s2cid=15167573|via=ProQuest Central}}</ref>

To perform a [[cache poisoning]] attack, the attacker [[Exploit (computer security)|exploit]]s flaws in the DNS software.  A server should correctly validate DNS responses to ensure that they are from an authoritative source (for example by using [[DNSSEC]]); otherwise the server might end up caching the incorrect entries locally and serve them to other users that make the same request.

This attack can be used to redirect users from a website to another site of the attacker's choosing.  For example, an [[Spoofing attack|attacker]] [[IP address spoofing|spoofs]] the IP address DNS entries for a target website on a given DNS server and replaces them with the IP address of a server under their control. The attacker then creates files on the server under their control with names matching those on the target server. These files usually contain [[Malware|malicious]] content, such as [[computer worm]]s or [[computer virus|viruses]]. A user whose computer has referenced the poisoned DNS server gets tricked into accepting content coming from a non-authentic server and unknowingly downloads the malicious content. This technique can also be used for [[phishing]] attacks, where a fake version of a genuine website is created to gather personal details such as bank and credit/debit card details.

The vulnerability of systems to DNS cache poisoning goes beyond its immediate effects as it can open users up to further risks such as [[phishing]], [[malware]] injections, [[Denial-of-service attack|denial of service]], and website hijacking due to system vulnerabilities. Various methods, ranging from the use of [[Social engineering (security)|social engineering]] tactics to the exploitation of weaknesses present in the DNS server software, can lead to these attacks.<ref>{{Cite book |chapter=DNS Cache Poisoning: A Review on its Technique and Countermeasures  |chapter-url=https://ieeexplore.ieee.org/document/8550085 |access-date=2024-01-31 |date=2018 |doi=10.1109/NITC.2018.8550085 |last1=m. Dissanayake |first1=I. M. |title=2018 National Information Technology Conference (NITC) |pages=1–6 |isbn=978-1-5386-9136-6 }}</ref>

==Variants==
In the following variants, the entries for the server {{samp|ns.target[[.example]]}} would be poisoned and redirected to the attacker's name server at IP address {{IPaddr|w.x.y.z}}. These attacks assume that the name server for {{samp|target.example}} is {{samp|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.{{Citation needed|date=January 2012}}

===Redirect the target domain's name server===
The first variant of DNS cache poisoning involves redirecting the name server of the attacker's domain to the name server of the target domain, then assigning that name server an IP address specified by the attacker.

DNS server's request: what are the address records for {{samp|subdomain.attacker.example}}?

{{sxhl|2=zone|subdomain.attacker.example. IN A}}

Attacker's response:

* Answer:
 (no response)

* Authority section:
{{sxhl|2=zone|attacker.example. 3600 IN NS ns.target.example.}}
 
* Additional section:
{{sxhl|2=zone|ns.target.example. IN A w.x.y.z}}

A vulnerable server would cache the additional A-record (IP address) for {{samp|ns.target.example}}, allowing the attacker to resolve queries to the entire {{samp|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.{{Citation needed|date=January 2012}}

DNS server's request: what are the address records for {{samp|subdomain.attacker.example}}?

{{sxhl|2=zone|subdomain.attacker.example. IN A}}

Attacker's response:

* Answer:
 (no response)

* Authority section:
{{sxhl|2=zone|target.example. 3600 IN NS ns.attacker.example.}}
 
* Additional section:
{{sxhl|2=zone|ns.attacker.example. IN A w.x.y.z}}

A vulnerable server would cache the unrelated authority information for {{samp|target.example}}'s NS-record ([[Name server|nameserver]] entry), allowing the attacker to resolve queries to the entire {{samp|target.example}} domain.

==Prevention and mitigation==
Many cache poisoning attacks against DNS servers can be prevented by being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back that are not directly relevant to the query. For example, versions of [[BIND]] 9.5.0-P1<ref>{{cite web|title=BIND Security Matrix|url=http://www.isc.org/software/bind/security/matrix|work=ISC Bind|access-date=11 May 2011|archive-url=https://web.archive.org/web/20111111173314/https://www.isc.org/software/bind/security/matrix|archive-date=11 November 2011|url-status=dead}}</ref> and above perform these checks.<ref>{{cite web|title=ISC Bind Security|url=http://www.isc.org/software/bind/security|work=ISC Bind|access-date=11 May 2011|archive-url=https://web.archive.org/web/20111111004309/https://www.isc.org/software/bind/security|archive-date=11 November 2011|url-status=dead}}</ref> 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.{{citation needed|date=June 2022}}

However, when routers, [[Firewall (computing)|firewalls]], [[Proxy server|proxies]], and other gateway devices perform [[network address translation]] (NAT), or more specifically, port address translation (PAT), they may rewrite source ports in order to track connection state. When modifying source ports, PAT devices may remove source port randomness implemented by [[Name server|nameservers]] and stub resolvers.{{Citation needed|date=January 2012}}<ref>{{Cite journal|last=Dearing|first=Christopher|date=2019|title=Personal Information as an Attack Vector: Why Privacy Should Be an Operational Dimension of U.S. National Security †|url=https://www.proquest.com/docview/2395864954|journal=Journal of National Security Law & Policy|volume=10|pages=351–403|id={{ProQuest|2395864954}} |via=ProQuest}}</ref>

Secure DNS ([[DNSSEC]]) uses cryptographic digital signatures signed with a trusted [[public key certificate]] to determine the authenticity of data. DNSSEC can counter cache poisoning attacks. In 2010 DNSSEC was implemented in the Internet root zone servers,<ref name="rootdnssec">{{cite web | url=http://www.root-dnssec.org/ | title=Root DNSSEC | publisher=ICANN/Verisign | access-date=5 January 2012 | pages=1 | archive-date=10 September 2017 | archive-url=https://web.archive.org/web/20170910160611/http://www.root-dnssec.org/ | url-status=live }}</ref> but needs to be deployed on all [[top level domain]] servers as well. The DNSSEC readiness of these is shown in the [[list of Internet top-level domains]].  As of 2020, all of the original TLDs support DNSSEC, as do country code TLDs of most large countries, but many country-code TLDs still do not.<ref>{{cite arXiv |eprint=2011.12978 |last1=Wei |first1=Lan |last2=Heidemann |first2=John |title=Whac-A-Mole: Six Years of DNS Spoofing |date=2020 |class=cs.CR }}</ref>

This kind of attack can 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 signature]]s. For example, by using [[HTTPS]] (the secure version of [[HTTP]]), users may check whether the server's digital certificate is valid and belongs to a website's expected owner.<ref>{{Cite book |last1=Maksutov |first1=Artem A. |last2=Cherepanov |first2=Ilya A. |last3=Alekseev |first3=Maksim S. |chapter=Detection and prevention of DNS spoofing attacks |date=2017-04-12 |title=2017 Siberian Symposium on Data Science and Engineering (SSDSE) |chapter-url=https://ieeexplore.ieee.org/document/8071970 |pages=84–87 |doi=10.1109/SSDSE.2017.8071970|isbn=978-1-5386-1593-5 }}</ref> 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.<ref>{{Cite web |title=The right configuration to secure your server |url=https://www.ionos.com/digitalguide/server/configuration/securing-a-server-correctly-configuring-linux-etc/ |access-date=2022-04-29 |website=IONOS Digitalguide |language=en}}</ref>

==See also==
* [[DNS hijacking]]
* [[DNS rebinding]]
* [[Mausezahn]]
* [[Pharming]]
* [[Root name server]]
* [[Dan Kaminsky]]

==References==
{{reflist}}

[[Category:Computer security exploits]]
[[Category:Domain Name System]]
[[Category:Hacking (computer security)]]
[[Category:Internet security]]
[[Category:Internet ethics]]
[[Category:Internet service providers]]
[[Category:Types of cyberattacks]]