MirageFlow: A New Bandwidth Inflation Attack on Tor

MirageFlow: A New Bandwidth Inflation Attack on Tor

Speakers: Christoph Sendner

Conference: NDSS Symposium

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

Overview

In a critical presentation at the NDSS Symposium, Christoph Sendner unveiled "MirageFlow," a novel and potent bandwidth inflation attack that poses a significant threat to the Tor network's anonymity guarantees. Tor, the world's most prominent system for anonymous communication, relies on a distributed network of volunteer-run relays to obscure user identities. However, its effectiveness is continually challenged by sophisticated traffic fingerprinting and correlation attacks, which aim to deanonymize users by attracting their traffic to adversarial relays. MirageFlow introduces a powerful new vector for achieving this prerequisite, leveraging an overlooked vulnerability in Tor's bandwidth measurement mechanisms.

The core innovation of MirageFlow lies in its exploitation of resource sharing among attacker-controlled relays. Unlike previous inflation attacks that focused on individual malicious relays, MirageFlow allows an adversary to dynamically reallocate the entire resources of a shared physical host or network segment to a single relay undergoing bandwidth measurement. This strategy dramatically amplifies the reported bandwidth, making the attacker's relays appear far more capable than they genuinely are, thereby increasing their probability of being selected by Tor clients. Sendner detailed two variants: C-MirageFlow for co-resident relays on a single host and D-MirageFlow for relays sharing a network link with a dedicated server, both demonstrating substantial inflation factors.

This research is particularly relevant as it exposes a fundamental weakness in Tor's current bandwidth measurement paradigm, which relies on easily distinguishable two-hop measurement circuits. By demonstrating how an attacker can control a significant portion of Tor's traffic with relatively modest resources—just 10 dedicated servers hosting 109 relays to control 50% of the network's bandwidth—MirageFlow underscores the urgent need for more robust and inflation-resilient measurement techniques. The findings not only highlight the vulnerability of existing solutions but also advocate for a fundamental shift in how Tor assesses relay capacity to safeguard user anonymity against increasingly sophisticated adversaries.

Background

▶ Watch: Introduction to MirageFlow and bandwidth inflation problem (0:00)

Tor's architecture is built on a decentralized network of volunteer-operated relays designed to provide anonymity to its users. When a user connects to Tor, their traffic is routed through at least three relays: a guard relay (entry point), a middle relay, and an exit relay (final hop to the destination). This multi-hop path is crucial for obscuring the client's IP address and preventing deanonymization. To ensure efficient and secure path selection, Tor clients rely on a consensus file, an hourly updated list of active relays with self-reported and measured state information, including an estimated bandwidth.

The bandwidth measurement process is managed by Directory Authorities (DAs), a subset of which act as Bandwidth Authorities (BAs). These BAs are responsible for actively measuring the available bandwidth of thousands of relays. Historically, Tor used TorFlow for this purpose, but around 2018, it transitioned to the Simple Bandwidth Scanner (SBWS). Both methods employ a critical, yet vulnerable, technique: they establish two-hop measurement circuits through the target relay and a randomly selected exit relay to download large files from a web server. This is a fundamental flaw because regular user traffic always requires at least three hops for anonymity. Consequently, two-hop measurement circuits are trivially distinguishable from legitimate user traffic.

This distinction creates a significant opportunity for attackers. Once a malicious relay detects that it is being measured by a BA (whose IP addresses are publicly known), it can prioritize measurement traffic while dropping or deprioritizing user traffic. This strategy, known as selective Denial-of-Service (DoS), allows the malicious relay to dedicate its full resources to the measurement, artificially inflating its reported bandwidth. Previous research has demonstrated the effectiveness of this approach, with studies by Biryukov et al. (2013) achieving over tenfold inflation and Johnson et al. (2017) reporting up to 177x inflation in simulations. Another common inflation strategy involves malicious relays simply misreporting exaggerated bandwidth in their descriptors, which BAs attempt to cross-verify but cannot fully prevent.

Furthermore, a critical omission in Tor's current system is that nothing prevents relay operators from deploying multiple relays on shared resources, such as a single physical machine or a shared network link. While Tor allows two relays to share the same public IP address, the implications of resource sharing for bandwidth inflation have not been fully explored until now. MirageFlow builds upon these prior inflation techniques by introducing a novel method that amplifies their impact through strategic resource allocation across co-resident, attacker-controlled relays.

