KernelCare Patches for SAD DNS Are Here

Sad DNS (Side-channel AttackeD DNS) is a vulnerability that was disclosed by academics from the University of California and Tsinghua University, at the ACM Conference on Computer and Communications Security CCS 2020. The vulnerability was assigned to CVE-2020-25705. It affects distributions starting from the 7th v.o. (i.e. RHEL6 is not affected, as its kernel doesn’t include ICMP responses throttling feature yet). KernelCare patches will be released shortly. The newly academic discovery lets a malicious actor poison the cache of a DNS server and thus potentially redirect user traffic to sites or services hosting undesired or dangerous content. 

Contents:

1. How Sad DNS Works
2. Mitigating Sad DNS
3. The Root Cause
4. KernelCare Patch Release schedule

How Sad DNS Works

DNS cache poisoning was first discovered in 2008 by a security researcher Dan Kaminsky. As most administrators know, the Domain Name System (DNS) is a fundamental component of the Internet. When a user types a domain into their browser, the browser performs a query on a DNS server to determine the IP address that corresponds with the domain name. 

Most DNS queries use UDP, which is a stateless protocol requiring no authentication or handshake. DNS queries using UDP require only a source address (the user’s machine) and a port pair (source and destination). Because no authentication is required, anyone can query a DNS server for the IP address associated with any registered domain.

UDP executes on the transport layer of the OSI model, but designers did architect entropy into DNS queries to add some sort of security. Queries incorporate a randomized transaction ID that must be the same in the query and the response. The randomization of this value makes forging requests less likely due to its entropy. However, the query ID is only 16 bits, which means that less than 100,000 “guesses” are required before an attacker can brute force a match. With today’s computing power, brute-force attacks with only 100,000 possibilities can execute within a few seconds.

Because the Internet is so large, DNS resolvers are used to centralize queries to authoritative servers and distribute domain IPs to client requests. When a recursive DNS server queries an authoritative server, usually port 53 is used to send and receive messages. Since the port is already known, an attacker just needs the 16-bit query ID. In a cache poisoning attack, an attacker floods the recursive server with responses containing all possible ~65,000 IDs. If the DNS recursive server receives the attacker’s response before the authoritative server response, the DNS cache for the target domain is poisoned. Since no authentication or handshake happens, the resolver accepts the attacker’s response without question and the malicious IP resolves for a targeted domain. 

When an attacker poisons DNS recursive server cache, any users that query the domain will get the attacker-assigned IP address for the given domain. This means that the user will be directed to an attacker-controlled server. The content shown to the user is typically a phishing site that has the same look and feel as the legitimate domain. Using this attack, an attacker can steal credentials, financial data, and potentially sensitive files if users are tricked into uploading content.

To combat this issue, DNS resolvers use randomized ports. This means that the attacker would not only need to guess the query ID but also the port, which makes the attack infeasible. Other security has been included in DNS architecture such as using TCP instead of UDP and adding DNSSec to the process. DNSSec requires a signature with the query message, but the protocol is still in its infancy and has not been universally adopted.

Sad DNS attacks overcome port randomization using Internet Control Message Protocol (ICMP) error messages. When a port is closed, an ICMP request returns a “port unreachable” error message. Using this protocol and a scan of closed ports, an attacker can infer which ports are open to DNS responses. By reducing the “guessing” to limited ports and query IDs, an attacker now only needs to brute force around a hundred thousand responses. This attack isn’t always possible as some resolvers use connected UDP sockets rather than open sockets. With a connected socket, both DNS servers are “tied” as peers using the operating system.

Some servers use rate limiting to stop flooding of ICMP ports from reflection attacks. While this defense works against denial-of-service (DoS) on DNS servers, it can be leveraged in a Sad DNS attack. When ICMP replies are limited, a server will not respond with an error message when the rate limit is met. Attackers flood the target server with enough ICMP messages to reach the rate limit and then determine which ports are open, eliminating the number of guesses in a brute-force attack.

To perform a Sad DNS attack, the attacker needs:

• A system able to perform DNS queries against a vulnerable DNS server
• The ability to receive ICMP responses from said DNS server

Mitigating Sad DNS

Sad DNS attacks require several pre-existing conditions to successfully exploit, so mitigations add an additional condition making the attack infeasible. Adding any of the following strategies to the DNS process will make Sad DNS attacks infeasible for an attacker:

• Configure DNSSec, but wide adoption of this protocol has been slow.
• Disallow ICMP replies. This has potential side-effects, as this traffic is legitimately used for other purposes, such as monitoring.
• Apply a kernel patch to fix the root cause of the problem, thus preventing the identification of the ports used. KernelCare is currently working on the patches for CloudLinux7. Patches for other supported distributions will be released shortly.

The Root Cause

Sad DNS attacks are possible due to the predictable ICMP response rate limit defined by the DNS server’s kernel. By having a fixed number of maximum ICMP responses per second, an attacker can infer what ports are being used in DNS communication and send specially crafted packets to those ports. Other operating systems are also affected by this problem, having different but fixed limits as well.

Theoretically, it’s possible that Sad DNS is only one of multiple vulnerabilities used to exploit inefficient ICMP port randomization. Other services may be vulnerable to similar attacks, but so far no others have been disclosed. Patching the kernel can help future-proof against unknown vulnerabilities.

A patch addressing Sad DNS has been submitted for the Linux kernel, and Linux vendors are releasing appropriate fixes for their distributions including Redhat, Debian, Suse, Ubuntu. The drawback to patching using vendor-supplied software is the reboot required to complete the process. With KernelCare, administrators can live patch their servers without a reboot and remediate Sad DNS and any future vulnerabilities targeting the ICMP protocol and rate limit exploits.

KernelCare Patch Release Schedule

Released on November 23:

• CloudLinux 6 Hybrid,
• CloudLinux 7, 
• Oracle Enterprise Linux 7,
• RHEL 7,
• CentOS 7,
• CentOS 7 Plus

The patches will be applied automatically within the 4-hour period without a reboot. To update manually, run:

/usr/bin/kcarectl --update

Planned for release on a Week # 48:

• Ubuntu Patches
• Debian Patches

Planned for release on a Week # 49:

• Amazon Linux

Stay tuned for the updates.