DNS spoofing

Last updated

DNS spoofing, also referred to as DNS cache poisoning, is a form of computer security hacking in which corrupt Domain Name System data is introduced into the DNS resolver's cache, causing the name server to return an incorrect result record, e.g. an IP address. This results in traffic being diverted to any computer that the attacker chooses.

Contents

Overview of the Domain Name System

A Domain Name System server translates a human-readable domain name (such as example.com ) into a numerical IP address that is used to route communications between nodes. [1] Normally if the server does not know a requested translation it will ask another server, and the process continues 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). [2]

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. [3]

To perform a cache poisoning attack, the attacker exploits 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 attacker 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 malicious content, such as computer worms or 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, and website hijacking due to system vulnerabilities. Various methods, ranging from the use of social engineering tactics to the exploitation of weaknesses present in the DNS server software, can lead to these attacks. [4]

Variants

In the following variants, the entries for the server ns.target.example would be poisoned and redirected to the attacker's name server at IP address w.x.y.z. These attacks assume that the name server 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.[ citation needed ]

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 subdomain.attacker.example?

subdomain.attacker.example.INA

Attacker's response:

(no response)
attacker.example.3600INNSns.target.example.
ns.target.example.INAw.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.[ citation needed ]

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

subdomain.attacker.example.INA

Attacker's response:

(no response)
target.example.3600INNSns.attacker.example.
ns.attacker.example.INAw.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 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 [5] and above perform these checks. [6] 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 ]

However, when routers, firewalls, 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 nameservers and stub resolvers.[ citation needed ] [7]

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., [8] 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.

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 signatures. 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. 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. [9]

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources on the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

A name server is a computer application that implements a network service for providing responses to queries against a directory service. It translates an often humanly meaningful, text-based identifier to a system-internal, often numeric identification or addressing component. This service is performed by the server in response to a service protocol request.

<span class="mw-page-title-main">Domain name</span> Identification string in the Internet

In the Internet, a domain name is a string that identifies a realm of administrative autonomy, authority or control. Domain names are often used to identify services provided through the Internet, such as websites, email services and more. Domain names are used in various networking contexts and for application-specific naming and addressing purposes. In general, a domain name identifies a network domain or an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, or a server computer.

<span class="mw-page-title-main">Proxy server</span> Computer server that makes and receives requests on behalf of a user

In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource. It improves privacy, security, and possibly performance in the process.

<span class="mw-page-title-main">Root name server</span> Name server for the DNS root zone

A root name server is a name server for the root zone of the Domain Name System (DNS) of the Internet. It directly answers requests for records in the root zone and answers other requests by returning a list of the authoritative name servers for the appropriate top-level domain (TLD). The root name servers are a critical part of the Internet infrastructure because they are the first step in resolving human-readable host names into IP addresses that are used in communication between Internet hosts.

A wildcard DNS record is a record in a DNS zone that will match requests for non-existent domain names. A wildcard DNS record is specified by using a * as the leftmost label (part) of a domain name, e.g. *.example.com. The exact rules for when a wildcard will match are specified in RFC 1034, but the rules are neither intuitive nor clearly specified. This has resulted in incompatible implementations and unexpected results when they are used.

The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

A Canonical Name (CNAME) record is a type of resource record in the Domain Name System (DNS) that maps one domain name to another.

In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of another (main) domain. For example, if a domain offered an online store as part of their website example.com, it might use the subdomain shop.example.com.

The domain name arpa is a top-level domain (TLD) in the Domain Name System (DNS) of the Internet. It is used predominantly for the management of technical network infrastructure. Prominent among such functions are the subdomains in-addr.arpa and ip6.arpa, which provide namespaces for reverse DNS lookup of IPv4 and IPv6 addresses, respectively.

<span class="mw-page-title-main">DNS zone</span> Administrable unit of the Domain Name System

A DNS zone is a specific portion of the DNS namespace in the Domain Name System (DNS), which a specific organization or administrator manages. A DNS zone is an administrative space allowing more granular control of the DNS components, such as authoritative nameserver. The DNS is broken up into different zones, distinctly managed areas in the DNS namespace. DNS zones are not necessarily physically separated from one another; however, a DNS zone can contain multiple subdomains, and multiple zones can exist on the same server.

