What is an eclipse attack?

In an eclipse attack, a malicious actor isolates a specific user or node within a peer-to-peer (P2P) network.

The attacker’s goal is to obscure a user’s view of the P2P network in preparation for more complex attacks or to cause general disruption. Eclipse attacks share similarities with Sybil attacks, however, their end goals are different. 

They are similar in the sense that a certain network is flooded with fake peers. The difference, however, is that in an eclipse attack, a single node is attacked. In a Sybil attack, the entire network is attacked. 

Moreover, attackers can start an eclipse attack by constructing many ostensibly independent overlay nodes via a Sybil attack. Attackers may use the overlay maintenance mechanism to mount an eclipse assault; hence, safeguards against Sybil attacks do not prevent eclipse attacks.

Eclipse attacks are discussed comprehensively in the 2015 paper authored by researchers from Boston University and Hebrew University entitled ‘Eclipse Attacks on Bitcoin’s Peer-to-Peer Network.’ In the said paper, the authors discussed their findings from launching eclipse attacks, as well as possible countermeasures. 

In an eclipse attack, an attacker tries to redirect the target network participant’s inbound and outbound connections from legitimate nodes to the attacker’s nodes. By doing so, the target is sealed off from the actual network. 

Since the target is disconnected from the blockchain ledger, the isolated node can then be manipulated by the attacker. An eclipse attack can lead to block mining disruptions as well as illegitimate transaction confirmations. 

How easily blockchain attacks can be executed depends on the target blockchain network’s underlying structure.

Attackers typically use a botnet or phantom network to compromise a node and seal it off.

Crypto eclipse attacks can be carried out because the nodes in a decentralized network cannot simultaneously connect with other nodes because of bandwidth limitations. As such, nodes connect with a limited set of neighboring nodes instead. 

Hence, a malicious actor works to compromise the target user’s connection with the limited set of nodes that it connects to. An attacker uses a phantom network or botnet to compromise a node. This network is created from host nodes and is used to flood a target node with internet protocol (IP) addresses. The target may then sync up with it when it reconnects to the blockchain network. 

The attacker will then wait for the target to reconnect with malicious nodes or use a Distributed Denial of Service (DDoS) attack so that the target is forced to reconnect to the network. 

The worst part is that once a target node is compromised, the attacker can feed it false data. Usually, the victim is unaware that the node has already been compromised. Some of the consequences of eclipse attacks in crypto projects are:

• Miner power disruption: Blocks can be excluded from a legitimate blockchain when an attacker tries to hide the fact that a block has already been mined from an eclipsed miner. This misleads the victim into wasting processing power and time computing already compromised blocks.

The attacker is then able to increase their hash rate within the network. Since an eclipsed miner is disconnected from the legitimate network, attackers can then launch attacks on multiple miners and launch a 51% attack on the network. 

• Double-spend attacks:  A victim that is isolated from its legitimate network may be misdirected by an attacker to accept a transaction that uses either of the two:

  • An invalid input

  • The same input of an already-validated transaction on the legitimate network

When an attacker targets a network’s user, there is usually a deeper motive for doing so. Typically, eclipse attacks can serve as gateways for more complex attacks and disruptions.

0-confirmation double spends

A user is at risk of a double-spend if they accept a transaction with no confirmations. By principle, although the transaction has already been broadcast, the sender can still create a new transaction and spend the funds somewhere else. Double spends can occur until a transaction has been included in a block and committed to the blockchain. 

New transactions that have a higher fee can also be included before original transactions to invalidate earlier transactions. What’s risky about this is that some individuals and businesses are in the practice of accepting 0-confirmation transactions.

N-confirmation double spends

N-confirmation double spends are similar to 0-confirmation transactions. However, they require more complex preparation. Because a lot of businesses prefer to hold off on marking a payment as valid pending a certain number of confirmations, they can be vulnerable to attacks. 

In this scenario, attackers eclipse both miners and merchants. They pull it off by setting up an order with the merchant and broadcasting the transaction to eclipsed miners. This leads the transaction to be confirmed and included in the blockchain. However, this specific chain is not the right one as the miner has been cut off from the network earlier. 

The attacker then relays this blockchain version to the merchant, who then releases goods and/or services believing that the transaction has already been confirmed.

Weakening competing miners

Eclipsed nodes continue to operate as the target user is often unaware that they have been isolated from the legitimate network. As a result, miners will continue to mine blocks as usual. Blocks that are added will then be discarded upon syncing with their honest peers. 

Large-scale eclipse attacks executed on major miners are usually used to carry out a 51% attack. However, due to the incredibly high cost to take over Bitcoin’s hashing power majority, chances for this are still quite slim. At ~80TH/s, an attacker would theoretically need more than 40TH/s to succeed in such an attempt.

Theoretically, an attacker can eclipse any node as long as they have enough IP addresses. 

Operators can mitigate this risk by blocking incoming connections. Also, they should only make outbound connections to specific nodes that they trust, such as those on a whitelist by other peers in the network. Researchers have pointed out, however, that if all participants adopt these measures, new nodes might not be able to join — making it an approach that cannot be done at scale.

What the authors of ‘Eclipse Attacks on Bitcoin’s Peer-to-Peer Network’ suggest, however, is to implement a few tweaks to the Bitcoin software. Some of these tweaks have already been implemented since the paper was released. They work to make eclipse attacks costlier through minor changes in the code.

Both attacks take place at the P2P network level. So what’s the difference?  

In an eclipse attack, most peers of a targeted user are malicious and therefore prevent the targeted user from connecting to a legitimate network. An eclipse attack is particularly useful in instances when a sender sends some Bitcoin (BTC) to someone and then also double spends these Bitcoin. 

The sender then uses the attack to prevent the target user from finding out about the double spend.

In a Sybil attack, a malicious actor or attacker attempts to spam the network with nodes under their control in an attempt to game the network’s reputation system. This includes false signaling of support using version bits. In summary, an eclipse attack targets a single user or party while a Sybil attack targets an entire network.

In the context of Bitcoin, Sybil attacks are less harmful because nodes operate on consensus rules. Under these rules, any deviation will lead to having that same node DoS banned.

Developers can familiarize themselves with the vulnerabilities in Bitcoin nodes that can be exploited to replace legitimate peer addresses with their own.

• Technically, when the node selects IP addresses from the tried bucket with timestamps, it increases the probability of the attacker getting selected. This is true even if the attacker only owns a small portion of these addresses. Chances of getting selected can also be increased by increasing the attack time.

• When an address bucket is full, one address is removed at random. If an attacker’s IP is the one removed, then it can eventually be inserted if it is repeatedly sent to the node.

As you can see, attackers can exploit the above-mentioned vulnerabilities. However, there are also some ways to avoid them: 

• IP address selection from the tried table could be done at random. This would reduce the chances of the selected peer being an attacker. If peer selection is randomized, then the attacker will not be successful even after having spent a lot of time in the attack.

• Use a deterministic approach to insert addresses of peers into fixed slots. This will reduce the chances of inserting an attacker’s address into a different slot after having been evicted from the address bucket. A deterministic approach ensures that repeated insertion of addresses does not add value to an attack. 

As we mentioned, a lot of the vulnerabilities in Bitcoin have already been addressed. However, attacks on blockchain can still be carried out when attackers find other vulnerabilities. This is because blockchain networks are public. 

The open-source culture followed by a lot of blockchain organizations may also give way to further vulnerabilities.