New Domain Name System vulnerability revealed
Linux and popular DNS software are vulnerable to new SAD DNS cache poisoning method
Exactly a year after publishing the first SAD DNS attack method, the same research team has revealed a new way of mounting a cache poisoning attack on the Domain Name System (DNS). At the conceptual level, the method is the same as the previous attack strategy: the researchers have discovered a new side channel via which false DNS information can be efficiently injected into a caching resolver. The method has therefore been dubbed SAD DNS 2.0. According to the researchers, it's mainly Linux systems that are vulnerable to the attack, along with popular DNS software such as BIND, Unbound and dnsmasq (all of which are Linux-based). Of the major public DNS services, half proved to be vulnerable, including Cisco's OpenDNS and Quad9 (9.9.9.9). While pointing out that the new SAD DNS variant can be countered in various ways, the researchers stress that DNSSEC is the best defence against cache poisoning. However, the effectiveness of DNSSEC does depend on universal adoption.
DNS cache poisoning
Like the first SAD DNS attack, SAD DNS 2.0 builds on the Kaminsky attack method published in 2008 by late security researcher Dan Kaminsky. In a Kaminsky attack, a caching resolver is injected with false DNS information by targeting it with DNS queries and spoofed false DNS responses. A DNS cache poisoning attack of that kind can be prevented by source port randomization (as defined in RFC 5452). That involves configuring the resolver to change the outbound UDP port for every query, which makes the spoofing of false DNS responses practically impossible.
Side channel attacks
The first SAD DNS attack negated the protection afforded by source port randomization by identifying the momentary (ephemeral) outbound UDP port. That was done by (indirectly) counting the ICMP messages sent in response to spoofed DNS responses. Once the outbound UDP port has been identified, a Kaminsky-style attack can be mounted. The attack method is described in more detail in this article. Like the first SAD DNS attack, the new one involves identifying the resolver's ephemeral outbound UDP port. However, the side channels used to do that (hence the name 'Side channel AttackeD DNS') are different. For the latest variant, the researchers developed various side channel attacks on the basis of the 'ICMP frag needed' and 'ICMP redirect' messages. This 'ephemeral port scanning' method involves sending a series of spoofed ICMP messages to the resolver, and then checking whether the ephemeral port has been hit. On Linux, a valid ICMP message leads to modification of the 'next hop exception cache' (part of the network stack). And it's possible to ascertain whether a modification has been made by, for example, sending a simple ping message to the resolver in question. Once the ephemeral outbound UDP port has been identified, a Kaminsky-style attack is again mounted to obtain the DNS transaction IDs by brute force. Additional techniques can be used to frustrate the transmission and safe receipt of the correct response from the true authoritative name server, thus increasing the window for landing false DNS responses. Those techniques were previously described in the publication about the first SAD DNS attack.
DNSSEC: the structural solution
When the researchers tested the new ICMP/UDP-based side channel attacks, they were able to inject vulnerable resolvers with false DNS information within a few minutes. Further analysis revealed that FreeBSD (and therefore MacOS) was not vulnerable – for the intriguing reason that its network stack doesn't fully conform to the RFC, according to the researchers. Recent versions of Windows were found to be partially vulnerable. "SAD DNS 2.0 exposes another weakness in the DNS, which can be properly resolved only by using DNSSEC," says Berry van Halderen, lead developer at NLnet Labs. "The issue here isn't a flaw in the software, but a weakness in the DNS protocol itself, which can be exploited if DNSSEC isn't active." While pointing out that the new SAD DNS variant can be countered in various ways, the researchers stress that DNSSEC is the best defence against cache poisoning. A non-secured resolver will accept false information if it arrives at the right moment, on the right port, and accompanied by the right transaction ID from the right (spoofed) sender. By contrast, a validating resolver will never accept the false information if it doesn't bear a valid digital signature.