Read more ->
SAD DNS | A revival of the DNS cache poisoning attack
9 Min A series of flaws in the software stack has led to a revival of the classic DNS cache poisoning attack. We analyze how the newly discovered SAD DNS attack looks like and how to mitigate this threat in the DNS ecosystem.
Published by
Simone Catania
Date
2023/03/27
The Domain Name System (DNS) is used to assign names to hosts on the network. It is a very useful protocol as it translates the more human-friendly domain names into numerical IP addresses. For example, the DNS resolves the domain name www.yourdomain.com into its IP address such as 165.78.323.567. Unfortunately, this system is far from being secure.
The DNS was created in the early days of the internet when the only parties connected were universities and research centers. There was no reason to expect anyone to try to come up with spoofing and cache poisoning at that time. The DNS protocol has a history of vulnerabilities and probably the most well-known dates back to the famous Kaminsky attack in 2008. It was the first widely publicized DNS cache poisoning attack discovered by Dan Kaminsky, a US security researcher.
In 2020 a new DNS vulnerability was discovered by researchers of the University of California Riverside shedding light on the weakness of the DNS, once again. It is also very important to understand today what the threats connected to the DNS are and how to protect yourself.
What is DNS caching?
Let’s start and clarify what the DNS cache is and how it works. A DNS resolver cache is a temporary database with all records of recent visits and attempted visits to websites and other web domains. The responses to IP address requests are stored in the computer’s operating system for a certain period, according to the designated Time-To-Live (TTL) value associated with that IP address. This way, the resolver can respond to future queries much faster, without the need to communicate with many servers involved in the typical DNS resolution process.
What is a DNS cache poisoning attack?
The DNS cache poisoning attack aims to modify the nameserver cache and change the IP address and/or the name of the server. In particular, this technique is based on inserting the fake cache record with a TTL. This attack allows redirecting a domain name like www.yourdomain.com to an IP address different from the original one.
DNS cache poisoning attacks have several objectives, such as:
- Spreading a virus or worms tricking the users into downloading a file.
- Man-in-the-middle attacks to monitor traffic.
- Phishing and pharming activities to collect sensitive data, such as passwords, bank accounts information, etc.
- Denial of Service by fooling the user that the server is unavailable.
One of the most well-known cache poisoning attacks is probably the one based on the birthday paradox, i.e. a brute-force attack based on the predictable information to spoof a DNS reply.
How does a DNS cache poisoning attack work?
Hackers can poison the DNS cache by tricking DNS resolvers into caching wrong information. By doing so the resolver will send a false IP address to the client and the user will be redirected to the wrong website.
The DNS protocol is vulnerable to attacks due to the weakness of its 16-bit transaction IDs. The DNS cache poisoning attack exploits exactly some DNS query fields during communication.
DNS cache poisoning is only applicable to the recursive DNS mode, i.e. when one DNS server communicates with many other DNS servers to resolve the IP address. Poisoning the DNS cache is made possible since DNS servers use a User Datagram Protocol (UDP) instead of the more secure Transmission Control Protocol (TCP). The UDP does not require both parties to perform a communication check. Furthermore, there is currently no verification for DNS information. 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.
Find perfect domains
Are DNS cache poisoning and DNS spoofing the same?
Let’s make things more clear as there is confusion around the terms DNS spoofing and cache poisoning. These two threats are often described as being the same type of attacks. Quite the opposite, they represent two different attack methods although sharing the same purpose.
While DNS spoofing refers to attacks in which fake resource records are sent using IP spoofing, cache poisoning refers to attacks in which fake resource records are smuggled into the victim’s DNS cache.
SAD DNS: the latest discovered method of DNS cache poisoning
In 2008, DNS server cache poisoning was a major problem. This type of attack was carried out by using fake IP addresses. Cybercriminals could redirect the browser from the secure site written in the address bar to a fake one infected with malware or with a phishing scheme. This problem has now been fixed in all DNS server software. Since then, DNS servers have strengthened their security, and attacks of this type have been reduced to such an extent that they are very rare. However, in 2020 the DNS cache poisoning attacks had a revival gaining quite significant relevance with the newly discovered SAD DNS attack.
The attack was presented for the first time at ACM Conference on Computer and Communications Security (CCS’20) in November 2020 and described in a paper titled “DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels“. It is a serious security problem that large DNS providers have in the meantime largely solved. This threat is peculiar as it leverages fundamental flaws, such as network side-channel in the networking stack of operating systems.
Together with vulnerable DNS software, any networking application that uses DNS to retrieve the IP address of peers/servers is potentially affected. According to researchers of the University of California Riverside, 35% of open resolvers are vulnerable, as well as most public resolvers and routers of well-known brands. 85% of the most popular free public DNS services have been exposed to these types of attacks.
SAD DNS attacks can target vulnerable software such as BIN, Unbound, and dnsmasq, which are widely used in Linux and other operating systems. An important fact is that the greatest vulnerability appears when the operating system and the DNS server network are configured to allow ICMP error messages. Only the ISP or DNS provider can actually detect a potential attack of SAD DNS.
How can you prevent a SAD DNS attack?
Let’s start with some good news. Since the discovery of SAD DNS, this type of DNS cache poisoning has been largely stopped by modern defense measures like DANE and DNSSEC. However, these DNS security methods have not been implemented by everyone, so these types of attacks are still ongoing.
To prevent the SAD DNS attack you could use the DNS Cookie RFC 7873 or disable the outgoing ICMP responses but you have to take into account you will lose some network diagnostics and troubleshooting functions.
But, if implemented correctly, DNSSEC is probably the best method to stop SAD DNS as it ensures the DNS responses are valid. To do this it signs DNS records with cryptography and verifies their authenticity. The response is digitally signed only when it comes from an authoritative DNS server.
How to keep your DNS communications safe
Today the defenses have been improved and DNS servers have been mostly patched to prevent such attacks. Nonetheless, there are several countermeasures you can adopt to assure a safer DNS space:
- Use a server that randomly generates a packet ID and a communication port number.
- DNS servers are subject to vulnerabilities. Keep your software updated so that newly discovered vulnerabilities don’t get exploited. Updated versions of DNS come with cryptographically secure port randomization and transaction IDs to help prevent DNS attacks. Always make sure the server you are using is up-to-date.
- Use DNSSEC, which supports origin authentication and integrity checking for each request through digital signature mechanisms.
- Actively monitor DNS data and keep an eye out for new patterns, such as the appearance of a new external host, which might signal the presence of an attacker.
- Establish a password policy, educating your employees in using strong passwords and keeping them safe. A single weak router password could jeopardize every device and user within the organization.
- Check the HTTPS flag, which must always be in the address bar of the browser. This lets you know that the site is valid. If the appearance of the HTTPS flag changes, it is a sign that a cyber attack has begun.
DNS is a backbone of the internet but it is not a safe system
Much of the internet still relies on the DNS as a source of integrity but it is exposed to attacks that can seriously endanger parts of the web experience. For example, the DNS is crucial for TLS, as well. TLS certificates are issued upon ownership of a domain. A failure in DNS security can lead to fraudulent certificates, compromising the public key cryptography.
The newly discovered side-channel vulnerability is not the last of a series of flaws in the networking protocols. In early 2021, a new version of the NAT-slipstreaming by Samy Kamkar was discovered and the Israeli company JSOF detected a total of seven bugs in dnsmasq: three allow DNS cache poisoning attacks and four opens to buffer overflow vulnerabilities.
They were dubbed collectively DNSSpooq. As the researchers reported, these vulnerabilities could lead to multi-staged attacks and be extremely effective since dnsmasq is also widely used.
The DNS is a fundamental element of the internet, yet it is an insecure workspace and its vulnerabilities are usually critical. In the past years, there have been many proposals to switch to another system. For example, the focus has been recently on a system based on blockchain technology. But at this point, all these ideas remain mere speculations.
When it comes to the secure authentication of DNS data, InterNetX is two steps ahead. InterNetX offers DNSSEC for several TLDs through AutoDNS to guarantee the authenticity of requested data in the DNS.
As an InterNetX customer, you can use DNSSEC for several TLDs through AutoDNS.
Register Domains with DNSSEC in AutoDNS 
