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:

 NXNSAttack Paper

 

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