As many as 38% of domain name search servers on the Internet are vulnerable to a new attack that allows hackers to send their victims to fraudulent addresses masquerading as legitimate domains, like bankofamerica.com or gmail.com .
The exploit, unveiled in the research presented today, reignites the DNS cache poisoning attack that researcher Dan Kaminsky revealed in 2008. It showed that by impersonating an authoritative DNS server and using it to flood a DNS resolver with bogus search results for a trusted server. domain, an attacker could poison the resolver cache with the spoofed IP address. Therefore, anyone relying on the same resolver would be redirected to the same impostor site.
A lack of entropy
The sleight of hand worked because DNS at the time relied on a transaction ID to prove that the returned IP number was from an authoritative server rather than an impostor server trying to send people to a malicious site. The transaction number was only 16 bits long, which meant that there were only 65,536 possible transaction IDs.
Kaminsky realized that hackers could exploit the lack of entropy by bombarding a DNS resolver with out-of-path responses that included every possible ID. After the resolver receives a response with the correct ID, the server accepts the malicious IP address and stores the result in the cache so that anyone else using the same resolver, who is usually from a company, organization or an ISP, is also sent to the same malicious server.
The threat raised the specter of hackers capable of redirecting thousands or millions of people to phishing or malware sites posing as perfect replicas of the trusted domain they were attempting to visit. The threat resulted in industry-wide changes to the domain name system, which acts like a phone book that maps IP addresses to domain names.
Under the new DNS specification, port 53 was no longer the default port used for search queries. Instead, these requests were sent on a randomly selected port from the full range of available UDP ports. Combining the random 16 bits of the transaction ID with an additional 16 bits of entropy from the source port randomization, there were now around 134 million possible combinations, making the attack mathematically infeasible.
Unexpected Linux behavior
Today, a research team from the University of California at Riverside rekindled the threat. Last year, members of the same team found a secondary channel in the new DNS that allowed them to re-infer the transaction number and random port number sending spoofed IP addresses from the resolver.
The research and the SADDNS exploit it demonstrated resulted in industry-wide updates that effectively shut down the secondary channel. Now comes the discovery of new secondary channels that make cache poisoning viable again.
“In this article, we conduct an analysis of the previously overlooked attack surface and are able to uncover even more powerful secondary channels that have been around for over a decade in Linux kernels,” wrote researchers Keyu Man, Xin’an Zhou and Zhiyun Qian. in a research paper presented at the ACM CCS 2021 conference. âSecondary channels affect not only Linux, but also a wide range of DNS software running on it, including BIND, Unbound, and dnsmasq. We also find that around 38% of open resolvers (by IP frontend) and 14% (by IP backend) are vulnerable, including popular DNS services like OpenDNS and Quad9.
OpenDNS owner Cisco said, âCisco Umbrella / Open DNS is not vulnerable to the DNS cache poisoning attack described in CVE-2021-20322, and no Cisco customer action is required. . We fixed this issue, followed up via Cisco Bug ID CSCvz51632, as soon as possible after receiving the Security Researcher report. Quad9 representatives were not immediately available for comment.
The secondary channel for attacks from last year and this year involves the Internet Control Message Protocol, or ICMP, which is used to send error and status messages between two servers.
“We find that handling ICMP (a network diagnostic protocol) messages in Linux uses shared resources in a predictable way so that it can be exploited as a secondary channel,” researcher Qian wrote in an email. âThis allows the attacker to derive the ephemeral port number from a DNS query, and ultimately lead to DNS cache poisoning attacks. This is a serious flaw because Linux is the most widely used for hosting DNS resolvers. He continued:
The ephemeral port is supposed to be generated randomly for each DNS request and unknown to an off-path attacker. However, once the port number is leaked through a side channel, an attacker can then spoof seemingly legitimate DNS responses with the correct port number that contains malicious records and have them accepted (e.g. record malicious can say that chase.com matches an IP address owned by an attacker).
The reason the port number can be leaked is that the off-path attacker can actively probe different ports to see which one is the correct one, i.e. through ICMP messages which are basically network diagnostic messages which have unexpected effects in Linux (which is the key finding of our work this year). Our observation is that ICMP messages may incorporate UDP packets, indicating that a previous UDP packet had an error (eg, destination unreachable).
We can actually guess the ephemeral port in the embedded UDP packet and condition it in an ICMP probe to a DNS resolver. If the guessed port is correct, this results in a modification of some global Linux kernel resources, which can be indirectly observed. This is how the attacker can deduce which ephemeral port is being used.
Changing the internal state with ICMP probes
Last time the side channel was the rate limit for ICMP. To conserve bandwidth and computing resources, servers only respond to a set number of requests and then go silent. The SADDNS exploit used the rate limit as a secondary channel. But while last year’s port inference method used UDP packets to probe which ports were designed to solicit ICMP responses, the attack this time uses ICMP probes directly.
âAccording to the RFC (standards), ICMP packets are only supposed to be generated * in response * to something,â Qian added. “They themselves should never * ask * for any response, which means they’re not suitable for port scans (because you don’t get any feedback). However, we find that ICMP probes can actually modify some internal states that can be observed through a side channel, which is why the whole attack is new.
The researchers came up with several defenses to prevent their attack. One is to set the appropriate socket options such as
IP_PMTUDISC_OMIT, which instructs an operating system to ignore ICMP messages, thereby shutting down the side channel. A downside, then, is that these messages will be ignored, and sometimes such messages are legitimate.
Another proposed defense is to randomize the caching structure to make the side channel unusable. A third is to reject ICMP redirects.
The vulnerability affects DNS software, including BIND, Unbound, and dnsmasq, when running on Linux. Researchers tested to see if DNS software was vulnerable when running on Windows or Free BSD and found no evidence that this was the case. Since macOS uses the FreeBSD network stack, they assume that it is not vulnerable either.