Photo by Lars Kienle on Unsplash
DNS spoofing, or DNS cache poisoning, is a phishing and cyber attack where false Domain Name System (DNS) information is introduced into a DNS resolver’s cache. This causes DNS queries to return an incorrect response, which commonly redirects users from a legitimate website to a malicious website designed to steal sensitive information or install malware.
There are several reasons why DNS spoofing is possible, but the principal problem is DNS was built in the 1980s when the Internet was much smaller, and security was not a primary concern. There is no in-built way for DNS resolvers to verify the validity of the data they store, and incorrect DNS information can remain until the time to live (TTL) expires or is manually updated.
How Do Attackers Poison DNS Caches?
DNS poisoning or DNS spoofing attacks work by impersonating DNS nameservers, making a request to a DNS resolver, and then forging the reply when the DNS resolver queries a nameserver. This is possible because DNS uses UDP, an unencrypted protocol, which makes it easy to intercept traffic with spoofing. DNS servers do not validate the IP addresses they are directing traffic to.
There are two common methods for poisoning DNS caches:
Man in the middle attack: The interception of communication between users and a DNS server to route users to a different or malicious IP address. In this situation, the attacker sits between the computer’s stub resolver and the recursive resolver, sending back a fake DNS result.
DNS server compromise: This type of attack occurs when an attacker gains direct access to the DNS server of a domain, generally through spear phishing or whaling, and updates the DNS entries to point to a malicious website. This type of attack is also known as DNS hijacking.
This works because, unlike TCP, which relies on both communicating parties performing a ‘handshake’ to initiate communication and verify the identity of devices, DNS requests and responses rely on UDP or User Datagram Protocol. With UDP, there is no guarantee that a connection is open, that the recipient is ready to receive, or that the sender is who they say they are. This leaves UDP communications vulnerable to MITM attacks; an attacker can send a message via UDP, pretending that it is a legitimate nameserver by forging header data. If the receiving DNS resolver accepts the fake response and caches, which can happen as there is no way to verify if the information is accurate and comes from a legitimate source. With that said, DNS spoofing attacks are not easy to pull off as the DNS resolver queries the authoritative nameserver giving attackers only a few milliseconds to fake the response before the real response arrives.
When are DNS Spoofing Attacks Successful?
For a DNS spoofing attack to be successful, attackers either need to know or guess:
Which DNS queries are not cached by the targeted DNS resolver so that the resolver will query the authoritative name server what port the DNS resolver uses, which was easy in the past but has since become much more difficult as DNS resolvers rotate their open ports to mitigate DNS spoofing The request ID number which authoritative nameserver the DNS resolver will query.
Furthermore, these malicious websites are often used to install computer worms, ransomware, and spyware on the user’s computer, giving the perpetrator long-term access.
How to Mitigate DNS Spoofing
The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications designed to secure certain kinds of information the DNS provides. DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence, and data integrity but not availability or confidentiality.
Like TLS/SSL, DNSSEC uses public-key cryptography to verify and authenticate DNS data.
When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record and the requested record type. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.
The delegation signer (DS) is used to authenticate DNSKEYs by using a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.
The chain of trust starts with a set of verified public keys for the DNS root zone, the trusted third party. Domain owners generate their own public key/private key pair and upload them using their domain-name registrar’s DNS control panel, which pushes the keys via secDNS to the zone operator (for example, Verisign for the com zone), who signs and publishes them in the DNS.
This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.
In short, DNSSEC provides two security features to DNS:
Data origin authentication: This allows a resolver to cryptographically verify data from the zone requested.Data integrity protection: This allows a resolver to know that the data hasn’t been modified in transit and was originally signed by the zone owner’s private key.
These two security features all any recursive resolver to look up data in the zone and retrieve the zone’s public key, which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end-user. If the signature is not valid, the resolver assumes a cyber attack, discards the data, and returns an error.
While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS, such as Certificate records, SSH fingerprints, IPSec public keys, and TLS Trust Anchors.
That said, DNSSEC, unlike SSL certificates, does not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).
DNSSEC also has several potential downsides, including:
Lack of data confidentiality: While DNSSEC authenticates, it does. not encode DNS responses. This means that perpetrators can still listen in on traffic and use this data for more sophisticated attacks; this is why SSL certificates are such an important part of Internet security. Deployment complexity: DNSSEC is easily misconfigured, which can cause servers to lose their security benefits or even deny access to the website altogether. No widespread adoption: While DNSSEC was published in 2005, it has not yet become mainstream, leaving any DNS records vulnerable to attacks.
Beyond DNSSEC, there are other ways you can prevent DNS spoofing:
Active monitoring: DNS data should be continuously monitored for changes, such as the appearance of a new external host, that could indicate compromise.
Patching: Like anything, DNS servers and software can be vulnerable to exploits and zero-day vulnerabilities. Ensure whoever is hosting your DNS records is meticulous about vulnerability management and attack surface management.
DNS updates Newer versions of DNS use port randomization and cryptographically secure transaction IDs to prevent DNS attackers and ensure your servers are up-to-date.
Password policies: Ensure you use strong passwords and, ideally, two-factor authentication for the account that manages your DNS records. And don’t forget about changing default passwords on network equipment, such as routers, which can put every device and user in danger if compromised. Read our guides on password security and network security for more information.
Invest in cybersecurity awareness training: Remember that many DNS spoofing attacks are either the result of or aim to initiate some phishing attack. Educate your staff about what to look for in phishing campaigns.
