A team of researchers from UC Irvine and Tsinghua University has developed a new powerful cache poisoning attack named ‘MaginotDNS,’ that targets Conditional DNS (CDNS) resolvers and can compromise entire TLDs top-level domains.
The attack is made possible thanks to inconsistencies in implementing security checks in different DNS software and server modes (recursive resolvers and forwarders), leaving roughly one-third of all CDNS servers vulnerable.
DNS cache poisoning background
DNS (Domain Name System) is a hierarchical and distributed naming system for internet resources and networks, helping resolve human-readable domain names to numerical IP addresses so that a network connection can be made.
The DNS resolution process uses UDP, TCP, and DNSSEC to perform queries and receive responses. It can be iterative and recursive, involving multiple steps and exchanges with root servers, TLD servers, authoritative servers, caching records along the way, etc.
The concept of DNS cache poisoning is injecting forged answers into the DNS resolver cache, causing the server to direct users who enter a domain to incorrect IP addresses, potentially leading them to malicious websites without their knowledge.
Many attacks of this type have been demonstrated in the past, like, for example, the Kashpureff Attack in 1997, which exploited a lack of data verification (bailiwick rules), and the Kaminsky Attack in 2008 that took advantage of the absence of a source port randomization system.
These attacks have been mitigated by adding defenses into the resolvers’ implementation, rendering off-path attacks challenging.
However, the ‘MaginotDNS’ attack can overcome these defenses by attacking the forwarding mode of CDNS from either on-path or off-path.
The MaginotDNS attack
CDNS resolvers support both recursive and forwarding query modes, used by ISPs and the enterprise to reduce costs and better access control.
The researchers found that bailiwick checks are adequately enforced in the recursive mode; however, the forwarder is vulnerable.
Because the two share the same global DNS cache, an attack on the forwarder mode can open the path to breaching the recursive mode, essentially breaking the DNS cache protection boundary.
Researchers identified inconsistencies in the bailiwick checking of prominent DNS software, including BIND9 (CVE-2021-25220), Knot Resolver (CVE-2022-32983), Microsoft DNS, and Technitium (CVE-2021-43105).
In certain cases, they noted configurations that treated all records as if they were under the root domain, a highly vulnerable setup.
The examples showcased by the researchers during their BlackHat presentation include both on-path and off-path attacks, with the latter being the more complicated but also far more valuable for threat actors.
For these attacks, the threat actor needs to predict the source port and the transaction ID used by the target’s recursive DNS servers when generating a request and then use a malicious DNS server to send forged responses with the correct parameters.
Inferring the source port and guessing the transaction IDs can be done by brute forcing or using SADDNS (side-channel attacked DNS).
For BIND9, both parameters can be successfully retrieved after 3,600 query rounds, while for Microsoft DNS, this drops to 720 rounds.
To increase the chances of success, the attacker must control the reply time of the malicious DNS responses to ensure their forged response reaches the victim’s server before the legitimate one.
The researchers shared the following video demonstrating the MaginotDNS attack on Microsoft DNS.
Scanning for vulnerable CDNS
The researchers scanned the internet and found 1,200,000 DNS resolvers, of which 154,955 are CDNS servers.
Next, using software fingerprints to identify vulnerable versions, they found 54,949 vulnerable CDNS servers, all of which are susceptible to on-path attacks, and 88.3% are impacted by off-path attacks.
All the affected software vendors mentioned above have confirmed and fixed the flaws, and Microsoft has awarded a bounty to the researchers for their report.
However, for the issues to be fully mitigated, CDNS administrators must apply the patches and follow the correct configuration guidelines provided by the vendors.