During the DNS OARC Fall Workshops conference, taking place on the 5th and 6th of October, in Phoenix, Arizona (USA), the ANSSI has presented a way to abuse some denial of service (DDoS) countermeasures to ease DNS cache poisoning attacks.
Here follows the slides of the presentation.
In addition, this FAQ answers the most frequent questions regarding the vulnerability discovered by the ANSSI and details the countermeasures available to DNS operators.
Internet entities are regularly affected by Distributed Denial of Service (DDoS) of various scales. Several methods can be used to perform such attacks but the most recent public incidents were caused by throughput amplification via DNS servers. The attacker spoofs his victims IP address and sends some small-sized queries, to which DNS servers answer with larger DNS messages, thus generating an amplified traffic toward the victim.
In response to these incidents, members of the DNS community have developed solutions that filter out some DNS queries, sometimes leaving them unanswered. Some of these technologies have already been deployed by TLD operators and high-profile Internet actors. The ANSSI (French Network and Information Security Agency) has studied these solutions and observed that the lack of answers to some queries helps performing DNS cache poisoning attacks.
When a resolver sends a DNS query to an authoritative server, an attacker can try to poison its cache by sending forged answers. However, the attacker must answer before the authoritative and such an attack succeed with extremely low probability. On the contrary, when the authoritative server does not answer, the usual race between the authoritative server and the attacker does not occur, letting the latter send forged answers to the resolver during the whole timeout period. Known DNS cache poisoning attacks (such as Kaminsky attack) thus become much more efficient.
We have modeled the problem and have been able to establish that an attack against a resolver has a 50% chance to be successful after 8 hours with a throughput of 100Mbps.
A successful exploitation would allow an attacker to inject a forged DNS delegation and intercept traffic sent to a web site or an email server for all clients relying on the poisoned DNS resolver.
The ISC (Bind developers), NLNet Labs (NSD developers), the governmental CERT of the Netherlands (NCSC), and SIDN (responsible for the nl TLD) have all published statements confirming the vulnerability.
Every network infrastructure or DNS software that drops DNS messages is vulnerable to this attack, since it leaves some legitimate queries unanswered. In particular, open source authoritative name servers are vulnerable if they do not follow ANSSI recommendations and have incorrect default value (advisory bulletin CERTA-2013-AVI-506 published on September 9th, 2013. Firewalls are also vulnerable if they rate-limit incoming traffic or drop some specific queries (for instance, dropping what they consider as malformed queries).
The vulnerable software are listed in the CERTA advisory bulletin. To this day, only Knot version 1.3.0 and higher is using a safe configuration by default. For BIND and NSD, a recent version is needed and must be configured accordingly.
The short term solution is to ensure that every query sent by a legitimate resolver is answered. To distinguish legitimate queries from forged ones is difficult, so the simplest solution is to answer every query received by the authoritative nameservers hosting your domain names. The packet you send does not need to contain the actual answer to the query. It can be a truncated answer or a packet with the error code "REFUSED". A long term solution against cache poisoning attacks is the deployment of DNSSEC.
Current DDoS attacks leveraging the DNS are bandwidth-related DDoS. The DNS itself only offers a limited amplification factor in terms of packets, caused by IP fragmentation of large DNS answers.
Always answering DNS queries keeps the susceptibility of using DNS for packet-related DDoS under the susceptibility of several other protocols, including TCP.
ANSSI has performed laboratory experiments to measure resource consumption of DNS software using RRL with a slip value of 1 (recommended by ANSSI), and a slip value of 2 (default value on some implementations).
Two scenarios have been tested:
Case 1: the attacker attempts to DDoS the RRL-protected authoritative name server
Case 2: the attacker attempts to DDoS a resolver by making it send queries to an RRL-protected authoritative name server
In the first case, the download and upload bandwidth consumptions are tightly related. In most cases, the download capacity is greater than the upload capacity. In this case, the upload capacity is therefore irrelevant and regardless of the RRL configuration, the exceeded download capacity problem should be handled upstream, for instance at the transit provider level. From the computational point of view, using a slip value of 1 negligibly increases the CPU consumption by less than 5%.
In the second case, using a slip value of 2 actually increases the network consumption because of the multiple retries that are performed by the resolver when no answer is received from the authoritative nameserver. Since the number of queries to handle is greater with a slip value of 2, using a slip value of 1 actually decreases the CPU consumption of the resolver by up to 20%.
Yes. ANSSI has tested the attack in laboratory. Results are detailed in the conference slides. However, the code and tools used to perform these proof of concept attacks will not be published.
In order to poison the cache, the attacker must send a large amount of spoofed packets toward the targeted resolver. This attack may therefore go unnoticed only by large Internet operators that are already managing very high traffic load. This notably includes large ISPs. This attack may also be performed from inside the LAN of companies with insufficient filtering rules on their firewalls.
ANSSI led a 4 months alert campaign, warning DNS software vendors and critical DNS operators (such as the root operators and several TLD operators).