Key Findings

▶ Watch: MirageFlow's core idea: exploiting shared resources for amplification (1:00)

The research on MirageFlow yielded several critical findings and contributions that significantly advance our understanding of bandwidth inflation attacks on Tor:

• Novel Bandwidth Inflation Attack (MirageFlow): The primary contribution is the introduction of MirageFlow, a new attack strategy that leverages resource sharing within a cluster of attacker-controlled relays. By dynamically allocating all available networking and computational resources to a relay currently being measured, MirageFlow dramatically amplifies the measured bandwidth. This technique can be combined with existing inflation methods, such as false self-reporting or selectively dropping user traffic, to maximize impact.
• Effective Attack Variants: Two distinct variants were proposed and empirically evaluated:
• C-MirageFlow (Co-Residing Relays): For relays co-located on a single physical host, empirical tests demonstrated an inflation factor remarkably close to 'n', where 'n' is the number of co-resident relays. For example, five co-resident relays effectively allowed the attacker to claim nearly five times the baseline bandwidth.
• D-MirageFlow (Dedicated Server): For relays sharing a network link with a dedicated server, the attack achieved an inflation multiplier of nearly half 'n*N', where 'n' is the cluster size and 'N' is the number of servers. An impressive demonstration involved three clusters with a total of 16 relays achieving a claimed bandwidth of 204.43 MBps, significantly exceeding the individual server limits.
• Feasibility of Large-Scale Control: Theoretical analysis and resource estimation revealed that controlling 50% of the entire Tor network's traffic—estimated at 678 GBit/s in 2022—could be achieved with a surprisingly modest investment. An adversary would require just 10 dedicated servers, each providing 100MB/s bandwidth, hosting a total of 109 relays. This indicates a high return on investment for attackers seeking to attract substantial user traffic.
• Ineffectiveness of 3-Hop Circuits as Mitigation: The study experimentally debunked the notion that increasing measurement circuits to three hops would mitigate detection. State-of-the-art Machine Learning (ML) techniques, specifically a cascaded Self-Attention Convolutional Neural Network (SA-CNN) model, were shown to effectively distinguish user and measurement traffic in 3-hop circuits with a 99% F1-score and less than 0.5 ms inference time. This renders increasing hop count an unviable countermeasure.
• Vulnerability of Existing Alternatives: Several proposed alternative bandwidth scanning solutions, including FlashFlow, EigenSpeed, PeerFlow, and MLEFlow, were critically assessed and found to be vulnerable to MirageFlow or other inflation attacks. Their design flaws, such as allowing attackers to schedule measurements or relying on BA-based measurements, make them susceptible.
• Real-World Indicators: The research identified specific characteristics in the real Tor network that could indicate ongoing MirageFlow attacks. These include relay families exhibiting similar bandwidth and uptime patterns, or the strategic leveraging of alternate port numbers by malicious relays. The study also demonstrated that existing Sybilhunter detection mechanisms can be easily evaded by meticulously configuring Sybil relay parameters.
• Coincidence Rate Analysis: While the probability of multiple co-resident relays being measured simultaneously (coincidence) increases with cluster size, the study found that for practical cluster sizes (up to 30 relays), this effect is insignificant. Even with 120 relays, the majority (59.17%) are measured individually, allowing them to claim full bandwidth. This ensures the attack's efficacy for a wide range of cluster sizes.

Technical Deep Dive

▶ Watch: Key contributions: MirageFlow strategy and two attack variants (1:31)

MirageFlow fundamentally redefines bandwidth inflation attacks by exploiting the common practice of resource sharing in computing environments. The adversary model assumes an attacker controls multiple Tor relay instances—which could be physical machines, virtual machines, or even processes/Docker containers—and has access to multiple public IP addresses. For the more advanced D-MirageFlow variant, the adversary additionally controls the network router or gateway connecting the relays to the internet.

