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?