Distributed denial-of-service attacks on root nameservers are Internet events in which distributed denial-of-service attacks target one or more of the thirteen Domain Name System root nameserver clusters. The root nameservers are critical infrastructure components of the Internet, mapping domain names to IP addresses and other resource record (RR) data.

This article presents a comparison of the features, platform support, and packaging of many independent implementations of Domain Name System (DNS) name server software.

<span class="mw-page-title-main">OpenDNS</span> Domain name system provided by Cisco using closed-source software

OpenDNS is an American company providing Domain Name System (DNS) resolution services—with features such as phishing protection, optional content filtering, and DNS lookup in its DNS servers—and a cloud computing security product suite, Umbrella, designed to protect enterprise customers from malware, botnets, phishing, and targeted online attacks. The OpenDNS Global Network processes an estimated 100 billion DNS queries daily from 85 million users through 25 data centers worldwide.

DNS hijacking, DNS poisoning, or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries. This can be achieved by malware that overrides a computer's TCP/IP configuration to point at a rogue DNS server under the control of an attacker, or through modifying the behaviour of a trusted DNS server so that it does not comply with internet standards.

<span class="mw-page-title-main">Dan Kaminsky</span> American computer security researcher (1979–2021)

Daniel Kaminsky was an American computer security researcher. He was a co-founder and chief scientist of Human Security, a computer security company. He previously worked for Cisco, Avaya, and IOActive, where he was the director of penetration testing. The New York Times labeled Kaminsky an "Internet security savior" and "a digital Paul Revere".

In computer networking, split-horizon DNS is the facility of a Domain Name System (DNS) implementation to provide different sets of DNS information, usually selected by the source address of the DNS request.

MaraDNS is an open-source Domain Name System (DNS) implementation, which acts as either a caching, recursive, or authoritative nameserver.

Google Public DNS is a Domain Name System (DNS) service offered to Internet users worldwide by Google. It functions as a recursive name server. Google Public DNS was announced on December 3, 2009, in an effort described as "making the web faster and more secure." As of 2018, it is the largest public DNS service in the world, handling over a trillion queries per day. Google Public DNS is not related to Google Cloud DNS, which is a DNS hosting service.

References

  1. Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). "Information fusion-based method for distributed domain name system cache poisoning attack detection and identification". IET Information Security. 10 (1): 37–44. doi:10.1049/iet-ifs.2014.0386. ISSN   1751-8717. S2CID   45091791.
  2. Son, Sooel; Shmatikov, Vitaly. "The Hitchhiker's Guide to DNS Cache Poisoning" (PDF). Cornell University. Archived (PDF) from the original on 14 August 2017. Retrieved 3 April 2017.
  3. Storms, Andrew (2006). "Don't Trust Your Vendor's Software Distribution Methodology". Information Systems Security. 14 (6): 38–43. doi:10.1201/1086.1065898X/45782.14.6.20060101/91858.8. S2CID   15167573 via ProQuest Central.
  4. m. Dissanayake, I. M. (2018). "DNS Cache Poisoning: A Review on its Technique and Countermeasures". 2018 National Information Technology Conference (NITC). pp. 1–6. doi:10.1109/NITC.2018.8550085. ISBN   978-1-5386-9136-6 . Retrieved 31 January 2024.
  5. "BIND Security Matrix". ISC Bind. Archived from the original on 11 November 2011. Retrieved 11 May 2011.
  6. "ISC Bind Security". ISC Bind. Archived from the original on 11 November 2011. Retrieved 11 May 2011.
  7. Dearing, Christopher (2019). "Personal Information as an Attack Vector: Why Privacy Should Be an Operational Dimension of U.S. National Security †". Journal of National Security Law & Policy. 10: 351–403. ProQuest   2395864954 via ProQuest.
  8. "Root DNSSEC". ICANN/Verisign. p. 1. Archived from the original on 10 September 2017. Retrieved 5 January 2012.
  9. "The right configuration to secure your server". IONOS Digitalguide. Retrieved 29 April 2022.