People have tried to develop many different attack vectors on cryptocurrencies, from codebase flaws, cryptographic algorithms, mining processes, consensus protocols and block propagation mechanisms to the underlying network layer. Most attacks could be patched quickly by modifying the source code, but preventing attacks that exploit the network layer remains a non-trivial problem as the network layer heavily relies on the existing Internet infrastructure, which is impractical to change. So network-layer attacks could be dangerous, powerful and hard to mitigate.

In this post, I would like to introduce some recent attacks against the Bitcoin P2P network. The first exploits a vulnerability in the Bitcoin codebase to occupy all of a victim’s connections, whereas the latter two exploit the capability of network adversaries to break Bitcoin’s underlying network layer. The implications of those attacks can vary, from selfish mining leading to a majority attack and double-spending, or even worse, a service denial attack that takes down a cryptocurrency.

[1] Eclipse Attacks on Bitcoin’s Peer-to-Peer Network by Ethan Hellman, Alison Kendler, Aviv Zohar and Sharon Goldberg (USENIX 2015)

This attack exploits a vulnerability in the internal IP table management and peer selection mechanisms of Bitcoin nodes to arbitrarily insert malicious IP addresses into the IP table, eventually evicting all legitimate ones. It allows any adversary who controls a large enough range of IP address to monopolise all of the victim’s inbound and outbound connections. After occupying enough slots in the victim’s IP table, the adversary triggers the node to restart; then there is a high probability that the victim node will establish all of its new connections to IP addresses controlled by the attackers.

The Bitcoin core at that time (v0.9.3) had a vulnerability (now fixed) which made it rather simple to populate IP addresses to a Bitcoin node’s internal IP table. The attack required very low-rate TCP connections and could be launched as long as the adversary had enough IP address space. To obtain a sufficient number of IP address, the authors described two possible scenarios: using a botnet and taking over infrastructure; both were feasible enough to make the attack practical. By estimating the number of IP address and prefix groups needed, they concluded that a botnet attack was far superior to using infrastructure as it requires much fewer IP addresses.

Thanks to this work, the Bitcoin core team implemented several countermeasures to mitigate the attack, notably by changing the IP table management mechanism and increasing the bucket and IP table size; these changes make the Eclipse attack much harder in practice. Another set of fixes also make the attack infeasible with botnets. As it could be mitigated quickly by patching the core software, this attack is no longer possible on Bitcoin at present.

[2] Hijacking Bitcoin: Routing Attacks on Cryptocurrencies by Maria Apostolaki, Aviv Zohar and Laurent Vanbever (IEEE S&P 2017)

This was the first paper to study the impact of routing attacks against Bitcoin. Besides presenting a novel and feasible attack, it shows that Bitcoin is heavily centralised as the majority of the entire Bitcoin network is hosted on a small number of ASes; worse, 3 ASes can intercept roughly 60% of Bitcoin traffic.

This is a control-plane attack, which utilises the routing manipulation to intercept Bitcoin traffic from/to the victim nodes directly. The high-level idea is using BGP hijacking to seize control all of the most-specific IP prefixes (up to /24) pertaining to the victims; in particular, they are prefixes containing the IP address of the targeted nodes. Then, by controlling all the victim’s inter-domain routes, the adversary can arbitrarily drop/modify/delay Bitcoin messages pertaining to the victim. Eventually, the attacker can isolate victims from the rest of the network, partitioning the network into two disjoint components. Even if a perfect cut cannot be established, the adversary can still delay blocks propagation to victims. The paper shows that intercepting 50% of a victim’s connections can result in its being not informed of the most recent propagated blocks ∼60% of the time.

To evaluate the attack performance, the authors first ran an actual BGP hijack against their own Bitcoin nodes, showing that it actually works in practice. They conclude that it is possible to isolate roughly half the mining power by hijacking less than 100 prefixes. They also show that a large number of hijacks targeting Bitcoin nodes are happening regularly (however, a longitudinal analysis in [3] below found that this kind of hijacks is just misconfiguration). Some deployable countermeasures were proposed, including both short-term and long-term patches. 

[3] A Stealthier Partitioning Attack against Bitcoin Peer-to-Peer Network by Muoi Tran, Inho Choi, Gi Jun Moon, Anh Viet Vu, Min Suk Kang (IEEE S&P 2020)

The Hijacking Bitcoin paper above shows how to partition the Bitcoin network, but this attack is naturally visible and globally observable by the rest of the Internet as malicious BGP route announcements need to be broadcast widely and many people watch for such announcements. So the perpetrator could face rapidly detection and attribution. This paper investigates the number of BGP hijacking messages actually targeting Bitcoin nodes by analysing billions of relevant BGP announcements from September to December 2018, and shows that all the suspicious cases found are just misconfigurations rather than intentionally targeted. In other words, no significant Bitcoin hijacking attack was recorded in this 4-month period.

The authors then proposed the Erebus attack, which aims at partitioning the Bitcoin network. Using a data-plane rather than a control-plane attack, Erebus exploits the essential topological advantage of large AS/ISPs, making it undetectable in both control plane and data plane. The high-level idea is that a capable attacker who controls a lot of IP address space can do an industrial-scale man-in-the-middle attack, by operating millions of virtual Bitcoin nodes at “shadow IPs”, namely IP addresses where the victim-to-IP-address routes pass through the adversary’s network. When the attack is executed, the adversary patiently evicts legitimate IPs in the Bitcoin victim node’s internal IP table in favour of the impersonated shadow IPs, followed by adaptively triggering the node to restart after seizing control of enough peering connections. Eventually, the victim node can be completely isolated from the rest of the network while being unaware of the attack.

It is shown that the attack is feasible for large AS/ISPs, only needs a few weeks of execution and can be executed with a trivial traffic rate. The authors note that a range of top cryptocurrencies (by market value) share the Bitcoin core codebase, and a significant number among them are still using out-of-date code, making them potentially vulnerable to the Erebus attack. By showing that distributed permissionless ledgers still rely heavily on the current Internet infrastructure, the paper reminds us that blockchain systems may be insecure against powerful AS-level adversaries. Some countermeasures are proposed for mitigating this attack, and some of these are being implemented by the Bitcoin developer team. However since the attack does not exploit any particular vulnerabilities of the Bitcoin core, it is still hard to eliminate Erebus completely.