Hey, guys! How’s everybody doing? I know I’ve been MIA for some time but I’m back now!
In today’s blog, we’re going to cover a serious issue that is threatening the entire infrastructure of the Internet as we know it.
It’s been 12 years since DNS server cache poisoning was brought to light and largely secured. However, security researchers at the University of California, Riverside, and Tsinghua University in Beijing have proven us wrong. Apparently, DNS resolvers can still be poisoned.
Dubbed "SAD DNS attack" (short for Side-channel AttackeD DNS), this technique uses side-channels, controlled by a malicious actor, to overcome common defenses that have worked against classic DNS cache poisoning attacks. Tracked as CVE-2020-25705, the findings were presented at the ACM Conference on Computer, and Communications Security (CCS '20) held early this month.
Scary, right? The researchers' findings don't get any better from here, either. So, let’s delve deeper to understand what exactly is this SAD DNS, just how severe its impacts are, and how to better protect our machines and infrastructure from this attack.
Hold up, what’s DNS cache poisoning?
Valid question! Let’s get the basics down first.
DNS cache poisoning is where a malicious actor intercepts the query of a DNS resolver or forwarder and injects a malicious IP address for a target domain in the resolver’s cache. Whoever who queries the DNS resolver now for the compromised domain will be redirected to the attacker’s server.
When DNS cache poisoning was first found back in 2008, it was possible due to the DNS requests between resolvers and upstream servers being done on a fixed port and used a 16-bit transaction ID. Attackers took advantage of this by initiating queries and brute-forcing responses on all possible channels.
This problem was solved by upgrading transaction IDs to 32 bits and randomizing the ports, that made it virtually impossible to brute-force DNS cache poisoning
Now, what is the SAD DNS attack?
Side-channel AttackeD DNS attack is a technique that enables an attacker to carry out an off-path attack, rerouting any traffic originally destined to a specific domain to a server they control - that allows them to eavesdrop and tamper with the communications.
Figure 1: SAD DNS attack
The researchers say:
"This represents an important milestone — the first weaponizable network side channel attack that has serious security impacts. The attack allows an off-path attacker to inject a malicious DNS record into a DNS cache."
This security flaw affects operating systems:
- Linux 3.18-5.10
- Windows Server 2019 (version 1809) and newer
- macOS 10.15 and newer
- FreeBSD 12.1.0 and newer
How does it happen?
The internet control message protocol (ICMP) plays a vital role as the SAD DNS uses it as a side-channel to aim at DNS resolvers and forwarders. Even though ICMP is not directly involved in DNS resolution, the researchers were able to play around and manipulate error messages produced by ICMP to figure out which ports are occupied and de-randomize the port used for DNS resolution.
Figure 2: Discovering open source ports that are used to initiate DNS queries
As demonstrated in Figure 2, SAD DNS leverages a side channel in the network protocol stack to scan and discover which source ports are used to initiate a DNS query and then insert a huge number of spoofed DNS replies by brute-forcing the TxIDs.
To add more context to this, the researchers utilized a channel used in the domain name requests to narrow down the exact source port number by sending spoofed UDP packets - each with different IP addresses - to a victim server and deduce whether the spoofed probes have hit the correct source port based on the ICMP responses received (or lack thereof).
Something interesting about this port scan method is that it can achieve a scanning speed of 1,000 ports per second. That means it only takes a little over 60 seconds to enumerate the entire port range consisting of 65536 ports. With the source port thus de-randomized, all a malicious actor has to do is to inject a malicious IP address to redirect website traffic and successfully pull off a DNS cache poisoning attack.
SAD DNS attacks predominantly work on local resolvers such as routers in universities, airports, and shopping centres. However, the researchers have discovered that public resolvers such as Cloudflare’s 184.108.40.206 and Google’s 220.127.116.11 were vulnerable to the attack.
In their research paper, the researchers have wrote:
“From our measurement, we find over 34% of the open resolver population on the internet are vulnerable (and in particular 85% of the popular DNS services including Google’s 18.104.22.168).”
They also added that they were able to validate the proposed attack with positive results against a variety of server configurations and network conditions.
The source code for SAD DNS attack was pulled back?
Yes, it was!
The researchers had initially published the source code for the SAD DNS attack on Github but the impact of their findings were so dire that they had to take it down.
Keyu Man, the lead author of the paper, told The Daily Swig:
“We removed the code from GitHub to protect those vulnerable servers and give them time to fix the vulnerability. We will put the code on GitHub when we feel it’s ok to do so … This attack will make the infrastructure of the internet vulnerable again, since every application would use DNS to get IP addresses. Adding and enforcing security features on old protocols is still a task that cannot be ignored [on] the internet today.”
Since Cloudflare’s 22.214.171.124 was also affected by this flaw, Nick Sullivan, head of research at Cloudflare, wrote in a blog:
“We’ve implemented an additional mitigation to 126.96.36.199 to prevent message ID guessing – if the resolver detects an ID enumeration attempt, it will stop accepting any more guesses and switches over to TCP. This reduces the number of attempts for the attacker even if it guesses the IP address and port correctly, similarly to how the number of password login attempts is limited.”
How to deal with the SAD DNS attack?
The researchers advocate disabling outgoing ICMP responses and setting the timeout of DNS queries more aggressively. For example, perhaps the setting could be so that's less than a second. This way the source port will be short-lived and disappear before the attacker can start injecting rogue responses. The downside, however, is the possibility of introducing more re-transmitted queries and overall worse performance.
Besides that, they have also put together a tool to check for DNS servers that are vulnerable to this attack. In addition, the group worked with the Linux kernel security team for a patch that randomizes the ICMP global rate limit to introduce noises to the side channel.
The researchers say:
“The research presents a novel and general side channel based on [the] global ICMP rate limit, universally implemented by all modern operating systems. This allows efficient scans of UDP source ports in DNS queries. Combined with techniques to extend the attack window, it leads to a powerful revival of the DNS cache poisoning attack."
That’s it for the blog today, y’all! Feel free to drop comments and share this blog if you found it useful.
Stay safe and stay tuned.
Until next time, friends!
Credits: The Daily Swig & The Hacker News