NXNSAttack attack affecting all DNS resolvers

A group of researchers from Tel Aviv University and the Interdisciplinary Center in Herzliya (Israel) developed new attack method NXNSAttack (PDF), which allows you to use any DNS resolvers as traffic amplifiers, providing a degree of amplification up to 1621 times in terms of the number of packets (for each request sent to the resolver, 1621 requests can be sent to the victim's server) and up to 163 times in terms of traffic.

The problem is related to the peculiarities of the protocol and affects all DNS servers that support recursive query processing, including BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS Server и Unbound (CVE-2020-12662), as well as public DNS services from Google, Cloudflare, Amazon, Quad9, ICANN, and others. The fix was coordinated with the developers of the DNS servers, who simultaneously released updates to fix the vulnerability in their products. Attack protection implemented in releases
Unbound 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

The attack is based on the use by the attacker of requests referring to a large number of previously unseen dummy NS records, to which the definition of the name is delegated, but without specifying glue records with information about the IP addresses of NS servers in the response. For example, an attacker sends a request to determine the name sd1.attacker.com by controlling the DNS server responsible for the attacker.com domain. In response to the resolver's request to the attacker's DNS server, a response is issued delegating the determination of the address sd1.attacker.com to the victim's DNS server by specifying NS records in the response without specifying the IP of the NS servers. Since the mentioned NS server has not been previously encountered and its IP address is not specified, the resolver tries to determine the IP address of the NS server by forwarding a query to the DNS server of the victim serving the target domain (victim.com).

NXNSAttack attack affecting all DNS resolvers

The problem is that the attacker can respond with a huge list of non-repeating NS servers with non-existent fictitious names of the victim's subdomains (fake-1.victim.com, fake-2.victim.com, ... fake-1000.victim.com). The resolver will try to send a request to the victim's DNS server, but will receive a response that the domain was not found, after which it will try to determine the next NS server in the list, and so on until it has gone through all the NS records listed by the attacker. Accordingly, for one attacker's request, the resolver will send a huge number of requests to determine NS hosts. Because NS server names are generated randomly and refer to non-existent subdomains, they are not retrieved from the cache, and each attacker's request results in a flurry of requests to the DNS server serving the victim's domain.

NXNSAttack attack affecting all DNS resolvers

The researchers studied the degree of exposure to the problem of public DNS resolvers and determined that when sending requests to the CloudFlare (1.1.1.1) resolver, you can achieve an increase in the number of packets (PAF, Packet Amplification Factor) by 48 times, Google (8.8.8.8) - 30 times, FreeDNS (37.235.1.174) - 50 times, OpenDNS (208.67.222.222) - 32 times. More significant results are observed for
Level3 (209.244.0.3) - 273 times, Quad9 (9.9.9.9) - 415 times
SafeDNS (195.46.39.39) - 274 times, Verisign (64.6.64.6) - 202 times,
Ultra (156.154.71.1) - 405 times, Comodo Secure (8.26.56.26) - 435 times, DNS.Watch (84.200.69.80) - 486 times, and Norton ConnectSafe (199.85.126.10) - 569 times. For servers based on BIND 9.12.3, the amplification level can reach up to 1000 due to query parallelization. limit on the number of name resolution steps allowed per request.

There are two main defense strategies. For systems with DNSSEC proposed by use RFC-8198 to prevent DNS cache bypass as requests are sent with random names. The essence of the method is to generate negative responses without contacting authoritative DNS servers, using range checking through DNSSEC. An easier way is to limit the number of names that can be defined in the processing of a single delegated request, but this method can lead to problems with some existing configurations, since the limits are not defined in the protocol.

Source: opennet.ru

Add a comment