Skip to content

Hijacking Bitcoin: routing attacks on cryptocurrencies

June 27, 2017

Hijacking Bitcoin: routing attacks on cryptocurrencies Apostolaki et al., IEEE Security and Privacy 2017

The Bitcoin network has more than 6,000 nodes, responsible for up to 300,000 daily transactions and 16 million bitcoins valued at roughly $17B.

Given the amount of money at stake, Bitcoin is an obvious target for attackers.

This paper introduces a new class of routing attacks on the network. These aren’t supposed to be feasible since Bitcoin is a vast peer-to-peer network using random flooding. However, look a little closer and you’ll find:

  1. The Internet infrastructure itself is vulnerable to routing manipulation (BGP hijacks), and
  2. Bitcoin is really quite centralised when viewed from a routing perspective.

Suppose for a minute it was practical to intercept or otherwise manipulate connections (you’ll soon see that it is):

As Bitcoin transactions are routed over the Internet – in clear text and without integrity checks – any third-party on the forwarding path can eavesdrop, drop, modify, inject, or delay Bitcoin messages such as blocks or transactions.

Seventeen billion dollars, clear text, no integrity checks!

It turns out that if you can hijack less than a hundred BGP prefixes (feasible) you can isolate about 50% of the mining power in the network. Once a collection of nodes are partitioned from the network the network becomes more vulnerable to double spending attacks, transaction filtering, and selfish mining attacks.

Nodes representing merchants, exchanges, and other large entities are thus unable to secure their transactions, or may not be able to broadcast them to the the network to begin with. The resulting longer-term loss trust in Bitcoin security may trigger a loss of value for Bitcoin. Attackers may even short Bitcoin and gain from the resulting devaluation.

The authors also demonstrate delay attacks which are effective against individual targets, but not against the network as a whole as the partitioning attacks are.

The core building block: BGP hijacking

BGP (Border Gateway Protocol) is the routing protocol that controls how packets are forwarded in the Internet. Routes are associated with IP prefixes, and are exchanged between neighbouring networks (Autonomous Systems, AS). The origin AS makes the original route announcement, and this then propagates through the network hop by hop.

In BGP, the validity of route announcements is not checked. In effect, this means that any AS can inject forged information on how to reach one or more IP prefixes, leading other ASes to send traffic to the wrong location. These rogue advertisements, known as BGP “hijacks”, are a very effective way for an attacker to intercept traffic en route to a legitimate destination.

If you want to hijack the traffic for a particular prefix, you can either advertise the same prefix (in which case you will attract traffic that is ‘closer’ to you than the genuine owner), or you can advertise a more specific (longer) prefix (up to /24) in which case longest match (i.e., yours) always wins. By leaving at least one path from the attacker to the destination untouched, a BGP hijack can be turned into an interception.

Is it really that simple to hijack Internet traffic??? I mean, does this really happen in practice? Sure it does! As evidence, the authors analysed six months of BGP updates (that’s 4 billion of them) to look for hijacks.

We see that there are hundreds of thousands of hijack events each month. While most of these hijacks involve a single IP prefix, large hijacks involving between 300 and 30,000 prefixes are also seen every month.

That’s all pretty alarming in general, but here we’re just focused on the Bitcoin specific nodes. Each month, at least 100 Bitcoin nodes are victims of hijacks. In November 2015 as an example, 7.8% of the network nodes were hijacked.

The structure of the Bitcoin network

The vulnerability of the Bitcoin network overall to routing attacks depends on the routing characteristics of the Bitcoin network itself. The conduct a study (details in section VI) to uncover the Bitcoin network topology. The key findings are as follows:

  • Unsurprisingly, there seems to be some kind of power law at play whereby a few ASes host most of the Bitcoin nodes. E.g., only 13 ASes hosts 30% of the entire Bitcoin network.
  • Just a few ASes naturally intercept the majority of Bitcoin traffic. Hurricane Electric, Level3, and Telianet for example, can together intercept more than 60% of all possible Bitcoin connections.

  • Over 90% of Bitcoin nodes are vulnerable to BGP hijacks. 93% of them have prefixes shorter than /24!
  • Mining pools are multi-homed and all use at least two ASes to connect to the Bitcoin network. Multi-homing is one of the main protections against routing attacks.
  • Bitcoin routing protocols are stable over time – the same IPs are present on average for 15.2 consecutive days.

Partitioning attacks

The goal of a partitioning attack is to isolate some set of nodes P from the rest of the network, effectively partitioning the Bitcoin network into two disjoint components. It may be that not all of the nodes in P can be isolated (due to ‘leakage points’ from connections in P that can’t be intercepted – e.g., a peering agreement between mining pools using private connections). So ultimately we try to find the maximal subset of P that can be partitioned off.