The crucial enabler for MirageFlow is the attacker's ability to distinguish measurement traffic from user traffic in real-time. As previously discussed, Tor's SBWS uses two-hop circuits for measurements, which are trivially distinguishable from the three-hop circuits used by legitimate user traffic. This allows for simple IP filtering based on publicly available Bandwidth Authority (BA) IP addresses. Even if Tor were to switch to three-hop measurement circuits, the research demonstrated that advanced Machine Learning (ML) techniques, specifically a cascaded Self-Attention Convolutional Neural Network (SA-CNN) model, can achieve over 99% F1-score in distinguishing traffic types with sub-millisecond inference times, rendering such a mitigation ineffective.

The high-level idea behind MirageFlow is to create a cluster of attacker-controlled relays that share underlying computational and networking resources. When a Traffic Classifier detects measurement traffic targeting any relay within this cluster, the entire shared resource pool is dynamically reallocated to the measured relay. Concurrently, user traffic destined for any relay in the cluster is either dropped entirely or diverted to a low-resource relay, ensuring the measured relay receives maximum available bandwidth. This dynamic resource allocation, combined with existing inflation techniques like false bandwidth self-reporting or selective DoS, dramatically amplifies the inflation effect.

C-MirageFlow: Co-Residing Relays on a Single Host

In C-MirageFlow, the attacker operates several co-resident Tor relays within a single physical machine or server. Each relay can be deployed as a separate CPU process, a Docker container, or a Virtual Machine (VM). The researchers opted for separate processes in their implementation to minimize overhead. Each co-resident relay must be configured with a unique combination of IP address and port number.

When measurement traffic from a BA is detected by the Traffic Classifier (e.g., implemented using Netfilters based on BA IP addresses) targeting one of these co-resident relays, the attack mechanism is triggered. All regular user traffic destined for any of the other co-resident relays in that cluster is immediately dropped. This action effectively dedicates the entire bandwidth and computational resources of the physical machine to the specific relay currently being measured. This amplifies the measured bandwidth by a factor approximately equal to 'n', the number of co-resident relays in the cluster. While simultaneous measurements of multiple relays within the same cluster are possible, the analysis showed this to be a rare event for practical cluster sizes, preserving the attack's efficacy.

D-MirageFlow: Relays with a Dedicated Server

D-MirageFlow extends the concept by distributing resources across a network segment behind a router, allowing for even greater resource aggregation. In this variant, the attacker controls a network segment and uses a physical router or switch to filter and manipulate traffic. Unlike C-MirageFlow, the traffic filtering function is separated from the Tor relays.

The attacker allocates a high-resource dedicated server specifically to handle measurement traffic. Meanwhile, low-resource servers (which can host multiple co-resident relay clusters, similar to the C-MirageFlow setup) handle regular user traffic. When the attacker-controlled router or switch detects measurement traffic, it forwards this traffic to the dedicated server. This allows all attacker-controlled relays, across all clusters, to falsely claim the total available bandwidth of the dedicated server. This represents a significant amplification, achieving a multiplier of nearly half 'n*N' (where 'n' is cluster size and 'N' is server count). Crucially, the relay clusters can continue serving client Tor traffic for potential interception or deanonymization without impacting the ongoing bandwidth measurement. This design enables a more distributed and scalable attack, leveraging network-level control for resource allocation. For cost-efficiency in evaluation, the researchers instantiated a virtualized, tunneled version, with the router as a VM and relay clusters connected via OpenVPN connections, running relays as Docker containers for easy orchestration.

Demo / Proof of Concept

▶ Watch: Tor's SBWS bandwidth measurement and its critical flaws (2:55)

The researchers conducted a comprehensive empirical evaluation of both MirageFlow variants in a private Tor test network, meticulously designed to mirror real-world conditions. The evaluation environment was set up on a powerful Debian Bullseye host machine, configured with 32/64 Cores/Threads, 126 GB RAM, and 3.2 TB NVMe disk space. A private Tor test network was created using Chutney for bootstrapping configuration files, comprising three DAs, five exit relays, two clients, a BA, a web server, and an internet connection. This entire setup was virtualized using Vagrant and VirtualBox, emulating server resources and network bandwidth limitations (e.g., DAs at 200 MBps, relay VMs at 50 MBps, clients at 25 MBps, and the BA/web server with unlimited bandwidth).

