On the heels of the July Microsoft DNS vulnerability, SIGRed, comes another attack against the Domain Name System. This time it's SAD, in more ways than one: SAD DNS (Side channel AttackeD DNS) is reviving that old standard, DNS cache poisoning, in a new way. Here’s what its aftermath can teach us.
Some context on SAD DNS cache poisoning
Researchers from the University of California, Riverside, and Tsinghua University presented their discovery of the new attack method last month. By the time news of the vulnerability spread widely, major players in DNS issued patches, corrections, and helpful workarounds.
Using Internet Control Message Protocol (ICMP) rate limits as a way to obtain necessary information for carrying out an attack, the researchers demonstrated how attackers can once again manage to poison the caches of DNS resolvers, directing users to malicious sites. SAD DNS, they said, is "the first weaponizable network side channel attack that has serious security impacts.”
Since 2008, when security researcher Dan Kaminsky demonstrated how an issue with transaction IDs (quickly corrected once he reported it) could be abused to do the same, things have been (relatively) quiet on the cache poisoning front. Until now. The researchers determined that 35% of open resolvers are open to the attack, as well as four of six home routers made by well-known brands.
They also found that 12 of 14 popular public resolvers (now 11—Cloudflare says they've corrected their systems) are susceptible. Even a patched DNS server could be made vulnerable by an unpatched or misconfigured NAT gateway.
Their 19-page paper on the exploit includes lists of devices and services tested. They have since set up a SAD DNS website featuring a Q&A and a tool that anyone can use to determine whether their DNS is vulnerable.
The flaw is being tracked as CVE-2020-25705, and affects Linux 3.18 – 5.10, Windows Server 2019 version 1809 and newer, macOS 10.15 and newer, and FreeBSD 12.1.0 and newer. The researchers did not test earlier versions of the listed operating systems.
It’s more than just SAD DNS
SAD DNS is only one of many ways DNS can be used in attacks. Because it was created in simpler, more trusting times—that sounds rather poetic, but it's true—DNS was not designed with the safeguards that today's threat landscape requires. Thus, it can be abused for things like command-and-control communications once a network has been compromised, mapping of compromised networks, and domain generation algorithms.
Queries can also be hijacked to send users to malicious domains. As a known part of the cyber kill chain, this should come as no surprise.
However, while no system is without vulnerabilities (unless turned off, unplugged, and at the bottom of the sea), homegrown solutions make it harder to incorporate what safeguards are available.
Homegrown DDI cripples common-sense safeguards
There already are common-sense mitigations for many attacks. DNSSEC is an example of a measure that can be helpful in the case of SAD DNS, but also in many others. DNS firewalls have also proven to be valuable. Tools that provide central visibility and manageability over DNS and log data can also be crucial for quickly containing an incident.
However, in North America, only 30% of DNS servers can currently handle DNSSEC resolution. Even Microsoft only announced in April that it would be adding DNSSEC for SMTP to its Exchange Online servers, with implementation complete by the end of 2021.
Likewise, leveraging core infrastructure to comply with security standards, as well as prevent, identify, remediate, and investigate incidents, is difficult. Especially with a homegrown solution made up of BIND or Microsoft DNS. Those architectures are often not managed centrally, compounding the network’s complexity and preventing full visibility and control.
If a behemoth like Microsoft is only just getting there on the DNSSEC front, organizations whose DDI (DNS, DHCP, and IP address management) is strictly roll-your-own need not be embarrassed if they can't implement DNSSEC on their own. It should prompt some serious thought.
The SAD reality
As attacks that leverage DNS continue to flare up, SAD DNS ought to be taken as a reminder to technology leaders that critical infrastructure plays a critical role in protection for the enterprise.
While the thought of evaluating a more enterprise-friendly alternative to homegrown DDI can be overwhelming, consider what will happen the next time there is an exploit that leverages your network’s very foundation to do damage. That might be worse.