Eclipse Attack

From this post by FlatOutCrypto (7-6-2018):

"An Eclipse Attack is a means of attacking a decentralized network through which an attacker seeks to isolate and attack a specific user(s), rather than attack the whole network (as in a Sybil Attack). A successful Eclipse Attack enables a would-be bad actor to isolate and subsequently prevent their target from attaining a true picture of real network activity and the current ledger state.

This attack is made possible because a decentralized network does not let all nodes simultaneously connect to all other nodes on the network. Instead, for efficiency, a node connects to a select group of other nodes, who in turn are connected to a select group of their own. For example, a Bitcoin node has eight outgoing connections; Ethereum 13.

A malicious actor would aim to hijack all of these connections. The effort required to achieve this varies by the construct, size, and nature of a network, but generally an attacker would have to control a botnet of host nodes (each with their own IP address) and work out (essentially by trial and error) the neighboring nodes of an intended victim. The next time the victim node logs off and then rejoins the network (resetting their connections, and forcing them to find a new set of nodes to connect to) the attacker has a good chance of being in control of all of the victim’s connections.

How do attackers profit from an Eclipse Attack?

Once a malicious actor has isolated a user by taking control of all outgoing connections they are able to exploit them by, for example, carrying out a 0 confirmation double spend attack. If User A is the malicious actor, User B is the isolated node and User C is another network entity, then User A would be able to send a payment to User C and then send the same transaction to User B. User B is unaware that those funds have already been spent as all their outbound connections route through User A who is able to suppress and manipulate what information User B receives. User B will accept the coins and only later when they connect to the ‘true’ blockchain, will they find out that they have been duped and have in reality received nothing.

An attacker may also use an eclipse attack to attack the blockchain itself, hijacking the mining power of an isolated node(s). The victim, seeing only the ledger that the attacker is showing, will lend their support to this variant of the chain. If the attacker can attack enough users (and bearing in mind some miners may control significant amounts of hashing power) they would be able to establish their own chain as a legitimate fork to the ‘true’ ledger. Gain enough support and that becomes the ledger.

Other potential Eclipse Attack effects on a PoW network such as Bitcoin, as noted in the 2015 paper by Heilman, Kendler, Zohar and Goldberg, include:

Engineering block races: Two miners discover a block simultaneously; an Eclipse attack would mean that eclipsed miners waste mining effort on orphan blocks as the attacker can ‘hide’ the discovery of mined blocks from victims and then release once a competing block has been found
Splitting mining power: In an effort to make it easier to launch 51% attacks a malicious actor could eliminate eclipsed miners from the network and in doing so reduce the number of active miners
N-confirmation double spend: Most merchants wait until a number (N) of blocks have been confirmed before releasing their goods to prevent double spend attacks. However, if enough miners have been eclipsed then an attacker can launch a double spend attack against an eclipsed merchant in spite of this. An attacker would be able to present their transaction to eclipsed miners, who add it to their ledger. This state is then shown to the merchant who cannot know better, given they too have been eclipsed and removed from the wider network. Once the merchant has sent the reciprocal goods to the attacker then the eclipsed miners’ ledger is discarded and the merchant is left empty-handed

Can Eclipse Attacks be prevented?

The ease with which an Eclipse Attack can occur depends on a number of factors, including a network’s data structure, how many connections each user has and if users can start up many nodes on a single IP address or if they require a unique IP address per node.

A research report published in March 2018 Low-Resource Eclipse Attacks on Ethereum's Peer-to-Peer Network by Marcus, Heilman and Goldberg laid bare these concerns. The report made clear that prior to the report’s publication an attacker with “only two hosts, each with a single IP address” could completely isolate a node. This is due to both the structured network of Ethereum (a structure known as Kademlia) and because nodes can run multiple nodes from the same IP address. An equivalent attack on the unstructured Bitcoin network is far more difficult as it would necessitate the use of hundreds of unique IP addresses, despite each node having fewer connections than Ethereum.

However, as the Ethereum developers noted in the aftermath of the report, “as far as we know, the bar has been raised high enough that eclipse attacks are not feasible without more substantial resources”, a statement applicable to other DLTs too.

Unfortunately, there are attackers with substantial resources and potential attack vectors for an Eclipse Attack against DLTs remain, particularly if the attacker has access to a botnet or can hijack an Internet Service Provider. Heilman et al’s 2015 paper illustrated how susceptible networks are to these more resource intensive attacks noting that “an attacker with 32 distinct /24 IP address blocks, or a 4600-node botnet, can eclipse a victim with over 85% probability in the attacker’s worst case”. While countermeasures have been introduced since, it highlights the ease with which Eclipse Attacks can be implemented with relatively small amounts of resources.

As the value of networks and the transactions happening across them continues to grow, so too do the incentives to dedicate significant resources to an attack. An Eclipse Attack is difficult for permissionless decentralized networks to defend against but there are a number of fixes that can make them harder to achieve:

Random node selection: One of the issues with Ethereum is the usage of Kademlia, which does not randomize a node’s search for new connections and therefore allows an attacker to be able to create nodes which will be selected by the victim. Randomizing this selection with peers spread across the network would make this harder for an attacker to guess at what nodes they should create to target a victim
Limit number of nodes per IP address/machine: This was one of the biggest flaws identified in Marcus et al’s paper and one of the easiest to address
Information storage: Nodes store information about other nodes as they encounter them; keeping this information accessible after a node leaves and rejoins the network would ensure they can keep some legitimate peers to connect to before finding others
Increase the number of connections; Whilst this cannot be an infinite number, as it would slow down the network, the more connections allowed the more likely it is that a node will connect to a legitimate user

Eclipse attacks are perhaps less immediately dangerous to a network as a whole, but they are also arguably more likely to take place and the immutable nature of blockchain means that there is no-one able to restore lost funds in the event of a successful attack. If the attacks became common then trust in the network would be eroded and the system would ultimately face a crisis."