What do Eclipse Attacks look like in blockchain?

When an Eclipse attack occurs, a hostile actor or attacker isolates a particular node or user within a peer-to-peer network.  He aims to conceal a user’s view of the peer-to-peer network to cause general disruption or plan more complex attacks.

The attacker tries redirecting the user’s inbound and outbound connections from his valid neighboring nodes to his controlled nodes. 

By “confusing” the valid current state of the blockchain ledger, the attacker can manipulate that isolated node in numerous ways that can lead to blocking mining disruptions or illegitimate transactions. 

The effectiveness of eclipse attacks, which rely on exploiting a user’s neighboring nodes, is heavily reliant on the underlying structure of the target blockchain network. In other words, it’s all up to the underlying structure. 

While most cryptocurrency protocols’ decentralized architecture makes them more difficult than other kinds of online attacks, eclipse attacks are still a great concern. It’s important to know how they operate and how to reduce the chance of being targeted by one so you can defend yourself.

How does the Eclipse attack work?

Usually, in an eclipse attack, attackers use a phantom network or a botnet to jeopardize a node and seal it off. Crypto eclipse attacks can be executed because the nodes in a decentralized network can’t at the same time connect with other nodes due to bandwidth limitations. So, nodes connect with a limited set of neighboring nodes instead.

Therefore, a violent actor works to compromise the user’s connection with the limited set of nodes. As we mentioned above, he uses a botnet or a phantom network to execute his actions. 

This network is created from host nodes and its purpose is to flood a node that is targeted with IP addresses. Then, the attacker waits for the target to reconnect with the harmful node or uses a DDoS attack, which is Distributed Denial of Service, so the user is forced to reconnect. 

To make things worse, once the target node is compromised, the attacker can give it false data. Usually, the victim is absolutely unaware of happenings. There are a few consequences of eclipse attacks: 

• Double-spend attacks: With the user being isolated from his valid network, he can be misdirected by the attacker to accept a transaction that uses either the same input of an already validated transaction or an invalid input.
• Miner power disruption: The attacker can disguise the fact that a block has been already mined. This situation misdirections users who are targeted into misusing time computing and processing power on already compromised blocks. 

Eclipse attack consequences

0 – confirmation

As we mentioned above, a user is at risk of double-spending if they accept a transaction without confirmation. Even though the transaction has already been broadcast, the sender can again create a whole new transaction and spend funds someplace else.

Double-spending can happen until a transaction has been involved in a block and committed to the blockchain. 

Transactions with higher fees can also be involved before the original transaction to disprove earlier transactions. The risky thing about this is that some businesses and individuals are practicing accepting 0-confirmation transactions. 

N – confirmation

These are similar to 0 – confirmation transactions. The thing is, they need more complex preparation. Businesses which prefer to hold off on marking a payment as valid can be vulnerable to attacks. 

In this scenario, an attacker eclipses both merchants and miners. They manage it by setting up an order with the merchant and then broadcasting the transaction to miners. And just like that, the transaction is confirmed and included in the blockchain. But this certain chain is not the right one as the miner has been excluded from the network earlier. 

Then, the attacker relays this new blockchain version to the customer, who believed that the transaction has already been confirmed, and releases services and goods. 

While the targeted user is completely unaware that they have been isolated from the network, eclipsed nodes continue to operate. Because everything seems to be okay, miners will continue to mine blocks as normal.

How to prevent Eclipse attacks

As long as attackers have enough IP addresses, they can eclipse any node. The easiest way to avoid this is for a node to limit inbound connections and be careful about connections made with other nodes.

On the other hand, this can make it more difficult for new nodes to join the network. Given the open-source and public nature of most blockchain projects, it is pretty easy for hostile users to evaluate their structural underpinning when looking for vulnerabilities to utilize. 

As structural changes are more difficult to implement and approve in the middle of a blockchain network’s lifecycle, the best advice for avoiding eclipse attacks is to create the blockchain network’s node configuration to withstand these attacks from the beginning. 

• Deterministic node selection: This approach differs from random node selection in that specific node IP addresses are inserted into defined fixed slots whenever they connect to the network. 

An attacker will have a harder time maneuvering malicious nodes through the network and converging on a target, and repeated implantation of attacker-controlled addresses will not necessarily aid an eclipse attack attempt. 

In the same way, a blockchain may include node identifiers into its network connection criteria to make reconnecting with genuine peers with higher trust ratings easier. 

The blockchain network will be more secure and less affected by third-party influences that deviate from good network activity if connections are made using identifying information rather than circumstantial data such as availability and timestamps. 

However, if connections may only be established to specific nodes that have been pre-approved by other peers, the network may suffer from scalability problems.

• Increased node connections: By raising the required number of node-to-node connections, a network may improve the chance that a node will connect to an actual person. 

However, there are node and bandwidth limitations that restrict how far a network may expand the number of node connections without losing performance, making this approach ineffective as a standalone solution to attack prevention.

• New node restrictions: By adding additional criteria to new node creation, the blockchain architect may establish a higher bar for hostile actors attempting to flood the network with attacker-controlled nodes. 

Frequently, this entails restricting the number of nodes per IP address or device, although an attacker may use a botnet composed of devices with their own unique IP addresses to overcome it.

• Random node selection: A blockchain structure may reduce the likelihood of a node connecting to an attacker-controlled node by structuring a peer-to-peer network in such a manner that each node is connected to a random set of IP addresses every time it syncs with the network, rather than following a repetitive, vulnerable set of node criteria.

Things we can learn from Eclipse attack

Developers can learn about the vulnerabilities in Bitcoin nodes that allow them to impersonate legitimate peer addresses and replace them with their own.

The probability of a node selecting IP addresses from the tested bucket with timestamps is actually greater than zero. This is true even if the attacker just has a little fraction of these addresses. The attack duration may also help raise your chances of getting selected.

One address is randomly removed from an aggregate once the bucket is full. If an attacker’s IP address is chosen, it can be reinstated if it is repeatedly sent to the node.

A tremendous amount of Bitcoin vulnerabilities have already been addressed. However, when attackers discover additional flaws, they may still mount assaults on blockchain networks. This is due to the fact that blockchain networks are open to the general public.

Use a deterministic method to fill fixed slots with the addresses of peers. This will reduce the likelihood of an attacker’s address being inserted into a different slot after having been thrown from the address bucket.

Because a deterministic technique establishes that identical entries are not beneficial to an assault, it decreases the likelihood of an attack’s success. Open-source environments that are prevalent in a lot of blockchain businesses may also lead to additional flaws.

Usually, eclipse attacks affect a limited set of targets or a single user, repeated attacks can weaken the trust within a blockchain network and in the end, destroy a network without real defenses. As a result, while considering the possibilities and tokenomics of your favorite blockchain projects, it’s also vital to understand the systems’ consensus algorithms.

While every cryptocurrency project requires a real-world application to survive the long run, without strong, tamper-resistant node connections, a network is unlikely to endure long enough to reach its full potential.