A Stealthier Partitioning Attack against Bitcoin Peer-to-Peer Network

TL;DR. We present the Erebus attack, which allows large malicious Internet Service Providers (ISPs) to isolate any targeted public Bitcoin nodes from the Bitcoin peer-to-peer network. The Erebus attack does not require routing manipulation (e.g., BGP hijacks) and hence it is virtually undetectable to any control-plane and even typical data-plane detectors. The Erebus attack also works against other cryptocurrencies with similar network codebase such as Litecoin, Bitcoin Cash, and ZCash (see below for the list). For technical details, please refer to our paper below.

NEW: For practical countermeasures, please visit https://erebus-attack-countermeasures.github.io.

Attack Overview

The Erebus attacker ISP's goal is to isolate one or more public Bitcoin nodes (currently around 10K active ones) from the rest of the network. By partitioning some Bitcoin nodes, an adversary can launch many serious attacks, including double-spending attacks, 51% mining attacks.

The adversary ISP can launch the Erebus attack without controlling any botnet but only with a simple desktop PC that implements some simple rudimentary Bitcoin node operations. The adversary should be a large enough ISP (e.g., Top-100 ASes) so that she can choose her target Bitcoin nodes with fewer restrictions. That said, all Tier-1 are shown to be able to choose any node from the 10K public Bitcoin nodes. Also, we show that large Tier-2 ASes can target most of the 10K public Bitcoin nodes.

We do not use routing manipulation (such as BGP hijacking) because such techniques leave undeniable evidence in the control plane of the Internet routing, making the attack obviously visible and revealing the attacker's identity to the public (see our paper for more detail).

