NXNSAttack

The NXNSAttack is a new vulnerability that exploits the way DNS recursive resolvers operate when receiving NS referral response that contains nameservers but without their corresponding IP addresses (i.e., missing glue-records). The number of DNS messages exchanged in a typical resolution process might be much higher in practice than what is expected in theory, mainly due to a proactive resolution of name-servers’ IP addresses. This inefficiency becomes a bottleneck and might be used to mount a devastating attack against either or both, recursive resolvers and authoritative servers. The NXNSAttack is more effective than the NXDomain attack: i) It reaches an amplification factor of more than 1620x on the number of packets exchanged by the recursive resolver. ii) Besides the negative cache, the attack also saturates the ’NS’ resolver caches.

A responsible coordinated disclosure procedure has been performed following the discovery of the NXNSAttack described in the paper below. Several DNS software vendors and service providers have adopted measures to protect against the destructive measures of the NXNSAttack.

This work has been accepted to USENIX Security 2020

NXNSAttack was discovered and reported by:

  • Lior Shafir, Tel Aviv University
  • Yehuda Afek, Tel Aviv University
  • Anat Bremler-Barr, The Interdisciplinary Center, Herzliya




The Amplifier - variants a,b

The core building block of the NXNSAttack is the amplifier, which is composed of three components: two attacker components and one innocent recursive resolver. The two attacker’s components are a client and an authoritative name-server. Essentially the attacker issues many requests for sub-domains of domains authorized by its own authoritative server (step 1 above). Each such request is crafted to have a different sub-domain to make sure it is not in the resolver’s cache, thus forcing the resolver to communicate with the attacker’s authoritative server to resolve the queried subdomains (step 2). The attacker authoritative name-server then returns an NS referral response with n name-server names but without their glue records (step 3), i.e., without their associated IP addresses, forcing the resolver to start a resolution query for each one of the name-server names in the response, whether these name-servers are in-bailiwick or out-of-bailiwick because it does not have their IP addresses in its cache (step 4). The attacker’s authoritative referral response issues n new and different delegated name-servers each time it receives a query for a sub-domain from the recursive resolver.

Double Amplifier - variant c

Illustration of the double amplification attack using self delegations in the first referral response. This attack variant (c) reaches a firepower of 19,980.

Here the attacker uses the self delegations technique to increase the number of concurrent referrals to the ROOT name-servers. In our empirical tests, the victim processes up to 81,428 packets (14,126,945 bytes) for each client request (and corresponding 75 referral packets) that the attacker generates (it is “only” 81,428 because many were lost).

Who was affected? Where can I find official infos/security advisories of involved/affected companies?

Link
ISC BIND  Security Advisory    /     CVE-2020-8616
NLnet Labs Unbound  CVE-2020-12662
NIC.CZ Knot Resolver  Blog Post    /     CVE-2020-12667
PowerDNS  Security Advisory
Google
Microsoft  Security Advisory
Cloudflare
Amazon
Oracle (DYN)
Verisign
Quad9
ICANN



Acknowledgements

We would like to thank Michael McNally and Cathy Almond of ISC, Ralph Dolmans, Wouter Wijngaards and Benno Overeinder of NLnet Labs, Petr Spacek of NIC.CZ, Francis Perron of Google, Remi Gacogne and Peter van Dijk of PowerDNS, John Todd of Quad9, Tim April and Ralf Weber of Akamai and James Adair and Matthew Pozun of Verisign for their cooperation and helpful discussions upon disclosing this issue, as well as Eyal Ronen and Yair Kaldor for their help with this project.