For C-MirageFlow evaluation, five malicious relays were deployed within a single VM, each running as a separate CPU process. These co-resident relays were introduced at staggered intervals to minimize the chance of simultaneous measurement, mimicking real-world deployment. The IP-based traffic detection mechanism, implemented via Netfilters to distinguish two-hop BA measurement traffic, was activated to drop user traffic during measurements. A baseline bandwidth measurement of approximately 25 MBps was established without any attack. The results, visualized in Figure 4 of the original presentation, clearly showed that with the addition of each new co-resident relay, the average measured bandwidth reported by SBWS steadily increased. For instance, with five co-resident relays, the sum of measurements reached 34.65 MBps, significantly exceeding the baseline. This demonstrated that C-MirageFlow boosts inflation by a factor above n (the number of co-resident relays), in a nearly linear fashion, due to measurement variance and the dedication of the entire host's resources to the measured relay.

The D-MirageFlow evaluation involved a more complex setup. Three relay clusters were instantiated as VMs, each with a bandwidth limit of 25 MBps and hosting six Tor relays as Docker containers. These clusters were co-located with a virtual router (a VM with a 200 MBps bandwidth limit). Additionally, a dedicated relay server with 6 vCPUs, 12 GB RAM, and a 50 MBps bandwidth limit was added. Continuous user traffic was generated to the relays, and a simulated SBWS instance emulated BA behavior. The results (Figure 5) were even more impressive: each measured relay claimed more than a fifth of the dedicated server's bandwidth. With all six relays in Cluster 1, the attacker claimed over 65 MBps. By extending the attack to three clusters with a total of 16 relays connected via the VPN router, the attacker achieved an astounding 204.43 MBps. This confirmed the linear relationship between the D-MirageFlow attack's impact and the number of relays 'n' in each cluster, distributed across 'N' relay servers, allowing for significant scalability.

The researchers also conducted an extensive analysis of the inflation factor and the impact of coincidence (simultaneous measurements). Using CollecTor data from May-July 2022 and the Stem library, they analyzed 10,440 bandwidth files. Despite the possibility of coincidence reducing the claimed bandwidth, their experiments with small attacker-controlled clusters showed this effect to be insignificant. They calculated a median measurement duration of 39 seconds for sequential measurements. For a cluster size of 45 relays, the probability of three relays being co-measured was only 0.014%, and even with 120 relays (e.g., the Artikel10 family used as an example of potential co-residency), the majority (59.17%) were measured individually. The theoretical analysis (Figure 7c) showed that for small cluster sizes, the attack demonstrates nearly linear inflation rates: 10 relays yield 9.91x, 20 relays yield 19.16x, and 30 relays yield 28.03x. While the linearity diminished for larger clusters (e.g., 92.52x for 120 relays), the overall inflation remained substantial.

Finally, the study estimated the required attack resources. Using a curve fitting algorithm, the researchers projected that to control half of the Tor network's traffic (678 GBit/s), an adversary would need to advertise an additional 678 GBit/s. This could be achieved with just 10 dedicated servers, each with 100MB/s bandwidth, hosting a total of 1090 relays (a cluster size of 109 relays per server). This demonstrates that a significant percentage of Tor traffic can be controlled with comparatively small effort, highlighting the critical threat posed by MirageFlow.

Defensive Implications

▶ Watch: MirageFlow adversary model and attack feasibility assumptions (4:30)

MirageFlow exposes fundamental vulnerabilities in Tor's current bandwidth measurement architecture, necessitating a re-evaluation of existing and proposed countermeasures. The research critically assessed several alternatives:

• 3-Hop Measurement Circuits: While intuitively appealing as a way to obscure measurement traffic, the study definitively demonstrated its ineffectiveness. Modern Machine Learning (ML) techniques, specifically a cascaded Self-Attention Convolutional Neural Network (SA-CNN) model, can distinguish user and measurement traffic in 3-hop circuits with an F1-Score of over 99% and an inference time under 0.5 ms. This means attackers can still detect and re-route measurement traffic, rendering this approach futile as a mitigation.
• FlashFlow: This proposed alternative forces relays to demonstrate near-maximum capacity. However, its design allows attackers to accept or refuse being measured by specific BAs and to schedule measurements to avoid co-measurements, which could further increase the inflation factor of MirageFlow.
• EigenSpeed, PeerFlow, and MLEFlow: EigenSpeed, a peer-to-peer bandwidth evaluation technique, is not directly vulnerable to MirageFlow due to the absence of specialized measurement traffic. However, it remains susceptible to Sybil attacks, which can also lead to inflation. PeerFlow, while building on P2P principles, still uses TorFlow during bootstrapping, making it vulnerable to similar inflation attacks. MLEFlow relies on BA-based measurements, making it inherently susceptible to measurement traffic detection and inflation attacks.