The attacker first diverts the traffic destined to nodes in P by hijacking the most-specific prefixes hosting each of the IP address. Once on-path, the attacker intercepts the Bitcoin traffic (e.g., based on the TCP ports) and identifies whether the corresponding connections cross the partition she tries to create. If so, the attacker drops the packets. If not, meaning the connections are contained within P, she monitors the exchanged Bitcoin messages so as to detect “leakage points”. Leakage points are nodes currently within P, which maintain connections with nodes outside of P that the attacker cannot intercept…

These leakage points are dropped from P until the maximal set of nodes that can be isolated is left.

The authors demonstrate the practicality of the attack by hijacking their own nodes:

First, we performed a real BGP hijack against our Bitcoin nodes and show that it takes less than 2 minutes for an attacker to divert Bitcoin traffic. (Emphasis mine)

Second, we estimated the number of prefixes to hijack so as to isolate nodes with a given amount of mining power. We found that hijacking only 39 prefixes is enough to isolate a specific set of nodes which accounts for almost 50% of the overall mining power. (Emphasis mine)

Delay attacks

Delay attacks slow down the propagation of new blocks sent to a set of Bitcoin nodes, without disrupting their connections. The attack can be targeted at selected nodes, or in theory conducted network wide. The authors’ analysis though shows that network wide attacks are not really feasible. To carry out a delay attack, the attacker first intercepts traffic using BGP hijacking with a forwarding route left open, and then tampers with the incoming and/or outgoing protocol messages. By tampering with outgoing GETDATA requests, a requesting node will never receive the blocks it is asking for. By tampering with incoming BLOCK messages the content can be corrupted so that the victim considers it invalid. Each of these actions triggers a 20 minute timeout.

We verified the practicality of delay attacks by implementing an interception software which we used against our own Bitcoin nodes. We show that intercepting 50% of a node’s connections is enough to keep the node uniformed for 63% of its uptime.

For 68% of the nodes in the Bitcoin network, there is at least one AS other than their provider that intercepts more than 50% of their connections.

Countermeasures

The authors recommend the following short-term measures:

  • Increase the diversity of node connections, for example by ensuring that all Bitcoin nodes are multi-homed.
  • Select Bitcoin peers in a route-aware way, adding extra random connections if the same AS appears in all paths.
  • Monitor RTT to detect sudden changes (increases) and establish extra random connections as a protection mechanism.
  • Monitor additional statistics as early warning signals of an attack: distribution of connections, request-response intervals, simultaneous disconnection of peers, and so on.
  • Embrace the natural churn of the network to continually refresh connections
  • Use gateways (for mining pools) in different ASes
  • Prefer peers hosted in the same AS, and in /24 prefixes

Longer term, Bitcoin can encrypt connections and/or use a Message Authentication Code to detect tampering. The authors also recommend separating control and data channels, negotiating a set of random ports on connection that will be used to exchange Bitcoin data. This forces an AS-level adversary to look at all traffic, not just the port 8333, which would be very costly. Other suggestions include adding UDP heartbeats to detect interception, and ensuring that any block requests are made on multiple connections in parallel. Ph

The last word

Our work underscores the importance of proposed modifications which argue for encrypting Bitcoin traffic or traffic exchanged among miners. Yet, we stress that not all routing attacks will be solved by such measures since attackers can still disrupt connectivity and isolate nodes by dropping Bitcoin packets instead of modifying them.

11 Comments leave one →
  1. June 27, 2017 10:56 am

    > Longer term, Bitcoin can encrypt connections and/or use a Message Authentication Code to detect tampering.

    Bitcoin does not need encryption to validate if a message is correct – every block has a proof-of-work and get validated if every transaction is valid. And you can only forge a transaction if you have the private key for all inputs it spents.

    If you’d add an encryption and/or MAC – who would you authenticate against? How would you know that peer X with a certain “authX” is a valid peer? That is the core problem bitcoin solves (by using PoW and full history verification of the blockchain)

    • June 27, 2017 4:17 pm

      Indeed, the best you could do with encryption/MAC is detect if peer X suddenly changed to peer Y. There is no way no way to detect if peer X was bogus or not in the first place.

      • June 28, 2017 8:51 pm

        But there is a ton of value in that. That’s the philosophy behind public key pinning, which many browsers now support.

        Of course, it won’t help if a MitM has you before your very first interaction, but it still greatly increases security. “Perfect is the enemy of good” etc.

  2. shenobie permalink
    November 7, 2017 5:54 am

    Nice post

Trackbacks

  1. Bitcoin News Digest Tuesday, June 27, 2017 - zentrade.online
  2. July 2 2017, Episode 392, Show Notes |
  3. Blockbench: a framework for analyzing private blockchains | the morning paper
  4. Hijacking Bitcoin: routing attacks on cryptocurrencies https://blog… | Dr. Roy Schestowitz (罗伊)
  5. Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - Nerd Junkie
  6. Hijacking Bitcoin: routing attacks on cryptocurrencies – PLANET CRYPTO
  7. SmartPool: Practical decentralized mining | the morning paper

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: