Eclipse Attacks on Monero’s Peer-to-Peer Network

Eclipse Attacks on Monero’s Peer-to-Peer Network

Speakers: Ruisheng Shi

Conference: NDSS Symposium

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

Overview

This article delves into a critical security vulnerability affecting Monero, a prominent privacy-focused cryptocurrency. The talk, titled "Eclipse Attacks on Monero’s Peer-to-Peer Network," presented by Julian Pong, a graduate student from Beijing University of Posts and Telecommunications, on behalf of Ruisheng Shi and collaborators, unveils a novel method for launching Eclipse attacks against Monero nodes. While Monero is lauded for its robust privacy features at the transaction level, its underlying peer-to-peer (P2P) network layer has remained a potential, yet underexplored, attack surface for these types of isolation attacks.

The significance of this research lies in demonstrating the feasibility of Eclipse attacks against Monero, a network previously thought to be resistant to traditional methods. By introducing a new attack vector dubbed the Connection Reset Attack, the researchers highlight how an attacker can effectively isolate a target Monero node from its legitimate peers, thereby opening the door for more sophisticated and damaging follow-on attacks such as selfish mining, deanonymizing transaction origins, or disrupting network consensus. This work is crucial for Monero developers and users, as it identifies specific weaknesses in the network's peer management and transaction propagation protocols, urging for immediate defensive measures to safeguard the integrity and privacy of the Monero ecosystem.

Background

▶ Watch: Introduction to Eclipse Attacks on Monero (0:00)

Eclipse attacks are a well-known class of attacks in decentralized networks, particularly against cryptocurrencies. The fundamental goal of an Eclipse attack is to isolate a target node from the rest of the honest network by monopolizing all its incoming and outgoing connections. Once isolated, the attacker can feed the target node manipulated information, censor its transactions, or even exploit its state for personal gain. For instance, an eclipsed node might be convinced it's on the longest blockchain, enabling a selfish mining attack, or its transaction propagation patterns could be observed to trace the originating node of a transaction, undermining privacy.

Traditional Eclipse attack methods, as demonstrated against cryptocurrencies like Bitcoin and Ethereum, typically focus on two main strategies: occupying outgoing connections by filling the target node's peer list with malicious addresses, often requiring a node restart to take effect; and occupying incoming connections by exploiting the target node's connection eviction strategy. When a node reaches its maximum incoming connection limit, it usually employs a specific strategy (e.g., least-recently-seen, lowest bandwidth) to decide which existing connection to drop to accept a new one.

However, these existing methods proved largely inapplicable to the Monero network due to several key design differences. First, occupying outgoing connections in Monero still suffered from the uncontrollability and time-consuming nature of waiting for node restarts. More critically, Monero's design presented a unique challenge for incoming connections: it does not have a connection eviction strategy and, by default, has no hard limit on incoming connections. This means that benign incoming connections do not interfere with new ones, rendering traditional eviction-based attacks completely ineffective. These characteristics posed significant challenges for attackers, as they lacked direct control over disconnecting benign connections, forcing reliance on unpredictable events like node restarts.

Monero, designed with strong privacy in mind, employs specific mechanisms to enhance network-level anonymity. Its peer list management utilizes a whitelist and a greylist, from which nodes select peers based on predefined rules. Crucially, Monero uses the Dandelion++ protocol for transaction propagation, which aims to obscure the origin of transactions by routing them through a randomized "stem" phase before a broader "fluff" phase broadcast. Furthermore, Monero incorporates an anti-DoS mechanism: if a node receives a double-spending transaction that conflicts with one it has already accepted, it will proactively disconnect from the peer that sent the conflicting transaction. This specific anti-DoS feature, intended for network integrity, ironically becomes a central vulnerability exploited by the Connection Reset Attack.

Key Findings

▶ Watch: Introducing the Connection Reset Attack: Core Idea (3:30)

The core finding of this research is the successful demonstration of Eclipse attacks against Monero's P2P network, despite its unique design features that historically rendered traditional Eclipse attack methods ineffective. The researchers introduced a novel attack primitive called the Connection Reset Attack, which specifically targets Monero's network layer and exploits its transaction propagation characteristics.

The Connection Reset Attack's effectiveness stems from its ability to force benign connections to drop, thereby creating opportunities for malicious nodes to occupy those connection slots. This is achieved by intentionally creating double-spending conflicts between the target node and its legitimate neighbors, leveraging Monero's built-in anti-DoS mechanism which disconnects peers sending conflicting transactions.

