DNSSEC

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.

Photo by DeepMind on Unsplash

What is a Cache?

A cache is a temporary storage location that allows faster retrieval of frequently used data and files. Several types of caches are found across several devices and applications, such as laptops, desktops, smartphones, tablets, web applications, and web browsers. The purpose is to make everything run faster and more efficiently.

When a user opens an app or visits a website for the first time, pertinent data and files are stored in the web cache. When the user revisits the website or app, the associated data and files can be accessed locally from the cache, allowing the site or app to load more quickly. This is why after users initially input their credentials into a website or app, such as Amazon or Gmail, they typically do not have to do so again with each subsequent visit.

Benefits of Caches

The most recognized benefit of caches by users and IT professionals is that they allow apps and websites to run much faster, improving the system’s performance. The DNS (Domain Name Server) resolver can respond to queries without communicating with multiple servers. There are also additional benefits to caches, including:

Offline access: As mentioned above, caches save data. In some situations, this allows apps to work without an internet connection. The reason some apps can do so is that the cached data can be used to enable the app to function correctly.

Optimize resources: Since caches only need to download files once, the app or website doesn’t have to waste battery power and time downloading data on each subsequent visit. Caches significantly increase efficiency.

It is pertinent to note two things. First, the data from a site or an

app will be redownloaded if changes have been made to the data or files. Second, the DNS information is stored in the designated cache for a specific time frame known as TTL (Time-to-Live). This is why users must re-login into applications such as their email every so often (e.g., 30 days).

How Cache Poisoning Works

In DNS poisoning, the perpetrator enters fake information into the DNS cache. The purpose is to redirect users from the intended server to a different server. The new destination is dangerous and has malicious intentions. There are three different forms of attack:

Once the user is on the malicious website, some program, such as a hijacking program, spyware, malware, a worm, a trojan, etc., is downloaded onto the user’s device without their knowledge.
Sensitive information such as login credentials or bank information may be stolen because the user believes they are on a legitimate website or app, so they willingly input their information. Instead, they are on a phishing website. A common tactic to use is the man-in-the-middle attack approach. A man-in-the-middle attack may occur where the perpetrator alters the communication between two parties. For example, users may think they are talking with a bank representative about their accounts. When the truth is that the attacker has intercepted and hijacked the conversation so that the user is now actually talking with a cyber attacker. The users believing they are communicating with a trustworthy party, may give out sensitive information.
The attacker compromises security updates on the device, which leaves the device vulnerable to hacking.

It is essential to understand that the attacker disguises the dangerous destination, so the user has no idea they’ve been a victim of a cyber attack and were diverted to a different server other than the intended one. One way attackers accomplish DNS spoofing attacks is to enter a website address into the DNS that has been altered. The destination is a fake website disguised as a real one. Cache poisoning can occur on Apple (Mac), Android, and Microsoft operating systems.

Preventing Cache Poisoning

Effectively preventing cache poisoning is the combined responsibility of website owners, DNS service providers, and users. Here are the best ways to protect your business from DNS poisoning.

Utilize DNS Security Extensions

DNS Security Extensions (Domain Name System Security Extensions) or DNSSEC is a protocol in which authentication is required at every communication step between servers. It creates a digital hierarchy designed to prevent cache poisoning. While this is better than nothing, DNS Security Extensions still have vulnerabilities because IP addresses and URLs can still be falsified. Name servers cannot tell the difference during translation.

Utilize End-to-End Encryption

End-to-End Encryption (E2EE) sends encrypted DNS requests that only the intended server can decrypt. This is a useful method because cyber attackers should be unable to decrypt and exploit the request. However, as with all things internet-based, some attackers can decrypt or foil these encrypted requests.

Educate users

Educate end-users on how to safely use apps and websites and implement internet protocols that significantly reduce their chances of introducing an attack into the system. Here’s what users should do whenever possible:

Never click on unknown URLs
Never disable firewalls
Routinely scan devices for suspicious activity
Routinely clear the cache (if a cache has been poisoned unknowingly, this will help get rid of it faster than waiting for the TTL to expire)
Use a VPN (a virtual private network) when possible.

What is DNS Spoofing?

What is Cache Poisoning?