An eclipse attack is a P2P (Peer to Peer) network-based attack. Eclipse attack can only be performed on nodes that accept incoming connections from other nodes, and not all nodes accept incoming connections.
In a bitcoin network, by default, there are a maximum of 117 incoming TCP connections and 8 outgoing TCP connections.
According to Gemini – In eclipse attack, the attacker attempts to redirect the target user’s inbound and outbound connections away from its legitimate neighboring nodes to attacker-controlled nodes, thereby sealing off the target in an environment that’s entirely separate from the actual network activity.
In other words, gaining control over node access to information in a P2P network is an Eclipse attack. The attacker positions itself in such a manner that all the incoming and outgoing connections of the target are attacker nodes.
Working of Eclipse Attack:
Eclipse attacks are possible because nodes within the network are unable to connect with all other nodes and can connect with a limited number of neighboring nodes. This limitation might make it seem convenient for attackers to isolate a node from the rest of the network, but it is not an easy task. Let’s now discuss how is it done.
- How Could An Attacker Isolate a Node: The attacker generally has to make use of a botnet to carry out this task of isolating a node completely and it might take several attempts to do so. One of the doable ways is a phantom network created from host nodes to flood the target node with a ton of IP addresses, which the target may sync up with the next time it reconnects with the blockchain network. From this point, the attacker waits for the target to connect to malicious nodes.
Consequences of An Eclipse Attack:
During an Eclipse attack, the attacker hides the actual current state of the blockchain ledger from the target, by doing that the attacker can perform:
- Double Spending
- Miner Power Disruption
-
Double Spending: Double-spending is a potential flaw in a digital cash scheme in which the same single digital token can be spent more than once. For Example: Suppose you gave 10₹ to the shopkeeper, now they are no longer yours, you can’t use the exact same 10₹ note again, but if you’re double-spending, you’re using the exact same note again. Which you might have guessed, is not legal to do. Similarly, on a blockchain network, suppose you spent 10 bitcoins (that’s a lot of bitcoins) to buy a house, these 10 bitcoins get stored in a mempool as a transaction and this transaction gets broadcasted on the network, and those 10 bitcoins get deducted from your wallet.
- Double spending through Eclipse attack: Suppose you are the attacker and all your attacker nodes account for 40% of the overall hashing power of the network, and the target node accounts for 30% of hashing power, also the remaining network has 30% hashing power. Now, you spend 10 bitcoin on the public network and inform all other nodes on the network except the target node, the merchant receives the payment, and 10 bitcoins get deducted from your wallet. Then, you inform the target node about a false transaction that sends 10 bitcoins from the seller to your (attacker’s) account. Since your hashing power when combined with the target’s hashing power reaches 70%, you will mine the blocks fastest, so your chain will be the longest, and as discussed earlier, it will be validated by the network, therefore, those10 bitcoins will be transferred from the seller’s account back to your account, and you can use those 10 bitcoins again.
- Miner Power Disruption: The attacker can hide the information that a block has been mined from the target, thereby misleading the victim into wasting computing power mining orphaned blocks. An orphaned block is a block that has been solved within the blockchain network but was not accepted by the network. This way, the attacker is able to increase their relative hash rate within the network and bias the block mining race in their favor. Another way is combining the target’s ability to mine blocks faster as we saw in double-spending, collaborating with the target to combine your hashing power.
- Transaction censorship: The attacker can censor transactions from the target by preventing them from being included in the blockchain. This can lead to delays in transactions or even the failure of transactions, which can harm the network’s usability and reputation.
- Sybil attacks: In an Eclipse attack, the attacker may use Sybil attacks to create fake identities and nodes to manipulate the target. By creating a large number of fake nodes, the attacker can increase their influence in the network and undermine the target’s ability to verify the authenticity of the network.
- Centralization: An Eclipse attack can lead to centralization of the network, where a few nodes or a single entity gains control over the network. This can undermine the decentralization and security features of the network, leading to a loss of trust in the network by users and stakeholders.
- Network instability: An Eclipse attack can cause network instability, as the target node may be overwhelmed with traffic or disrupted from the rest of the network. This can lead to a breakdown in communication between nodes, making it difficult to maintain consensus and verify transactions.
- Financial loss: An Eclipse attack can lead to financial loss for the victims, as the attacker may be able to carry out fraudulent transactions, double-spending, and other malicious activities. This can lead to a loss of trust in the network and a decline in its overall value.
Prevention of Eclipse Attack:
- Increased node connections: If each node in the network gets connected to a large number of nodes, it will get difficult for the attacker to isolate the target in the network, thereby reducing the possibility of an Eclipse attack.
- Random node selection: The network should be designed in such a way, that each node connects to a random set of nodes when it comes in sync with the network.
- Secure communication: The nodes in the network should use secure communication protocols such as SSL/TLS to encrypt the data transmitted between them. This prevents attackers from eavesdropping on the communication and gaining information that can be used to launch an Eclipse attack.
- Regular updates: The software running on each node should be updated regularly to ensure that it is free from known vulnerabilities that can be exploited by attackers.
- Diverse implementation: The network should encourage the use of diverse implementation of the software running on each node. This makes it difficult for attackers to exploit a common vulnerability across all nodes in the network.
- Use of firewalls: Firewalls can be used to filter traffic to and from each node in the network. This helps to prevent attackers from sending malicious traffic to the target node and also helps to prevent the target node from sending malicious traffic to other nodes in the network.
- Monitoring: The network should be monitored for any unusual activity or traffic patterns. This can help to identify and mitigate an Eclipse attack before it causes significant damage to the network.
- Redundancy: The network should be designed with redundancy in mind. This means that there should be multiple nodes providing the same service, so if one node is compromised, the network can still function without disruption.
- Peer review: The code of the software running on each node should be reviewed by peers to ensure that it is free from any vulnerabilities that can be exploited by attackers.
- Education: Users of the network should be educated on how to identify and prevent Eclipse attacks. This can help to prevent attackers from gaining access to the network through social engineering techniques such as phishing.