Why SAD DNS Isn’t So Sad with SOLIDserver

DNS is at the middle of any communication intent, making it a popular target for threat actors, who always manage to find new ways to attack such a critical service. Sometimes, it is not the engine itself which is faulty, but another piece of the communication chain. Being able to manipulate a DNS record in a recursive cache is very powerful as it allows forwarding traffic to a different place than the expected one – leaving an open door to complex phishing and attacks (e.g on banking sites, news sites, corporate image…). This is the story behind the SAD DNS attack which targets most engines under the Linux operating system. Thankfully, EfficientIP SOLIDserver is not impacted by this matter thanks to specific countermeasures already implemented in the system at the end of 2018.

Numerous attacks have been performed in the past to poison the DNS cache, as the impact is really beneficial for threat actors. Multiple defenses have consequently been specifically developed to mitigate cache poisoning attacks (0x20 encoding, source port randomization, TxIDs, DNSSEC, …). When all are implemented, the task of poisoning a DNS cache becomes really hard. However, some DNS recursive servers are lazily administered, leaving a chance for threat actors to easily perform their attacks.

SAD DNS: Cache Poisoning through open ports

More recent interest in how to improve the cache poisoning injection phase is known under the term “SAD DNS”. The main idea is to increase efficiency by using detected open ports to inject the poisoning traffic. The detection is mainly based on analyzing the “ICMP port unreachable” messages that a DNS recursive server may send whenever it receives a message to a closed port. And when speaking here about the DNS server, it is more accurately the operating system running the service which is responsible for sending such ICMP information frames.

By using a specific side channel introduced in the Linux kernel (and potentially in other kernels) to limit the number of ICMP replies that can be sent during a period of time, it is possible to get information about the fact that open ports in a well known list are available. This leads to a more efficient way to detect which port to attack – potentially the DNS port expecting an answer for an upstream DNS Server in the recursion chain (affecting recursive and forwarder servers).

The attack also requires there to be a delay between the query and the answer from the upstream DNS server, in order to have more time to execute the injection – there are still a lot of ports to test and some intrinsic protection in DNS traffic to bypass. This is tricky because it also needs the recursion to use an authoritative server controlled by the attacker.

The UC Riverside and Tsinghua Universities study focused on specific DNS forwarders that may be used at home, in small stores, on the internet open DNS relay and also at a few big DNS providers. Their attack scenario is not easy to perform, but becomes totally possible when all the planets are well aligned. The first planet that requires this alignment is the fact that ICMP port unreachable messages are sent back from the DNS server to the attacker. Not all systems are performing this normal behavior. Some hardened servers put protections in place such as disabling specific IP routing scenarios, or more simply by not answering ICMP messages under specific conditions. This is the point where security crosses the line of protocol design for the good of the service.

Patching and DNSSEC help limit the threat

For Linux DNS servers (which are the main targets in the attack study), a kernel patch is already available to add some entropy in the amount of ICMP messages that are sent, making it more difficult to guess whether any ports are open or not during this SAD DNS attack. This requires either patching the kernel or at least applying the global patches on the server – which is obviously not the case everywhere and highly improbable on open recursive DNS servers over the internet that aren’t managed at all.

In addition to applying patches if your DNS is running on a Linux server, we recommend you apply standard protection mechanisms like DNS cookies. To take the security a step further, we also recommend setting up DNSSEC on authoritative domains, since the best way of avoiding poisoned cached records in all the recursive servers is by implementing DNSSEC validation of record content.

Ensure Service Continuity with SOLIDserver DNS

In 2018, a set of protection rules were introduced into SOLIDserver DNS for ensuring service continuity by not always answering ICMP messages – therefore it is not subject to this kind of attack, protecting the DNS recursive service. As a state of the art DNS solution, we at EfficientIP apply every technique we think may benefit our clients, as soon as possible. This is a major reason why ISPs and telcos worldwide are relying on EfficientIP solutions for their operations. In addition, the existing arsenal in the Guardian engine can even protect more efficiently against awkward situations like long response time from authoritative servers on specific records, making it very difficult for cybercriminals to exploit them.