DNS FLaRE: A Flush-Reload Attack on DNS Forwarders

DNS FLaRE: A Flush-Reload Attack on DNS Forwarders

Speakers: Gilad Moav, Anad Bremler Bar, Amit Klein, Yuda (presenting)

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=LdOpqQkwipA

Overview

The talk "DNS FLaRE: A Flush-Reload Attack on DNS Forwarders" unveils a sophisticated side-channel attack that leverages the timing characteristics of DNS forwarder caches to infer sensitive user activity. Presented by Yuda, on behalf of a research team including Gilad Moav (whose master's thesis formed the basis of this work), Professor Anad Bremler Bar from Tel Aviv University, and Professor Amit Klein from the Hebrew University, this research highlights a critical privacy vulnerability in widely deployed network infrastructure. The attack, named DNS FLaRE, focuses on the DNS caches present in home routers, which are typically used to accelerate DNS resolution.

DNS FLaRE demonstrates that an attacker, simply by tricking a victim into visiting a malicious website, can gain insights into the victim's subsequent browsing habits or even their physical movements if IoT devices are involved. Crucially, the attack requires no malicious software to be installed on the victim's computer or any IoT device. This low-bar entry for the attacker, combined with the high-resolution timing information that can be extracted, makes DNS FLaRE a significant threat to user privacy. The research not only details the attack methodology but also explores the challenges of executing such an attack across various operating systems and browser configurations, offering practical solutions and demonstrating its efficacy with high accuracy rates.

The implications of DNS FLaRE are far-reaching. It exposes how fundamental network services, designed for efficiency, can be repurposed into potent surveillance tools. By observing the presence or absence of specific DNS records in a home router's cache, an attacker can determine if a victim has visited a particular website (e.g., their bank) or if an IoT device has triggered an alert (e.g., a motion sensor). The research underscores the need for a reevaluation of DNS caching mechanisms and a more robust approach to privacy in the interconnected digital ecosystem, prompting browser vendors, operating system developers, and DNS software providers to consider and implement defensive measures.

Background

▶ Watch: Introduction to DNS FLaRE attack and use cases (0:00)

The Domain Name System (DNS) is a foundational component of the internet, translating human-readable domain names (like example.com) into machine-readable IP addresses. To enhance performance and reduce latency, various levels of caching are employed throughout the DNS resolution process. At the network edge, particularly in home networks, DNS forwarders (often integrated into Wi-Fi or cable routers) maintain a local cache of recently resolved domain names. This forwarder cache serves to expedite subsequent requests for the same domains, providing a quicker response to the user's devices.

The problem arises from the fact that these caches, while beneficial for performance, represent a shared resource. The presence or absence of a DNS record in a cache can be observed through timing differences in subsequent lookups. This forms the basis of a side-channel attack, where information is leaked through unintentional channels, such as variations in execution time, power consumption, or, in this case, network response times. Prior work in this area has explored side-channel attacks on various caching mechanisms, including CPU caches and network caches. Specifically, the research team behind DNS FLaRE had previously developed and presented a DNOS DOS attack (at USENIX 2024), which focused on flushing the caches of DNS resolvers. DNS FLaRE adapts and extends this concept to target the more localized and often less protected caches of DNS forwarders found in home routers.

The persistent existence of this privacy vulnerability stems from several factors. Firstly, the design of DNS caching prioritizes speed and efficiency, often overlooking potential side-channel implications. Secondly, home routers, while critical network components, are frequently "black boxes" for end-users, receiving infrequent updates and often running legacy DNS software like DNSmasq with default configurations. These factors create an environment where an attacker can exploit predictable timing variations in DNS responses to infer sensitive user activities, without needing direct access to the victim's devices or installing any malware. The challenge lies in distinguishing genuine cache hits from misses reliably, especially when other caches (like those in the operating system or browser) can interfere with measurements.

Key Findings

▶ Watch: Addressing the four major attack challenges (4:00)

The DNS FLaRE research presents several critical findings regarding the feasibility and impact of side-channel attacks on DNS forwarder caches:

• Inference of User Activity Without Malware: The most significant finding is the ability to infer a victim's browsing activity (e.g., visiting specific financial institutions) or even physical movements (via IoT device alerts) with no malicious software installed on the victim's systems. The attack only requires the victim to be tricked into visiting a single malicious website, which then orchestrates the cache manipulation and timing measurements.
• High Accuracy Rates: The attack demonstrates impressive accuracy, achieving an 86% accuracy rate when employing a "direct DNS" measurement technique (using the port zero trick). Even with less precise HTTP reload methods, an average accuracy of approximately 60% was observed, which is still sufficient for inferring activity, especially when combined with profiling techniques.
• Effective Cache Flushing Mechanism: The researchers successfully adapted their previously developed DNOS DOS attack to specifically target and "flash" the caches of DNS forwarders. This crucial step ensures that the forwarder cache is cleared of existing records, creating a clean slate for monitoring new entries.
• Bypassing Intermediate Caches: DNS FLaRE demonstrates effective techniques to circumvent the interference from other caches (operating system and browser caches) that could obscure the state of the target forwarder cache. This includes leveraging browser features like Network State Partitions and employing multiple attacker-controlled origins to isolate measurements.
• Broad Applicability Across Platforms: The attack was shown to be effective across a range of common operating systems and browsers, including Windows (Chromium), macOS (Chromium, Safari), and Linux distributions like Debian and Ubuntu (Chromium, Firefox). The research details how different OS/browser combinations present unique challenges and how these were overcome.
• Identification of Affected Components and Vendor Responses: The study identified specific software and hardware components vulnerable to this attack. While some vendors, such as Safari (which issued a CVE) and systemd (Ubuntu, which acknowledged the issue), have taken steps or committed to resolving the vulnerability, others like DNSmasq (a common DNS forwarder in home routers) have, at the time of the talk, declined to implement changes, citing hardware cost limitations for increasing cache sizes. This highlights a disparity in security postures across the ecosystem.

Technical Deep Dive

▶ Watch: Innovative techniques for measuring DNS response times (5:45)

The DNS FLaRE attack operates on a flush-reload principle, adapted for DNS forwarder caches. The core idea is to first empty the target cache, then wait for a period during which a victim might access a domain of interest, and finally measure whether that domain's record has entered the cache by timing its DNS resolution.

The threat model is particularly compelling due to its low requirements: the attacker needs an authoritative DNS server under their control and must trick the victim into visiting a single malicious website. No malware installation on the victim's machine or IoT devices is necessary.

The attack proceeds in several distinct phases:

1. Victim Enticement: The victim is lured to a malicious website, which executes JavaScript code in their browser.
2. Cache Flushing: The malicious JavaScript triggers a cache-flushing operation. The attacker, using their authoritative DNS server, serves a specially crafted zone file. This file contains numerous junk subdomains (e.g., junk1.flash.com, junk2.flash.com) with very short Time-To-Live (TTL) values. The victim's browser, through the malicious JavaScript, is made to issue DNS requests for these junk domains. This floods the victim's home router's DNS forwarder cache, effectively pushing out any existing legitimate records due to its finite size. The researchers adapted their DNOS DOS attack (previously presented at USENIX 2024 for resolvers) to perform this flushing specifically on forwarders.
3. Monitoring Window: After flushing, the attacker waits for a predefined monitoring window, typically 30 seconds. During this time, if the victim visits a "domain of interest" (e.g., bank.com) or an IoT device triggers an alert that resolves a specific domain (e.g., alert3.camera_manufacturer.com), the corresponding DNS record will be fetched and stored in the now-cleared forwarder cache.
4. Cache Reload and Timing Measurement: At the end of the monitoring window, the malicious JavaScript in the victim's browser attempts to "reload" a DNS request for the domain of interest. The crucial step here is to accurately measure the response time. Two primary techniques were developed:

• Port Zero DNS Request: The attacker issues an HTTP request to the domain of interest on port zero (e.g., http://bank.com:0). Such a request is immediately aborted by the browser due to the invalid port. However, critically, the underlying DNS resolution for bank.com completes before the request is aborted. This allows the attacker to measure the full DNS resolution time. A fast response indicates the record was in the forwarder cache, while a slow response implies a fresh lookup was performed (meaning the record was not in the cache). This method provided an 86% accuracy rate due to its clear distinction between fast and slow responses.
• HTTP Reload: A simpler method involves attempting to load an HTTP resource from the domain of interest. While less precise than the port zero trick, this method still yields measurable timing differences. The researchers used a Gaussian Naive Bayes classifier to distinguish between fast (cache hit) and slow (cache miss) responses, achieving an average accuracy of ~60%.

Addressing Major Challenges:

The researchers identified and overcame four major challenges:

1. Flashing the Forwarder Cache: As mentioned, an adaptation of their prior DNOS DOS attack was used. The focus here was on forwarders, which might have different cache eviction policies or sizes compared to larger recursive resolvers.
2. Choosing the Target Cache: While operating system (OS) and browser caches also exist, the forwarder cache in the home router was chosen as the primary target. It offered a "reasonable size" for mounting the attack effectively. Larger caches would be significantly harder to flood completely within a practical timeframe.
3. Reliable Reload Timing: The port zero trick and HTTP reload methods were developed because direct JavaScript-based DNS requests to arbitrary domains for timing measurements are generally restricted by browser security models.
4. Interference from Other Caches: This was a significant hurdle. When a victim visits bank.com, the record might be stored not only in the forwarder cache but also in the OS and browser caches, potentially masking the state of the forwarder cache.

• Browser Cache Bypass (Network State Partitions): Modern browsers, particularly Chromium-based ones, implement Network State Partitions. This security feature (developed partly in response to earlier side-channel attacks by Felton et al.) segments the browser's DNS cache based on the origin of the request. To bypass this, the attacker uses multiple extra domain names/origins (e.g., attacker1.com, attacker2.com). When measuring, the attacker issues the reload request from a different origin than the one used for the initial malicious website visit. This ensures the browser's partitioned cache doesn't serve a stale record, forcing the request to consult the OS or forwarder cache. The number of such extra domains needed depends on the target domain's TTL and the length of the monitoring loop.
• Operating System Cache Handling:
• Chromium-based browsers (Windows, macOS): By design, Chromium does not use the operating system's DNS cache, simplifying measurements as it directly queries the forwarder.
• Linux Debian: This distribution typically does not have a system-wide DNS cache, meaning the OS cache doesn't interfere.
• Ubuntu: Ubuntu uses systemd as a third-party DNS element with its own cache. This cache is small enough that the researchers could target it directly, effectively treating it as the "forwarder cache" for the purpose of the attack on Ubuntu systems. HTTP reload was used for measurements here.
• Safari (macOS) and Firefox (Windows, macOS): These browsers do use the operating system's cache. This makes direct measurement of the forwarder cache challenging. However, on Debian Linux (no OS cache) and Ubuntu (where systemd can be targeted), Firefox was still vulnerable using HTTP reload.

Increased Accuracy through Footprinting: The accuracy of the attack can be further enhanced by leveraging the "footprint" of target websites. When a user visits a domain like axe.com, the page often loads resources from several other domains (e.g., twink.com, twitter.com, apixx.com). By monitoring the cache status of these associated domains, the attacker can create a more robust signature for a specific website visit, increasing confidence in their inferences.

Demo / Proof of Concept

▶ Watch: Bypassing browser/OS caches using network state partitions (7:45)

The talk illustrated the practical application of DNS FLaRE with a compelling IoT profiling demonstration. In this scenario, the victim has a security camera installed in their home. When someone moves within the victim's home, the camera detects this movement and, as part of its alert mechanism, issues a DNS request to a specific domain, such as alert3.camera_manufacturer.com.

The DNS FLaRE attack, running in the background via the malicious website visited by the victim, continuously monitors the home router's forwarder cache. When the camera's DNS request for alert3.camera_manufacturer.com is made, the record enters the forwarder cache. During the subsequent "reload" phase of the attack, the attacker's script observes a fast response for this domain, indicating a cache hit. This allows the attacker to infer, "Aha, there was movement in the victim's home!" The demonstration highlighted how the system could accurately distinguish between slow (cache miss) and fast (cache hit) responses, even showing a visual representation with a green area indicating detected movement based on the cache status.

The effectiveness of this proof of concept was underscored by the previously mentioned accuracy figures: 86% accuracy with the direct DNS (port zero) method and approximately 60% average accuracy with HTTP reload. These results demonstrate that the attack is not merely theoretical but practically achievable, providing a reliable mechanism for real-time monitoring of user and device activity within a victim's home network.

Defensive Implications

▶ Watch: Attack compatibility with different OS and browsers (10:00)

The DNS FLaRE attack highlights significant privacy vulnerabilities in existing network infrastructure and software, prompting a need for robust defensive measures across various layers:

• Browser Vendors:
• Opera (Chromium-based): The researchers noted that Opera, being built on Chromium, would be patched as long as it used recent Chromium releases that incorporated fixes.
• Safari: Apple acknowledged the issue and swiftly patched Safari, issuing a CVE (Common Vulnerabilities and Exposures) identifier for the vulnerability. This demonstrates a proactive response to the discovered side channel.
• General Browser Best Practices: The existence of Network State Partitions in Chromium-based browsers, while intended to prevent earlier attacks, presented a challenge that the DNS FLaRE attack successfully bypassed using multiple origins. This suggests that even sophisticated browser-level defenses might need continuous re-evaluation against evolving side-channel techniques. Further hardening of DNS resolution privacy within browsers, perhaps through more aggressive caching policies or even stricter origin isolation for DNS requests, could be considered.

• Operating System Developers:
• systemd (Ubuntu): The developers of systemd, a widely used system and service manager that includes a DNS resolver component, acknowledged the issue and committed to resolving it. This is crucial as systemd's cache was directly targeted in some Linux configurations.
• General OS Cache Management: Operating systems that maintain a local DNS cache should review their design to mitigate timing-based side channels. Implementing features like cache randomization, obfuscation of cache hit/miss timing, or making OS caches less accessible to unprivileged processes could be beneficial.

• DNS Forwarder Manufacturers (Home Routers):
• DNSmasq: A significant finding was that DNSmasq, a common DNS forwarder used in many home routers, declined to implement changes at the time of the talk. Their suggestion was to increase the size of the cache. However, the researchers pointed out that "increasing the cache size on home routers is very expensive and comes in hardware units," making it an impractical solution for manufacturers and consumers. This stance leaves a critical vulnerability unaddressed in a vast number of consumer devices.
• Router Firmware Updates: Manufacturers of home routers should prioritize security updates that address DNS caching vulnerabilities. Implementing features such as:
• Cache Randomization: Introducing random delays for DNS responses to obscure cache hit/miss timings.
• Rate Limiting: Restricting the rate at which a single client can query distinct domains to prevent cache flooding.
• DNS Encryption (DoH/DoT): While DNS FLaRE primarily targets the forwarder cache timing, widespread adoption of DNS over HTTPS (DoH) or DNS over TLS (DoT) could make it harder for an attacker to observe or manipulate DNS traffic at other points in the network, potentially complicating certain aspects of the attack, though not directly mitigating the forwarder cache timing itself.
• Adaptive Cache Management: Dynamic adjustment of cache eviction policies or TTLs based on observed query patterns.

• IoT Device Manufacturers: The IoT profiling use case demonstrates that even devices not directly running malicious code can inadvertently leak sensitive information through their DNS behavior. IoT manufacturers should consider:
• Minimizing DNS Queries: Reducing unnecessary or frequent DNS lookups for alerts or status updates.
• Obfuscating Query Patterns: Varying the timing or domain names used for sensitive alerts to make profiling harder.
• Direct IP Communication: For critical alerts, consider communicating directly with known IP addresses rather than relying solely on DNS resolution.

Overall, the defensive implications underscore the need for a multi-layered approach. No single patch or mitigation will fully address the issue, given the distributed nature of DNS and caching. Coordinated efforts from browser developers, OS maintainers, and network hardware/software vendors are essential to enhance user privacy against such sophisticated side-channel attacks.

Key Takeaways

• DNS FLaRE is a novel side-channel attack that exploits timing differences in DNS forwarder caches within home routers.
• It infers sensitive user activities like browsing history and IoT device alerts without requiring any malware on the victim's systems.
• The attack is initiated simply by tricking a victim into visiting a malicious website, which then orchestrates cache flushing and timing measurements.
• High accuracy is achieved, up to 86% with direct DNS measurement techniques (port zero trick), and ~60% with HTTP reload, using a Gaussian Naive Bayes classifier.
• The researchers successfully bypassed interference from browser and OS caches using techniques like Network State Partitions with multiple origins and adapting to specific OS cache implementations (e.g., targeting systemd on Ubuntu).
• While some vendors (Safari, systemd) have acknowledged and addressed the vulnerability, others (DNSmasq) have declined changes, highlighting a critical gap in security posture for widely deployed home router software.
• The research emphasizes the persistent privacy risks inherent in shared DNS infrastructure and the need for coordinated defensive efforts from browser, OS, and network hardware/software vendors to mitigate such side-channel attacks.

About the Speaker(s)

The research presented on DNS FLaRE is a collaborative effort. The talk was delivered by Yuda, representing Tel Aviv University. The foundational work for this project primarily stems from the master's thesis of Gilad Moav, who is credited with doing most of the work on the attack. The team also includes Professor Anad Bremler Bar from Tel Aviv University and Professor Amit Klein from the Hebrew University, both contributing to the academic rigor and depth of the research.