Up to 38 percent of domain name search servers on the Internet are vulnerable to a new attack that allows hackers to send victims to maliciously spoofed addresses posing as legitimate domains, such as bankofamerica.com or gmail.com.
The exploit, which was revealed in a study presented today, revives the DNS cache poisoning attack that researcher Dan Kaminsky revealed in 2008 -Domain could be poisoned by an attacker in the resolver cache with the falsified IP address. From then on, anyone who relied on the same resolver would be redirected to the same scam site.
A lack of entropy
The sleight of hand worked because at the time the DNS relied on a transaction ID to prove that the returned IP number was from an authoritative server rather than a rogue server trying to send people to a malicious site . The transaction number was only 16 bits, which meant there were only 65,536 possible transaction IDs.
Kaminsky realized that hackers could take advantage of the lack of entropy by bombarding a DNS resolver with off-path responses that contained every possible ID. Once the resolver has received a response with the correct ID, the server accepts the malicious IP and caches the result so that everyone else using the same resolver – which usually belongs to a company, organization, or ISP – also joins. are sent to the same malicious server.
The threat raised the specter of hackers who could redirect thousands or millions of people to phishing or malware sites masquerading as perfect replicas of the trusted domain they were trying to visit. The threat resulted in industry-wide changes to the domain name system, which acts as a phone book that maps IP addresses to domain names.
Under the new DNS specification, port 53 was no longer the standard used for search queries. Instead, these requests were sent over a randomly selected port from the entire range of available UDP ports. By combining the 16-bit randomness from the transaction ID with a further 16-bit entropy from the source port randomization, there are now around 134 million possible combinations that make the attack mathematically impracticable.
Unexpected Linux behavior
Now a research team from the University of California at Riverside has revived the threat. Last year, members of the same team found a side channel in the newer DNS that allowed them to re-derive the transaction number and random port number that resolver spoofed IPs were sending.
The research and the SADDNS exploit shown resulted in industry-wide updates that effectively closed the side channel. Now comes the discovery of new side channels that make cache poisoning viable again.
“In this paper, we conduct an analysis of the previously overlooked attack surface and are able to uncover even stronger side channels that have existed in Linux kernels for over a decade,” write researchers Keyu Man, Xin’an Zhou and Zhiyun Qian in a research paper to be presented at the ACM CCS 2021 conference. “The side channels affect not only Linux, but also a wide range of DNS software that runs on it, including BIND, Unbound, and dnsmasq. We also find that around 38% of open resolvers (from front-end IPs) and 14% (from back-end IPs) 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 via the Cisco Bug ID CSCvz51632 will be tracked “as soon as possible after receiving the security researcher’s report.” Quad9 representatives were not immediately available for comment.
The side channel of the attacks from last year and this year is the Internet Control Message Protocol, or ICMP for short, which is used to send error and status messages between two servers.
“We find that the processing of ICMP messages (a network diagnostic protocol) in Linux predictably uses shared resources so that they can be used as an ancillary channel,” researcher Qian wrote in an email. “This allows the attacker to infer the short-lived port number of a DNS query and ultimately lead to DNS cache poisoning attacks. It’s a fatal mistake because Linux is most often used to host DNS resolvers. ”He went on:
The short-lived port should be generated randomly for every DNS query and should be unknown to an off-path attacker. However, once the port number is leaked through a side channel, an attacker can forge legitimate-looking DNS responses with the correct port number that contain malicious records and have them accepted (e.g. the malicious record can say that chase.com is an IP Address of an attacker).
The reason the port number leaked is because the off-path attacker could actively examine different ports to find out which one is the right one, i.e. through ICMP messages which are essentially network diagnostic messages that have unexpected effects on Linux ( d the most important discovery of our work this year). Our observation is that ICMP messages can embed UDP packets, which indicates that a previous UDP packet had an error (e.g. destination unreachable).
We can actually guess the ephemeral port in the embedded UDP packet and pack it into an ICMP probe to a DNS resolver. If the guessed port is correct, a global resource changes in the Linux kernel, which can be observed indirectly. In this way, the attacker can deduce which short-lived port is being used.
Changing the internal state with ICMP probes
The side channel was the rate limit for ICMP last time. To save bandwidth and computing resources, servers only respond to a certain number of requests and then fall silent. The SADDNS exploit used the rate limit as a side channel. But while the port inference method used UDP packets last year to check which ports are designed to request ICMP responses, this time the attack uses ICMP checks directly.
“According to RFC (standards), ICMP packets should only be generated * in response * to something,” added Qian. “You should never * ask * for answers yourself, which means they are unsuitable for port scanning (because you are not getting any feedback). However, we find that ICMP probes can actually change an internal state that can actually be observed through a side channel, which is why the entire attack is new. “
The researchers suggested several defense measures to prevent their attack. One of these is the setting of suitable socket options such as IP_PMTUDISC_OMIT, which instruct an operating system to ignore so-called ICMP messages, which effectively closes the side channel. A disadvantage then is that these messages are ignored and sometimes such messages are legitimate.
Another defense proposed is to randomize the caching structure to render the side channel unusable. A third is to refuse ICMP redirects.
The vulnerability affects DNS software, including BIND, Unbound, and dnsmasq, when running on Linux. The researchers tested whether DNS software was vulnerable when running on Windows or Free BSD and found no evidence of this. Since macOS uses the FreeBSD network stack, they assume that it is not vulnerable either.