They discovered a new variant of SAD DNS to replace dummy data in the DNS cache

A group of researchers from the University of California at Riverside released Some days ago a new variant of the SAD DNS attack which works despite the protection added last year to block the CVE-2020-25705 vulnerability.

The new method is generally similar to last year's vulnerability and only differentiated by the use of a different type of packages ICMP to verify active UDP ports. The proposed attack makes it possible to substitute dummy data in the cache of a DNS server, which can be used to spoof the IP address of an arbitrary domain in the cache and redirect calls to the domain to the attacker's server.

The proposed method is operable only on the Linux network stack Due to its connection to the peculiarities of the ICMP packet processing mechanism in Linux, it acts as a source of data leaks that simplify the determination of the UDP port number used by the server to send an external request.

According to the researchers who identified the problem, the vulnerability affects approximately 38% of open solvers on the network, including popular DNS services like OpenDNS and Quad9 ( For server software, the attack can be carried out using packages like BIND, Unbound, and dnsmasq on a Linux server. DNS servers running on Windows and BSD systems do not show the problem. IP spoofing must be used to successfully complete an attack. It is necessary to ensure that the attacker's ISP does not block packets with a spoofed source IP address.

As a reminder, the attack SAD DNS allows bypassing added protection to DNS servers to block classic DNS cache poisoning method proposed in 2008 by Dan Kaminsky.

Kaminsky's method manipulates the negligible size of the DNS query ID field, which is only 16 bits. To find the correct DNS transaction identifier needed to spoof the host name, just send about 7.000 requests and simulate about 140.000 fake responses. The attack boils down to sending a large number of fake IP-bound packets to the system DNS resolver with different DNS transaction identifiers.

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

The method SAD DNS lets you radically simplify network port number determination and reduce attack to the classical method of Kaminsky. An attacker can determine access to active and unused UDP ports by taking advantage of leaked information about network port activity when processing ICMP response packets.

The information leak that allows you to quickly identify active UDP ports is due to a flaw in the code to handle ICMP packets with fragmentation (ICMP fragmentation required flag) or redirect (ICMP redirect flag) requests. Sending such packets changes the state of the cache on the network stack, making it possible, based on the server's response, to determine which UDP port is active and which is not.

Changes that block information leakage were accepted into the Linux kernel at the end of August (The fix was included in kernel 5.15 and September updates of the LTS branches of the kernel.) The solution is to switch to using the SipHash hash algorithm in network caches instead of Jenkins Hash.

Finally, if you are interested in knowing more about it, you can consult the details in the following link.

The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published.



  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

bool (true)