New SAD DNS Attack Variant to Substitute Fake Data in the DNS Cache

A team of researchers at the University of California, Riverside, has published a new SAD DNS attack variant (CVE-2021-20322) that works despite protection added last year to block the CVE-2020-25705 vulnerability. The new method is broadly similar to last year's vulnerability, with the only difference being that it uses a different type of ICMP packet to check for active UDP ports. The proposed attack allows substitution of fictitious data in the cache of the DNS server, which can be used to replace the IP address of an arbitrary domain in the cache and redirect requests to the domain to the attacker's server.

The proposed method works only in the Linux network stack due to being tied to the peculiarities of the ICMP packet processing mechanism in Linux, which acts as a source of data leakage, which simplifies the determination of the UDP port number used by the server to send an external request. Changes blocking information leakage were accepted into the Linux kernel at the end of August (the fix was included in the 5.15 kernel and the September updates of the LTS kernel branches). The fix comes down to switching to using the SipHash hashing algorithm in network caches instead of Jenkins Hash. The status of fixing the vulnerability in distributions can be assessed on these pages: Debian, RHEL, Fedora, SUSE, Ubuntu.

According to the researchers who identified the problem, about 38% of open resolvers on the network are affected, including popular DNS services such as OpenDNS and Quad9 (9.9.9.9). With regard to server software, the attack can be carried out using packages such as BIND, Unbound, and dnsmasq on a Linux server. DNS servers running on Windows and BSD systems do not experience the problem. To successfully carry out an attack, it is necessary to use IP spoofing, i.e. it is required that the attacker's ISP does not block packets with a fake source IP address.

Recall that the SAD DNS attack allows you to bypass the protection added to DNS servers to block the classic DNS cache poisoning method proposed in 2008 by Dan Kaminsky. The Kaminsky method manipulates the small size of the DNS query ID field, which is only 16 bits. To find the correct DNS transaction ID required for hostname spoofing, it is enough to send about 7000 queries and simulate about 140 bogus responses. The attack comes down to sending a large number of packets to the DNS resolver with a fictitious binding to IP and with different DNS transaction identifiers. To prevent caching of the first response, each dummy response contains a slightly modified domain name (1.example.com, 2.example.com, 3.example.com, etc.).

To protect against this type of attack, DNS server manufacturers implemented a random distribution of source network port numbers from which resolution requests are sent, which compensated for the insufficient size of the identifier. After the implementation of protection, in order to send a dummy response, in addition to selecting a 16-bit identifier, it became necessary to select one of the 64 thousand ports, which increased the number of options for selection to 2 ^ 32.

The SAD DNS method drastically simplifies the determination of the network port number and reduces the attack to the classical Kaminsky method. An attacker can detect access to unused and active UDP ports by exploiting the leakage of information about the activity of network ports when processing ICMP response packets. The method allows reducing the number of enumeration options by 4 orders of magnitude β€” 2^16+2^16 instead of 2^32 (131_072 instead of 4_294_967_296). The leak of information that allows you to quickly determine active UDP ports is caused by a flaw in the code for processing ICMP packets with fragmentation requests (ICMP Fragmentation Needed flag) or redirection requests (ICMP Redirect flag). Sending such packets changes the state of the cache in the network stack, which allows, based on the reaction of the server, to determine which of the UDP ports is active and which is not.

Attack scenario: When a DNS resolver tries to resolve a domain name, it sends a UDP request to the DNS server serving the domain. While the resolver is waiting for a response, an attacker can quickly determine the source port number that was used to send the request and send a fake response to it, impersonating a domain-serving DNS server using IP address spoofing. The DNS resolver will cache the data transmitted in the fake response and, for some time, all other DNS requests for the domain name will return the IP address substituted by the attacker.

Source: opennet.ru

Add a comment