Given these shortcomings, the researchers proposed several potential countermeasures for Tor defenders:

1. Detecting Measurement Anomalies: Currently, Tor's bandwidth files only record end timestamps, making it difficult for BAs to deterministically recreate measurement timelines. The speaker strongly advocated for BAs to record start timestamps and collaborate to recreate complete timelines. This would enable the detection of suspicious trends, such as noticeable drops in instantaneous bandwidth when multiple co-resident relays are measured simultaneously, indicating an attack.
2. Obscuring Measurement Traffic: Randomizing the origin and destination IPs of measurement flows could make traffic detection non-trivial. However, the research found that even with masked IP addresses, traffic flow patterns remain detectable by advanced ML techniques. This suggests that simply obscuring IP addresses is an insufficient mitigation strategy.
3. Co-residency Detection: Defenders could look for indicators of co-residency, such as relay overload, shared public IP addresses, similar uptime values, consistent measurement results, or even identical Tor versions. Tools like Sybilhunter could be adapted to identify such patterns. If co-residency is suspected, BAs could intentionally co-measure these relays to verify anomalous bandwidth drops. However, this approach increases system load and is generally discouraged.
4. Eliminating Explicit Measurement Traffic: This is presented as perhaps the most promising and fundamental countermeasure. By shifting away from explicit, distinguishable measurement traffic and instead using existing Tor relay nodes to measure peer bandwidth in a distributed, peer-to-peer fashion, the network could become significantly more resilient. While existing P2P solutions like EigenSpeed and PeerFlow have their own vulnerabilities (e.g., Sybil attacks), improved versions of these distributed measurement techniques could effectively hinder a wide range of bandwidth inflation attacks, including MirageFlow. This would require a fundamental paradigm shift in how Tor's bandwidth is measured.

In essence, the defensive implications highlight that incremental fixes, such as adding more hops or obscuring IPs, are insufficient against sophisticated adversaries leveraging ML. A more radical re-architecture of Tor's bandwidth measurement system towards a truly distributed, non-explicit measurement approach is necessary to safeguard the network's integrity and user anonymity.

Key Takeaways

• MirageFlow is a potent new bandwidth inflation attack: It exploits resource sharing among attacker-controlled relays to dramatically amplify measured bandwidth, making malicious relays appear more attractive to Tor clients.
• Two variants demonstrate significant inflation: C-MirageFlow (co-resident relays on a single host) achieves near-linear inflation (factor n), while D-MirageFlow (relays with a dedicated server) achieves even higher amplification (factor n*N/2).
• Low resource investment for high impact: An adversary can control 50% of Tor's total network traffic (678 GBit/s) with a relatively small investment of just 10 dedicated servers hosting 109 relays.
• Current countermeasures are insufficient: Increasing hop count to three for measurement circuits is ineffective due to advanced Machine Learning techniques (99% F1-score detection). Existing alternative measurement solutions are also vulnerable.
• Detecting anomalies and fundamental shifts are crucial: Defenders should implement better timestamping for bandwidth measurements to detect anomalies. The most promising long-term solution is a fundamental shift towards distributed, peer-to-peer bandwidth measurement, eliminating explicit, distinguishable measurement traffic altogether.

About the Speaker(s)

Christoph Sendner is a researcher who presented the work on MirageFlow at the NDSS Symposium. While his specific title and affiliation beyond "researcher" are not detailed in the provided transcript, his presentation demonstrates a deep technical understanding of the Tor network, its architecture, bandwidth measurement mechanisms, and the vulnerabilities inherent in its design. His work focuses on identifying and evaluating novel attack vectors, particularly those related to bandwidth inflation and deanonymization, to advocate for stronger security measures in anonymous communication systems.