The overall Eclipse attack architecture proposed consists of two main components:

1. Peer List Attack: This preparatory phase aims to fill the target node's peer lists (both greylist and whitelist) with records of attacker-controlled nodes. This ensures that when the target node attempts to establish new outgoing connections, it primarily selects malicious peers.
2. Connection Reset Attack: This is the core mechanism that actively disconnects existing benign connections (both incoming and outgoing), making way for the attacker to establish full control.

The research further details two distinct instances of the Connection Reset Attack, each tailored to different aspects of Monero's network:

• One variant targets nodes with RPC services enabled, exploiting a private transaction method to create double-spending conflicts.
• The second variant leverages the inherent differences in propagation speed between the "stem" and "fluff" phases of Monero's Dandelion++ protocol to orchestrate double-spend conflicts.

Experimental evaluation on the Monero mainnet confirmed the attack's effectiveness and efficiency. The Dandelion++-based attack, for example, achieved a complete Eclipse in an average of just 56 seconds across 10 experiments, demonstrating a significant improvement in speed and control compared to traditional, uncontrollable methods. This work not only identifies critical vulnerabilities but also provides concrete proof of concept, highlighting the urgent need for Monero to implement specific countermeasures.

Technical Deep Dive

▶ Watch: Overview: Peer List Attack and Connection Reset Attack (4:00)

The Connection Reset Attack is the innovative core of this Eclipse attack strategy, directly addressing Monero's lack of a connection eviction strategy. The fundamental idea is to exploit Monero's anti-DoS mechanism, which mandates that a node disconnects from any peer that sends a double-spending transaction conflicting with a transaction already known to the node. By strategically orchestrating such conflicts, an attacker can force benign connections to drop, making room for malicious connections.

The overall attack unfolds in two primary stages:

Peer List Attack

This stage is crucial for occupying the target node's outgoing connections. The goal is to ensure that the target node's whitelist and greylist are predominantly populated by attacker-controlled node records.

1. Greylist Attack:

• Monero nodes periodically exchange peer information with their connected peers, and this information is added to their greylist, often without immediate connectivity checks.
• The attacker establishes a connection with the target node.
• During the time-sync process (a standard P2P handshake), the attacker modifies the node information included in its response.
• By injecting carefully crafted, embedded node records into the target's greylist, the attacker can fill it with malicious addresses. These records don't need to represent active, connectable nodes initially, just valid-looking entries.

1. Whitelist Attack:

• When a Monero node successfully completes a handshake with an incoming connection, it adds the connecting node's information to its whitelist.
• The attacker leverages this by simultaneously controlling a large number of malicious nodes.
• These malicious nodes continuously attempt to perform handshakes with the target node.
• Through this sustained effort, the target node's whitelist is progressively filled with attacker-controlled node records.

The combined effect of the Greylist and Whitelist attacks is to poison the target's peer lists. When the target node needs to establish new outgoing connections (e.g., after some connections are dropped), it will predominantly select from these compromised lists, effectively connecting to malicious nodes.

Connection Reset Attack

This is the active phase where benign connections are forcibly terminated, paving the way for the attacker to fully eclipse the node. The attack results in two key consequences:

1. A decrease in the number of outgoing connections, forcing the target to select new peers from its now-malicious peer lists.
2. Disconnection of benign incoming connections, allowing the attacker to establish new malicious incoming connections.

The researchers proposed two distinct methods for executing the Connection Reset Attack:

1. Connection Reset Attack based on Private Transactions (RPC-enabled nodes)

This method specifically targets Monero nodes that have RPC services enabled, which are often used by wallets or services for sending transactions. Monero provides an RPC method for private transactions, allowing users to send transactions to a node without it forwarding them to the broader network.

The attack sequence is as follows:

• Step 1: Inject TX1. The attacker first injects a private transaction, TX1, into the target node directly via its RPC service. Since it's a private transaction, the target node accepts it but does not broadcast it to the network.
• Step 2: Broadcast TX2. Immediately after, the attacker broadcasts a second transaction, TX2, to the entire Monero network. TX2 is carefully crafted to be a double-spending conflict with TX1 (i.e., it attempts to spend the same inputs as TX1).
• Step 3: Conflict Propagation. TX2 rapidly propagates throughout the Monero network. Eventually, the target node's legitimate neighbors receive TX2 and, as part of their normal operation, attempt to forward it to the target node.
• Step 4: Disconnection. Since the target node has already received and accepted TX1 (via the private transaction RPC), it will recognize TX2 as a double-spend. According to Monero's anti-DoS mechanism, the target node will then reject TX2 and proactively disconnect from the neighboring node that sent it.

