logo Agence nationale de la sécurité des systèmes d’information

Agence nationale
de la sécurité
des systèmes d’information

You are here : Home > The ANSSI > Publications > Scientific publications > Conference > Abusing anti-DDoS mechanisms to perform DNS cache poisoning

Abusing anti-DDoS mechanisms to perform DNS cache poisoning

11 October 2013
Démonstration d’un détournement possible de technologies anti-déni de service distribué (DDoS) Imprimer Les fils d’actualité RSS de Envoyer cette page Réduire la taille du texte Agrandir la taille du texte

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.

PDF - 933.5 kb
PDF - 933.5 kb

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.

  1. Who has confirmed the vulnerability?

    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.

  2. Is my hosting infrastructure vulnerable to this attack?

    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).

  3. What software currently implements ANSSI recommendations regarding this vulnerability?

    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.

  4. How can I protect my domain names from this attack?

    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.

  5. Is always answering queries safe with respect to packet-per-second DDoS attacks?

    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.

  6. Does always answering queries increase the CPU or network consumption?

    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%.

  7. Did ANSSI produce a proof of concept of the attack?

    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.

  8. Who are the potential targets of such attacks?

    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.

  9. What has ANSSI done to improve the security of the DNS?

    ANSSI led a 4 months alert campaign, warning DNS software vendors and critical DNS operators (such as the root operators and several TLD operators).

FRENCH REPUBLIC | ANSSI © 2014 | Contact Us | Site Map
French governement Legifrance French civil service