Interestingly, the Erebus attack does not exploit any specific bugs (unlike the Eclipse attack by Heilman et al. but the topological advantages of adversary ISPs.

Main Results

Since the Erebus attack can be nearly invisible, the adversary ISPs can patiently wait for several weeks while slowly attacking the targeted Bitcoin nodes until finally the target is completely isolated from the rest of the Bitcoin network. The figure above shows one snapshot of an attack event we emulated via our Bitcoin network stack emulator (see our open source emulator).

We show in our emulation of Bitcoin core with real Bitcoin addr message logs that the Erebus attack can isolate a targeted Bitcoin node within 40 days after sending low rate attack traffic (e.g., 2 IP addresses per second). Since all the attack traffic is purely data plane and no control-plane evidence is left, the attack is highly invisible, compared to the partitioning attack using BGP hijacking by Apostolaki et al.


NEW: For practical countermeasures, please visit https://erebus-attack-countermeasures.github.io.

We have proposed several countermeasures and their quick summaries and current status are as follows. To check the evaluation of some of these solutions, please refer to our paper above. We will update the following table whenever we have changes of status (e.g., solutions are accepted to a new version of the Bitcoin core).

  1. Table size reduction Awaiting
    Reducing the size of the two tables storing peer IPs makes Erebus attack less effective because the adversary has much larger bandwidth capability and significantly more IP addresses than legitimate peers.

  2. More outgoing connections Bitcoin v0.19.0 Pull request #15759
    Increasing the number of outgoing connections (e.g., from 8 to 16) also makes Erebus attack significantly harder to occupy all the outgoing connections. Since Bitcoin v0.19.0, there are 10 outgoing connections in total.

  3. Selecting peers with AS topology information Bitcoin v0.20.0 Pull request #16702
    Incorporating AS topology in the peer selection can make attack becomes harder or impossible for the adversaries with IPs distributed in a large number of prefix groups but hosted in a few ASes only. Since Bitcoin v0.20.0, ASN-based grouping is included as a non-default setting.

  4. Smarter eviction policy In talks with Bitcoin core team
    An improved peer eviction policy that protects peers providing fresher block data will make censoring a specific block or transaction from the victim's view becomes less effective if there exists a legitimate incoming connection providing fresher blocks.

Frequently Asked Questions

    About the impacts

  1. Why is partitioning bad for Bitcoin and in general, blockchain-based cryptocurrencies?
    The consensus of cryptocurrencies can only work reliably with highly dependable underlying peer-to-peer networks. A partitioned network enables several attacks against the consensus such as 51% attack, selfish mining, censoring transactions or even taking down the cryptocurrencies at a large scale.

  2. Isn't several weeks too long to execute an Erebus attack?
    Yes and no. It requires a longer execution period than partitioning attacks with BGP hijacking (e.g., Apostolaki et al.). However, Erebus attack is nearly invisible. Serious attacker, such as nation-state adversaries, may find several weeks of attack time still negligible, considering the significant damage this attack can create.

  3. Which cryptocurrencies are vulnerable to Erebus attack?
    The Erebus attack can potentially have similar attack effectiveness against many other cryptocurrencies that have a similar network design and implementation to Bitcoin. Because of this, 34 out of 100 top cryptocurrencies are potentially vulnerable to the Erebus attack (as of July 2019).
    Disclaimer: Further investigation is needed to confirm the cryptocurrencies listed below (except Bitcoin) are indeed vulnerable to the Erebus attack.

  4. Has any one demonstrated or executed the Erebus attack in the real world yet?
    We haven't executed the Erebus attack on Bitcoin mainnet and testnet. All our tests were done in a safe emulation with real data. So far, we haven't heard any reports about previous or on-going Erebus attacks. Given the highly stealthy nature of the Erebus attack, however, we cannot answer this with confidence.

  5. Can the Erebus attack target and isolate ANY Bitcoin nodes?
    No. Bitcoin nodes that do not accept incoming connections (e.g., nodes behind NATs or connected via Tor bridge) are out of the scope of the Erebus attack.

  6. About the attacks

  7. Who can launch Erebus attack?
    The attacker AS needs millions of shadow IP addresses (in >=100 unique /16 or /32 prefix groups) and 5-6 weeks of attacking period. All the Tier-1 and many large Tier-2 ASes already have such capabilities.

  8. What is exactly the bug(s) the Erebus attack exploits?
    The Erebus attack does NOT exploit any bugs in the Bitcoin core software but the topological advantage of being a large ISP, sitting in the center of the Internet topology.

  9. What are the required resources (e.g., botnets) to launch the Erebus attack?
    No botnet is required for the Erebus attack. The adversary may need a single desktop PC to partition many Bitcoin nodes at the same time.

  10. Can the Erebus attack isolate multiple Bitcoin nodes at the same time?
    Yes. Mounting the Erebus attack against multiple Bitcoin nodes is trivial because it should only scale up bandwidth and the number of IP addresses linearly as the attack targets more nodes. For one target, it requires only 520 bit/s or 2 IP/s.

  11. Why is Erebus attack stealthy?
    Existing partitioning attacks using BGP hijacking (Apostolaski et al.) require the attacker to broadcast malicious control-plane messages (e.g., routing announcements) and thus it is completely visible to control-plane monitors, such as BGP message collectors and analysis tools. The Erebus attack, on the other hand, is a data-plane only attack and thus, undetectable by such monitor systems. Even if data-plane traces of the attack are captured, the perpetrator can easily deny the execution of the attack.

  12. How is the Erebus attack different from previous partitioning attacks?
    There are two previous partitioning attacks, i.e., the Bitcoin hijacking (by Apostolaski et al., IEEE SP'17) and the Eclipse attack (by Heilman et al., USENIX Sec'15). At a high level, Erebus attack has the same attack capabilities as the Bitcoin hijacking attack and similar attack strategy as the Eclipse attack. However, unlike the Bitcoin hijacking attack, Erebus attack is very stealthy. Also, it works against the latest version of Bitcoin core (v.0.18.0) while Eclipse attack is now infeasible. We summarize the comparison of Erebus attack with these two attacks as below.

  13. Bitcoin hijacking attack Erebus attack Eclipse attack
    Attack capabilities
    Network attacker? Yes Yes No
    Distributed computing resource required? No No Yes
    Route manipulation required? Yes No No
    Attack outcomes
    Effective against Bitcoin v0.18.0? Yes Yes No
    Attacks are visible and attributable? Yes No No

    About the defenses

  14. What should I do if I am currently running Bitcoin nodes?
    You should suspect if you are not receiving new blocks on time. Also, you should wait for Bitcoin Core updates.

  15. Is there any quick defenses against Erebus attack?
    Using proxies can be an effective mitigation against the Erebus attack. However, proxies also come with some problems, such as limited scalability and centralization.

  16. Can the relay systems (e.g., SABRE by Apostolaski et al.) handle the Erebus attack?
    Theoretically yes. Yet, we are concerned that such relay-based solutions would undermine the basic philosophy of decentralization in Bitcoin and other cryptocurrencies.

  17. Is there any defense at the routing layer?
    A future Internet architecture (e.g., SCION) that allows end hosts to control the inter-domain routes will address the Erebus attack. However, these clean-slate Internet architectures are still too costly to deploy at the moment.

  18. What's NEXT?
    We are actively playing with similar attack vectors and also designing a secure peer-to-peer networking stack for blockchains with security principles in mind. Please contact us if you are interested in collaboration!


Muoi Tran, National University of Singapore, muoitran@comp.nus.edu.sg
Inho Choi(*), National University of Singapore, inhochoi@comp.nus.edu.sg
Gi Jun Moon(*), Korea University, shangmoon@korea.ac.kr
Anh V. Vu(*), Japan Advanced Institute of Science and Technology, anhvv@jaist.ac.jp
Min Suk Kang, National University of Singapore, kangms@comp.nus.edu.sg

(*): This research was done while the authors were working as interns at National University of Singapore.

© Muoi Tran. Design: Yen-Chia Hsu. Last update on 23 April 2021.