|
Co-authored by Ken Linscott, product director, Domains and Security, Mark Flegg, global director, Security Services, and Letitia Thian, marketing manager
There is a new threat in town known as “SAD DNS” that allows attackers to redirect traffic, putting companies at risk of phishing, data breach, reputation damage, and revenue loss.
No, it isn’t the domain name system (DNS) feeling moody, but an acronym for a new-found threat—“Side-channel AttackeD DNS” discovered by researchers that could revive DNS cache poisoning attacks.
The DNS operates like a telephone book of the internet, translating domain names into IP address, so users can easily look for websites with names instead of a string of numbers.
For efficiency, the IP address is now stored at the resolver to return the same address the next time it receives the same query—this is known as caching. Storing this data means the next time someone asks for the IP address of a domain name, it can answer very quickly from its own records. How long the cache is maintained is determined by the Time to Live (TTL) detailed within your zone file.
It is this cache of data that can be compromised. In DNS cache poisoning, the resolver (in this case the ISP) is corrupted by an attacker to return a spoofed IP address, which sends users to the wrong place, such as a fraudulent website instead of the intended legitimate one. So a user typing a legitimate domain name could unwittingly land on a phishing website, or one laden with malware. With the ability to reroute traffic, attackers can eavesdrop, steal data, and tamper with communication.
No, this vulnerability in the DNS protocol was discovered in 2008 by security researcher Dan Kaminski. He noticed a flaw in the way the DNS is architected with only 65,536 unique transaction IDs that accompany every DNS query used for validation. This allows an attacker to flood a resolver with fake DNS responses with transaction IDs, to guess the correct transaction ID of a DNS query via brute force method, and insert their own malicious spoof IP address in the DNS response.
This kind of attack can be stemmed using two mitigations:
Researchers at the University of California and Tsinghua University recently identified a vulnerability in DNS resolvers, where attackers can send data (UDP packets) to a DNS resolver, and based on the resolver’s (ICMP) responses in this side-channel, guess the right source port via brute force. Armed with the known source port and finite number of transaction IDs, together with a low adoption rate for DNSSEC globally2, attackers can now conduct DNS cache poisoning attacks again.
Only recursive DNS name servers are at risk from this attack. A company’s DNS at their registrar are authoritative name servers that are not prone to DNS cache poisoning. However, due to the nature of how the DNS works, companies are still susceptible to such attacks if recursive name servers—such as the ISP—are poisoned.
There have been various suggestions offered, however, there is one effective mitigation since the 2000s that has been largely neglected—DNSSEC.
The rate of adoption of DNSSEC has not increased significantly over the decades. In our 2020 Domain Security Report, the adoption of DNSSEC among the Forbes Global 2000 companies was only at 3%!
“Father of the internet,” Vint Cerf, says, “The industry also needs to push for speedier adoption of domain name system security extensions, or DNSSEC, to eliminate spoofing of the DNS system. This is a way to verify that the domain name and IP address combination obtained during the domain name lookup comes from a recognized source and has been digitally signed to assure the browser is using the correct destination internet address to reach the website intended. Domain registrars and hosting providers should make it one-step simple for website owners to enable DNSSEC for their sites.”3
SAD DNS is a real and immediate threat to companies around the globe who should now be escalating the implementation of DNSSEC with their DNS provider.
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byVerisign
Sponsored byCSC
Sponsored byWhoisXML API