Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Our partner program is designed with flexibility in mind for partners who are at various stages of their business lifecycle. With financial investment and dedicated resources, you will continue to grow with TuxCare.
Would you like to work with a leader in open source and Linux security that values innovation and partnerships?
Partners receive benefits that are designed to reward the commitment that they have made to the sale of our products and services.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
Follow Us on Social
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.
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:
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:
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.
Released on November 23:
The patches will be applied automatically within the 4-hour period without a reboot. To update manually, run:
Planned for release on a Week # 48:
Planned for release on a Week # 49:
Stay tuned for the updates.
TALK TO A CYBERSECURITY EXPERT
Stay updated with the latest news and announcements from TuxCare.com
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...
In a symphony orchestra, instruments harmonize to create one pleasing...
We are pleased to announce that a new updated ePortal version...
We are pleased to announce that a new updated KernelCare agent...