Side channel AttackeD (SAD) DNS

DNS is a protocol unknown by most users but it’s very important for the Internet because domain names have to be resolved to IP addresses. It’s an essential service. The DNS service is a very important protocol which has to be managed, monitor and protected. I’ve already written about DNS Security, DNS performance testing tools, EDNS(0) - Extension Mechanisms for DNS as well as DNS over HTTPS (DoH) and DNS over TLS (DoT). I’ve even written about how to configure DoH & DoT to DNS Proxy with F5 LTM. I’m going to write today about the SAD DNS attack.

First of all, we have to understand what is a DNS Cache Poisoning Attack. It is an attack in which corrupt DNS data is introduced into the DNS resolver’s cache, causing the name server to return an incorrect result record. DNS uses the UDP protocol for queries and responses. There is no handshake with the UDP protocol. Therefore, DNS responses can be spoofed by an attacker and, thus, an attack can inject forged DNS entry. This is one way to execute a DNS Cache Poisoning Attack. There is another way, which is accessing the DNS resolver server to change DNS resources. Anyway, it’s difficult to execute this attack but if there is no DNS protection, it can be done. 

DNS Cache Poisoning Attack

The DNS protocol has already changed several times to protect users to the DNS Cache Poisoning attack. For instance, prior to 2008, recursive resolvers used port 53 to send and receive messages to authoritative nameservers. This made guessing the source port trivial and the only variable an attacker needed to guess to forge a response to a query was the 16-bit message ID. Therefore, the Kaminsky’s attack was simple to run. The DNS protocol was changed to run over randomized source ports for security reasons.

Recently, UC Riverside and Tsinghua Universities has announced a new attack called SAD DNS (Side channel AttackeD DNS). This is a new way to defeat the source port randomization. Thanks to ICMP error messages, the attacker could ask the server which port number is being used for a pending query, that would make the construction of a spoofed packet much easier. However, this attack scenario isn’t easy to perform, but becomes totally possible when all the planets are well aligned. For instance, it requires DNS servers answer ICMP messages under specific conditions.

SAD DNS

If you are a network engineer who manage DNS forwarder or recursive DNS resolver, you should cosider upgrading your Linux Kernel, which uses unpredictable rate limits, blocking the outgoing ICMP “port unreachable” messages with a firewall, and keeping your DNS software up to date. In addition, configuring DNSSEC is a best practice because it is designed to protect against this type of attack.

To sum up, SAD DNS attack is not easy to perform but we should know this kind of attack to harden DNS servers with security protections. This is the best way to avoid attacks like this one.

How are you protecting your DNS servers?