A group of researchers from Tel Aviv University and the Interdisciplinary Center in Herzliya (Israel) a new attack method (), which allows any DNS resolvers to be used as traffic amplifiers, achieving amplification factors of up to 1621 times in the number of packets (for each request sent to the resolver, up to 1621 requests can be sent to the victim's server) and up to 163 times in traffic.
The problem is related to the protocol's characteristics and affects all DNS servers that support recursive processing of requests, including (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), and (CVE-2020-12662), as well as public DNS services from Google, Cloudflare, Amazon, Quad9, ICANN, and others. The issue was coordinated with the DNS server developers, who simultaneously released updates to address the vulnerability in their products. Protection against the attack has been implemented in the releases
, , , .
The attack relies on the attacker using queries that reference numerous previously unseen fictitious NS records, which are delegated to determine the name but do not provide glue records containing information about the IP addresses of the NS servers in the response. For example, the attacker sends a request to resolve the name sd1.attacker.com while controlling the DNS server responsible for the domain attacker.com. In response to the resolver's inquiry to the attacker's DNS server, a reply is issued delegating the resolution of the address sd1.attacker.com to the victim's DNS server by specifying NS records in the response without detailing the NS servers' IP addresses. Since the mentioned NS server has not been seen previously and its IP address is not specified, the resolver attempts to resolve the IP address of the NS server by directing a query to the victim's DNS server servicing the target domain (victim.com).
The issue is that the attacker can respond with a huge list of unique NS servers with non-existent fake subdomain names of the victim (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 is not found, after which it will attempt to determine the next NS server on the list, continuing until all the NS records listed by the attacker have been exhausted. Thus, for each request from the attacker, the resolver will send a huge number of requests to identify NS hosts. Since the NS server names are generated randomly and point to non-existent subdomains, they are not cached, and each request from the attacker leads to a flood of requests to the DNS server serving the victim's domain.
Researchers have examined the susceptibility of public DNS resolvers to this issue and determined that sending requests to the CloudFlare resolver (1.1.1.1) can achieve a packet amplification factor (PAF) of 48 times, to Google (8.8.8.8) — 30 times, to FreeDNS (37.235.1.174) — 50 times, and to OpenDNS (208.67.222.222) — 32 times. More notable figures 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, due to parallelizing requests, the amplification level can reach up to 1000. In Knot Resolver 5.1.0, the amplification level is about several dozen times (24-48), as the determination of NS names is performed sequentially and hits an internal limit on the number of resolution steps allowed for a single request.
Two main defense strategies are highlighted. For systems with DNSSEC to use to prevent cache bypass since requests are sent with random names. The essence of the method is generating negative responses without querying authoritative DNS servers, using range checks through DNSSEC. A simpler method is to limit the number of names that can be resolved per delegated request, but this method may cause issues with some existing configurations, as limits are not defined in the protocol.
Source: opennet.ru
