Information Eclipsing an attack on Bitcoin’s secure network : A MAJOR FLAW

Bitcoin network is secure if honest nodes hold at least 51% of the mining power, which relies on an assumption that all parties (nodes) see valid blocks/transactions. Bitcoin relies on its own peer-to-peer network to deliver this information. This paper exploits this very nature of a node of relying on a peer-to-peer network for information (which also happens to be the backbone of bitcoin system) with an attacker controlling what an honest node receives from network by attacking the network itself (information eclipse) instead of having to gain majority CPU power for solving the problem first (essentially adding a block in chain) in order to commit fraud.

How can an attacker make use of eclipse attack?

The attack allows the attacker to launch a 51% attack (majority power) with only 40% mining power or so. For example, imagine a network with 3 large mining nodes. Two control 30 percent of the mining power and are honest while the remaining 40 is controlled by attacker. The attacker can partition the other 2 miners so that they cannot build a connection with each other and hence cannot receive a version of other miner's blockchain, giving attacker a chance to out-compete each partitioned miner. As a result, the attacker’s blockchain becomes the consensus block chain.

This is called an information eclipse attack where an attacker gains control over a node’s access to information in the peer-to-peer network. With proper manipulation of the peer-to-peer network, an adversary can eclipse a node so that it is only communicating with malicious nodes.

How does an attacker go about eclipsing a node?

To do this, an attacker can manipulate the node so that all its outgoing connections (a Bitcoin node typically has 117 incoming TCP connections and a maximum of 8 outgoing TCP connections, by default) are to attacker IPs. This can be done simply. First, fill the node’s peer tables (I have explained these below) with attacker IPs. Then, the node restarts and loses its current outgoing connections. Finally, the node makes new connections only to the attacker IPs. Note that this attack affects only those nodes which accept incoming connections because not all nodes are accepting incoming nodes.

One question is how easy are restarts? The attack requires the users’ nodes to restart. However, this occurs fairly frequently because of software updates and power/network failures. As a result, Bitcoin assumes that the uptime of the node is 100% for prevention of this attack, which seems unreasonable.

Ethan Heilman from Boston University demonstrated some worrying attacks on the Bitcoin network in his very interesting talk which I have summarised below...

He explains that the vulnerability lies in the core client software (bitcoin node software) and so does the solution - There are two divisions maintained in software for the peer table, hence two peer tables as such. 1) New table : storing IPs the node has heard about 2) Tried table : storing IPs the node peered with at some point. The tables also store a time stamp for each IP. Nodes picks up IP addresses from here to query blockchain from.

In our attack we fill these tables with attacker's IPs, so that the node will only connect to attacker's IP. You see this is possible because the software has some rules to find an IP to make an outgoing connection to, which are as follows:

• choose new or tried tables to select from.
• select an IP (biased towards "fresher" timestamps).
• attempting an outgoing connection to the IP.

Vulnerability : Bias selection. Hence, attacker ensures its IPs are fresher, so they are more likely to be selected.

He also provided a solution to counter this attack. To prevent the attacker's IP from being selected Bitcoin should randomly select IPs with no bias toward fresher timestamps. The attacker exploited eviction bias toward older IPs and exploited the randomness in the eviction process to improve the odds of filling tried table by running the attack multiple times.
Another problem is that the tried table fills up very slowly and contains mostly dead IPs. To prevent this, Bitcoin should make test connections to IPs to fill tried tables faster and should not evict them if they are still online.

Some of these countermeasures have been included and patched. But this work surely demonstrates that Bitcoin’s security model, like any other security model, is flawed and requires further investigation.

Moreover, with UASF (User Activated Soft Fork) - BIP 148 in line, bitcoin has many more problems to solve before it really becomes a gold like asset in future.