By repeating this process with different conflicting transactions and targeting various neighbors, the attacker can systematically disconnect all benign incoming and outgoing connections from the target node, replacing them with malicious connections.

2. Connection Reset Attack based on the Dandelion++ Protocol

This method exploits the unique two-phase transaction propagation mechanism of Monero's Dandelion++ protocol.

• Stem Phase: A transaction originates from a source node and is propagated in a hop-by-hop manner across the network, following a random, secret path. This phase is designed to obscure the transaction's origin.
• Fluff Phase: Once the transaction reaches a designated "proxy node" at the end of its stem path, or after a certain time, it transitions into the fluff phase. In this phase, the proxy node (and subsequent nodes that receive it) broadcasts the transaction widely to all its peers. Transactions in the fluff phase generally propagate much faster across the network than those in the stem phase.

The attack leverages this difference in propagation speed:

• Step 1: Generate Conflicting Transactions. The attacker generates two conflicting double-spending transactions, TX1 and TX2.
• Step 2: Send TX1 (Stem) and Broadcast TX2 (Fluff). The attacker sends TX1 directly to the target node, ensuring it enters the stem phase for propagation. Simultaneously and immediately, the attacker broadcasts TX2 to the entire network, ensuring it enters the fluff phase.
• Step 3: Differential Propagation. Because TX1 is in the slower stem phase and TX2 is in the faster fluff phase, most nodes in the network (including many of the target node's neighbors) will receive TX2 first. Only a few nodes, particularly those on the direct stem path for TX1, might receive TX1 first.
• Step 4: Disconnection. The critical scenario occurs when a target node's benign neighbor receives TX2 first (due to its rapid fluff propagation). This neighbor will then attempt to send TX2 to the target node. However, the target node has already received TX1 directly from the attacker and accepted it. Upon receiving TX2 from its neighbor, the target node identifies it as a double-spend and, as per its anti-DoS mechanism, disconnects from that neighbor.

By carefully timing the injection of TX1 and the broad broadcast of TX2, the attacker can systematically trigger disconnections from a significant portion of the target node's benign connections, ultimately leading to a successful Eclipse.

Demo / Proof of Concept

▶ Watch: Consequences of Connection Reset: Enabling Eclipse Attacks (5:30)

The researchers conducted comprehensive Eclipse attack experiments on a controllable target node within the Monero mainnet. This real-world environment demonstrates the practical feasibility and effectiveness of their proposed attack methodology. The experiments aimed to not only verify the complete occupation of all connections of the target node but also to evaluate the individual efficacy of each sub-attack component.

For the Eclipse attack using the Connection Reset Attack based on the Dandelion++ protocol, the results were compelling. Across 10 conducted experiments, the average computation time to achieve a full Eclipse was a mere 56 seconds. This rapid execution time highlights the attack's high efficiency compared to existing Eclipse attack methods that often require lengthy, uncontrollable waiting periods for node restarts or rely on specific, often absent, connection eviction strategies. The presentation detailed one specific experiment, illustrating how the number of various connection types (outgoing, incoming, benign, malicious) changed over time, visually confirming the attack's progression and success. The Greylist attack and Whitelist attack were shown to effectively occupy outgoing connections, while the continuous execution of connection reset attacks successfully evicted benign connections, leading to the ultimate success of the Eclipse.

Similar experiments were performed for the Connection Reset Attack based on private transactions. While there might have been performance differences (e.g., in execution time or resource requirements), the researchers stated that there was "no fundamental distinguish" in their ultimate effectiveness. Both methods consistently achieved complete occupation of all the target node's connections, demonstrating the robustness of the core Connection Reset Attack concept across different exploitation vectors. These experimental results unequivocally prove the practical viability of launching Eclipse attacks against Monero nodes using the newly identified vulnerabilities.

Defensive Implications

▶ Watch: Method 1: Connection Reset via Private Transaction (7:00)

The successful demonstration of Eclipse attacks against Monero necessitates immediate attention to defensive measures. The proposed countermeasures primarily target the three sub-attacks identified: the Greylist attack, the Whitelist attack, and the two instances of the Connection Reset Attack. While the talk briefly mentions analyzing potential negative impacts of these measures, the specific details provided allow for inferring practical defensive strategies.

1. Mitigating Peer List Attacks (Greylist and Whitelist):

• Enhanced Greylist Validation: Monero nodes should implement more rigorous connectivity checks before adding entries to the greylist or, at the very least, before attempting to establish connections with greylist entries. Currently, information from connected peers is added to the greylist without immediate connectivity verification, which the Greylist attack exploits. Requiring a successful handshake or proof of liveness before an entry can be used for outgoing connections would significantly reduce the effectiveness of injecting invalid or malicious greylist records.
• Stricter Whitelist Management: The mechanism where a successful handshake automatically adds an incoming connection's node information to the whitelist should be re-evaluated. Implementing a more robust reputation system, limiting the number of whitelist additions from new incoming connections, or requiring a longer period of sustained, benign interaction before whitelisting could help prevent a rapid whitelist poisoning by an attacker controlling numerous nodes.

1. Mitigating Connection Reset Attacks (Double-Spending Exploitation):

• Refined Double-Spend Handling: The immediate disconnection policy upon receiving a conflicting double-spending transaction, while a strong anti-DoS measure, proves to be a critical vulnerability. Monero could explore more nuanced approaches:
• Temporary Peer Flagging/Rate Limiting: Instead of an immediate hard disconnect, a node could temporarily flag a peer that sends a double-spend, rate-limit its incoming messages, or place it under observation. Only after repeated offenses or a more thorough verification process would a full disconnection occur. This would make it harder for an attacker to rapidly clear out benign connections.
• Probabilistic Disconnection: Introduce a probabilistic element to disconnections, making the attacker's control over connection drops less deterministic.
• RPC Service Hardening (for Private Transaction attack): For nodes with RPC services enabled, especially those offering private transaction capabilities, stricter access controls, authentication, and rate-limiting should be implemented. Limiting who can send private transactions or how many can be sent within a given timeframe could reduce the attacker's ability to inject TX1 into the target node.
• Dandelion++ Protocol Adjustments: The Dandelion++ protocol's differential propagation speeds between stem and fluff phases are exploited. While the design is intentional for privacy, its susceptibility to timing-based double-spend conflicts needs review. Developers could explore adjustments to the protocol that equalize propagation speeds under certain conditions, introduce randomized delays, or improve conflict resolution mechanisms to prevent adversaries from consistently winning the "race" between TX1 and TX2. For instance, if a node receives a transaction in the fluff phase that conflicts with one it recently received in the stem phase, a more sophisticated logic might be employed than immediate disconnection.

Implementing these measures would require careful consideration of their impact on network performance, legitimate user experience, and the core privacy goals of Monero. However, given the demonstrated effectiveness of these Eclipse attacks, such trade-offs are necessary to maintain the integrity and security of the Monero network.

Key Takeaways

• Traditional Eclipse attack methods are ineffective against Monero due to its unique P2P characteristics, specifically the absence of a connection eviction strategy and no default limit on incoming connections.
• A novel Connection Reset Attack has been developed, making Eclipse attacks on Monero feasible by exploiting its transaction propagation mechanisms and anti-DoS double-spending disconnection policy.
• The attack comprises a Peer List Attack (Greylist and Whitelist attacks) to control outgoing connections and the Connection Reset Attack to forcibly disconnect benign connections.
• Two distinct instances of the Connection Reset Attack were demonstrated: one targeting RPC-enabled nodes via private transactions, and another exploiting the speed differences between the stem and fluff phases of the Dandelion++ protocol.
• Experiments on the Monero mainnet proved the attack's high effectiveness and efficiency, with the Dandelion++-based attack achieving a full Eclipse in an average of just 56 seconds.
• Defensive measures are crucial, requiring enhancements to peer list validation, a more nuanced approach to double-spend handling beyond immediate disconnection, and potentially adjustments to the Dandelion++ protocol and RPC service hardening.

About the Speaker(s)

The talk was presented by Julian Pong, identified as a graduate student from Beijing University of Posts and Telecommunications. The metadata lists Ruisheng Shi as the speaker, indicating Ruisheng Shi is a primary author or lead researcher behind this work. While Julian Pong delivered the presentation, the research represents a collaborative effort, with Ruisheng Shi likely playing a significant role in the study's conception and execution. An author named Xiwan Pong was also available online to answer questions during the Q&A session.