SAD DNS is a new variant of DNS cache poisoning that allows an attacker to inject malicious DNS records into a DNS cache, thus redirecting any traffic to their own server and becoming a man-in-the-middle (MITM).
SAD DNS was firstly reported by researchers from UC Riverside and Tsinghua University at the ACM Conference on Computer and Communications Security.
DNS poisoning is a classic attack which has usually been mitigated by randomizing the source port, which would require an attacker to guess both a 16 bit port number and a 16 bit DNS transaction ID, thus making an attack unlikely to succeed.
Surprisingly, we discover weaknesses that allow an adversary to "divide and conquer" the space by guessing the source port first and then the transaction ID (leading to only
2^16 + 2^16spoofed responses). Even worse, we demonstrate a number of ways an adversary can extend the attack window which drastically improves the odds of success.
The main factor enabling SAD DNS is not blocking outgoing ICMP responses. This makes it quite widespread, with most public resolvers being affected at the time of discovery, including the ubiquitous 8.8.8.8 and 1.1.1.1, and many private DNS services.
In theory, any DNS server running the newer version of popular operating systems without blocking outgoing ICMPs (only Windows blocks it by default) is also vulnerable.
Overall, according to figures provided by the team of researchers who discovered the vulnerability, up to 85% of popular DNS services and 34% of DNS services overall are vulnerable.
Cloudflare engineers Marek Vavruša and Nick Sullivan provided a great recount of what lies at the heart of SAD DNS, highlighting its intrinsic relationship with UDP, which is still the most common protocol used for communication between recursive DNS resolvers and DNS nameservers. As mentioned above, the only mechanisms available to the DNS protocol over UDP to increase message entropy are port randomization along with the use of a random transaction ID. Knowledge of both is required to construct a valid DNS reply.
Now, it turns out it is possible to defeat source port randomization by leveraging a mechanism of the Internet Control Message Protocol (ICMP) protocol, which is able to return a "port unreachable" message. This allows an attacker to reduce the number of possible source ports by knowing which ports are surely closed.
A single [ICMP] scan of the server effectively reduces the search space of valid UDP responses from 232 (over a billion) to 217 (around a hundred thousand), at least in theory.
This is not the whole story, though, since many resolvers use "connected" UDP sockets instead of "open" UDP sockets to exchange messages with a nameserver, which defeats the use of simple ICMP queries to detect which ports are used for that communication. But a more sophisticated approach using ICMP rate limit can be used to reveal whether a given port is open or not:
The attacker sends a bunch (large enough to trigger the rate limiting) of probe messages to the target, but with a forged source address of the victim. In the case where there are no open ports in the probed set, the target will send out the same amount of ICMP “port unreachable” responses back to the victim and trigger the rate limit on outgoing ICMP messages. The attacker can now send an additional verification message from its own address and observe whether an ICMP response comes back or not.
At this point the attacker has succeeded in leaking some information about the probed port and can narrow down their guess of which ports are used for the DNS exchange, thus significantly reducing the number of brute-force attacks required to construct a valid DNS reply.
In spite of its apparent simplicity, there are a number of hurdles making it hard to mount this attack, Cloudflare engineers note. These include knowing which IP addresses to target and the ability to complete the attack while the exchange with the victim is still ongoing.
Thus, while waiting for DNSSEC adoption to become widespread, which would significantly contribute to making DNS more secure, there are a number of mitigations that should be applied, including using unpredictable ICMP rate limits, included in Linux 5.10 kernel; firewalling ICMP "port unreachable" messages; and updating DNS software.