SAD DNS: new DNS cache poisoning technique emerges
DNSSEC remains the structural solution for vulnerabilities of this kind
DNSSEC remains the structural solution for vulnerabilities of this kind
Last week saw the return of the DNS cache poisoning attack for which Dan Kaminsky found an effective exploit back in 2008. The SAD DNS attack uses a new side-channel to inject fake DNS information into a caching resolver. Hence the name – Side-channel AttackeD DNS. According to the discoverers, a third of all caching resolvers are vulnerable to the attack, as are the majority of major public DNS services.
Operators of caching resolvers need to patch/update their systems: the discoverers of SAD DNS have made a Linux patch available, which is also included in the kernel from version 5.10. If patching isn't (yet) possible, (temporary) blocking of outbound ICMP messages will protect relevant systems pending a more permanent solution. End users who have their systems set up to use one of the big public DNS services (Google Public DNS (8.8.8.8), 1.1.1.1, Quad9 (9.9.9.9) or the like) as their resolver are advised to do nothing for the time being. Such services are likely to be provided with protection in the near future. You can check whether the resolver you use is vulnerable to SAD DNS by using a link on the saddns.net website [PowerDNS Recursor, 1.1.1.1].
The classic DNS cache poisoning attack and the Kaminksy attack are described in our DNSSEC FAQs. With SAD DNS, an attacker establishes what a DNS resolver's outbound UDP port is by taking advantage of the protective rate limiting functionality for ICMP messages built into all network stacks. If, for example, the limit is set at 1,000 messages per second (as with Linux), the attacker can test all 65,000 UDP ports in blocks of a thousand to find out which block includes the DNS resolver's outbound port. That involves first sending 1,000 fake DNS responses from spoofed IP addresses, one to each port in the block. The resulting ICMP error messages are lost because the sender's address is spoofed. However, if the attacker sends a 1,001st message from their real IP address within the same second and gets one final ICMP response, they know that the correct port is in that series of 1,000 ports. Otherwise the limit of 1,000 ICMP error messages would have been exceeded for the second in question. The second diagram in this article shows how the tactic works. By establishing what outbound UDP port the resolver is currently using, the attacker negates the original strategy for preventing classic DNS cache poisoning attacks and Kaminsky attacks, namely source port randomisation. Once the port is known, the attacker merely has to try each of the 65,000 different transaction IDs in order to inject fake DNS information (by means of a Kaminsky-style attack). In their publication, the researchers explain how they were able to extend the window for performing a complete attack from a few tens of milliseconds to many tens of seconds. Fortunately, the new problem is relatively easy to fix. The Linux patch introduces a substantial degree of randomness to the limit of 1,000 ICMP messages.
A more structural solution is of course to use DNSSEC validation. 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. However, a validating resolver would never accept the same false information if it didn't bear a valid digital signature.