SAD DNS makes cache poisoning possible again

SAD DNS has revived the Kaminsky attack from 2008, which allows attackers to poison DNS caches with false information. The remedy that was devised at the time has now been overturned: a smart method makes it possible to ascertain the outgoing UDP port of the DNS resolver. How does SAD DNS work and how can you prevent it?

DNS Cache poisoning: an old problem

As a reminder, and as described by Cloudflare: the DNS system and protocol ensure, in short, that domain names are linked to IP addresses in natural language. The DNS protocol always comprises a set of messages: a request or query and a response or reply. These messages are exchanged over a network between machines, by means of a transport protocol. 

The most commonly used transport DNS protocol is UDP. The major advantage of UDP is that it is quick and everywhere and does not require any session setup. However, without DNSSEC there is no authentication which actually means that anyone could send a reply to a request with false information about the associated IP address . That would not be possible with other DNS transport protocols such as TCP, or even TLS or HTTPS. 

To avoid having to look up the corresponding address in the DNS tables for each new request, the results of DNS queries are temporarily stored in the cache of caching name servers. When a caching DNS server keeps such false reply in its cache, it is known as ‘DNS cache poisoning': this false information continues to exist in the cache as long as the TTL (Time To Live) lasts.

This phenomenon can lead to a lot of abuse and means visitors who enter a domain name in their browser may be redirected to a fake version of the website they want to visit, for example, where they may be victims of fraud, etc. 

Such attacks are targeted against different types of servers in the DNS hierarchy that use DNS caching, i.e. on the level of public DNS resolvers, internet service providers and telecom operators, companies that run their own resolver even on home gateway level, the cache of private persons. On all these levels there is a risk that false records are injected which redirect the user to insecure websites. 

Kaminsky attack in 2008 quickly remedied

The DNS system actually does have a tactic against false replies: the first two bytes in the message must be the same in both query and response. When a method was found in 2008 to guess those IDs, which was given the name Kaminsky attack a solution was found, i.e. source port randomisation. By using a random source port, the attacker not only had to guess the IDs, but also the source port. This increased the number of attempts required for a successful attack from tens of thousands to over a billion. It made this kind of attack less interesting which is why this method of attack has not been used much over the last years. 

SAD DNS has revived cache poisoning 

However, researchers of UC Riverside and Tsinghua University recently discovered a new method of attack: SAD DNS or Side Channel AttackeD DNS. This uses ICMP rate limiting, a way to prevent a server misusing a reflection attack, by limiting the number of ICMP responses a server will provide in a given time. 

SIDN.nl clearly explains how the principle works. If we suppose the limit is set to a maximum of 1,000 messages per second, the attacker is able to scan all 65,000 UDP ports in blocks of a thousand, and see in which block the outgoing port of the DNS resolver is located. For this he first sends 1,000 false DNS responses from a fake address to all ports in that block. He will not see the ICMP error messages because they go to the fake address. But if he sends a 1,001st message within the same second, this time from his own real IP address, and still gets an ICMP response back, he knows that the right port is within that series of a thousand ports. The fact that he received a message back at all means that the limit of a thousand error messages had not been reached, and the correct port is within that series of 1,000 ports.

This nullifies the port randomisation protection against the Kaminsky attack, because now all the attacker has to do is try to find out the 65,000 different transaction IDs. 

What action must you take?

The maintainers of the linux kernel released a patch that deals with the problem of the rate limits by randomising them. 

However, this is only an ad-hoc solution. A more structural way to prevent cache poisoning is the use of DNSSEC. Because a non-secured resolver accepts information as long as it is offered at the right time, via the correct port, and is provided with the correct transaction ID by the correct sender. But they can be guessed or spoofed, just like the sender's name. 

However, a resolver working with DNSSEC (a validating resolver) will not accept this fake information, because he will also base himself on the correct digital signature.

For DNS cache managers such as telecom operators, ISPs (home NAT gateways), company network administrators we advise:

• Apply the kernel patch as soon as possible (kernel version > 5.10)
• If you are unable to upgrade to the latest kernel, SAD DNS attacks can also be rendered impossible by blocking outgoing ICMP messages (more specifically, type ICMP port-unreachable). 
• If you operate a caching resolver behind a NAT device (Network Address Translation) such as routers, remember to patch these NAT devices (or to implement the aforementioned workaround). The attack may also target these devices. That was picked up by our own DNS Belgium engineers, and confirmed by the research. It is important to know that this attack vector works via the NAT device, even if the caching DNS resolver is patched (or a workaround was configured).
• Underline the importance of DNSSEC to your customers. Read more about DNSSEC and how DNS Belgium implements this extra security.

Note: Some resolver software already has an additional detection mechanism for cache poisoning: this forces the DNS communication to fall back on the transport protocol, TCP. And consequently this makes the SAD DNS attack impossible. 

We generally advise registrants and internet users to:

• Request your ISP or registrar to activate DNSSEC. This is the ultimate solution to guarantee the integrity of a look-up record, and ensures that visitors to your website are not redirected. Your visitors do still have to use a DNSSEC validating resolver to effectively enjoy the protection offered by DNSSEC.
• Most providers do indeed provide DNSSEC for domain names, and you only have to activate it.