Security Threats to Blockchain Networks — 4 — Network Attacks
Network attacks are a class of exploits that focus on the isolation and manipulation of individual nodes or groups of nodes. While blockchain networks are theoretically robust against such attempts, both hackers and academics have found loopholes that can be used not only to defraud and damage individuals, but also scale up to take down entire exchanges. While easily overlooked, the list of network attacks is likely to grow in the years ahead, and is worth preparing for.
A blockchain network is powered by the exchange of information between nodes. These are the individual ‘worker ants’ whose collective strength makes the system function, and whose distributed nature makes the network secure. According to the logic, it is hard to corrupt a network of nodes, because you have to corrupt each one individually.
To take a political analogy, a blockchain is similar to Switzerland, as opposed to a traditional centralized network, which is more like a banana republic.
In order to influence the public policy of the latter, you would need to bribe a dictator and a perhaps a handful of officials. Switzerland, on the other hand, is so decentralized that a well-traveled, well-educated citizen may well be unable to tell you who the country’s president is. Small though it is, altering Swiss national policy would involve a tedious process of traveling from kanton to kantons, and likely end in the failure to secure a majority.
As we know from the existence of consensus-based attacks, the Swiss-like nature of blockchains is not 100% proof against incursions from malevolent actors. And decentralization of consensus is more or less irrelevant when the ambitions of the attackers are focused on an individual kanton/node, with the aim of influencing a specific transaction.
Rather than raising an entire army to seize control of the radio stations, train depots, and post offices like traditional revolutionaries, Network Attacks are more like sending a commando unit to waylay a vehicle carrying precious cargo, blow up a power station, or kidnap a foreign dignitary.
As with all categories of attack, there are multiple variants, and in this article we’ll be covering those most commonly discussed.
Nodes in a Proof of Work (PoW) system are in theory vulnerable to a series of maneuvers that can be used to fake and/or reverse transactions by identifying loopholes in the mining process.
In a Finney attack, an attacker mines a block as usual, including a transaction that sends coins to his account. Before broadcasting it, however, he sends the same coins to a merchant and receives a service in return. When the originally mined block is broadcast, the transaction to the merchant is erased.
Another variant of this is a Race attack, whereby an attacker creates two conflicting transactions, one sending payment to the victim, and another returning an identical amount to the attacker. Since one transaction must prevail, if the second transaction invalidates the first transaction, the victim is left out of pocket.
Combining the two approaches above in a so-called Vector76 attack, an attacker can broadcast two transactions to his own account, one high-value, and one low-value. The high amount is deposited, but the network accepts and records the low amount.
While these ‘classical’ tactics appear in almost every list of blockchain cyberattacks, they are difficult to achieve in practice, and can be guarded against by adjusting the parameters for accepting transactions (e.g. insisting that they be confirmed by the network). They serve as useful illustrations of how one can defraud a node.
A routing attack relies on disrupting communication between nodes. Attackers conspire to block or delay transactions emanating from a particular node or network of nodes, rendering the mined blocks temporarily or permanently unrecognized by the wider network.
The strategy comes in two main varieties: a partitioning attack involves completely separating a set of nodes from the rest of the network, whereas a delay attack aims simply to slow the speed of information flowing to and from a given set of nodes.
How the attacker achieves this is somewhat technical, but the strategy essentially works by the entity positioning itself in the path of the traffic and intercepting transactions, thereby jamming or slowing the ‘route’ through which the data must pass.
In both cases, the disconnect can be exploited to carry out double-spending and/or cause damage to a miner through loss of revenues (by making it impossible to validate or initiate transactions).
The Bitcoin network is vulnerable to routing attacks because although it is technically decentralized, mining power is concentrated (with around 68% hosted on 10 networks) as is network traffic (3 transit networks account for 60% of total connections). This means that a malign actor has fewer points of failure that they must exploit.
Counter-strategies to prevent routing attacks involve making nodes ‘routing-aware’ so as to maximize the diversity of the routes used to propagate information. Additional measures include early-warning alerts that indicate when an attacker is beginning to attempt to launch a routing attack, causing nodes to temporarily seek ‘extra-random’ selections.
Other measures include the establishment of ‘relay networks’ such as SABRE to protect against routing attacks on specific networks. The purpose of these networks is to provide a designated ‘safe passage’ (like an armed convoy, to continue the military analogy) along which nodes can exchange blocks, even if the broader network is compromised, by essentially circumventing the partition created by the attackers.
The name ‘Eclipse’ comes from the purpose of the attack, which is to block out or ‘eclipse’ the rest of the network from the view of a target node, leaving it vulnerable to manipulation.
There are three steps to the strategy. First, the attacker must create or take control of a number of nodes in the proximity of the victim node. Next, it forces the victim node to restart (for example by means of standard DDoS attack). The final step is to induce the victim to re-establish its connection to the network exclusively using the strategically-placed, attacker-controlled nodes.
Depending on the number of confirmations required to confirm the fraudulent transaction the attacker wants to carry out, it may be necessary to control both the victim and the miners or validators who are needed to confirm the transaction, but the strategy — isolate and manipulate — is the same in either case.
A good way of thinking about the Eclipse is as the younger brother of the Sybil attack, which succeeds by flooding an entire network with fake identities, rather than creating a crowd of fake nodes around a specific target. An Eclipse is indeed similar to a consensus-based attack, because from the perpsective of the victim node, it is as though the entire network has been taken over.
The Eclipse attack was originally proposed as a potential vulnerability in the Bitcoin network in 2015, and researchers from Boston University successfully initiated an eclipse attack on the Ethereum network in 2018, using only one or two machines.
A simple way to avoid falling victim to Eclipse attacks is to connect only with ‘whitelisted’ nodes, although this decreases the efficiency of the network as it introduces an unwelcome layer of compliance to a supposedly dynamic and permissionless paradigm. So far, suggested tweaks have focused on increasing the cost to the attacker, for example by increasing the number of required connections per node and confirmations per transaction.
Transaction Malleability could be seen as the “Three-Card Monte” of node-level scams. Unlike other attacks, it is straightforward in terms of its aim. The mirror image of a double-spending attack, it forces a victim to pay for the same transaction twice. You could call it a double-take.
First, a victim makes a legitimate transaction by sending funds to the attacker. The attacker creates a copy of the transaction, and then alters the transaction ID to make it appear that the transaction has failed. He then broadcasts the fake transaction and the network before the original transaction can be broadcast.
When the network confirms the ‘error’, the sender receives the message that the transaction has failed, whereupon they send the funds for a second time. The attacker then releases the original transaction and the new transaction, which are both confirmed by the network, meaning that the funds are debited twice.
One of the first and most high-profile cases occurred in 2014 at Mt. Gox, the largest Bitcoin exchange in the world at the time. The firm lost hundreds of millions of dollars resending Bitcoin withdrawals to attackers who were able to create the illusion they had not received the original transactions. Mt. Gox was forced to file for bankruptcy shortly afterwards, demonstrating the seriousness of the exploit.
Solutions exist and have been implemented on various chains, including Bitcoin and Ethereum, to solve the issue of malleability (long story short: it turns out that the answer is to make transaction IDs less malleable — whoda thunk?).
The issue is not entirely put to bed, however, and still rumbles on in other chains. This is due to the innate controversy involves in making fundamental changes to the protocol, and the ensuing debate over hard versus soft forking. The Segwit malleability fix, for example, is credited with leading to the split of Bitcoin (BTC) and Bitcoin Cash (BCH).
As the name suggests, a timejacking attack works by manipulating a node’s ‘perception of time’, steadily drawing it away from safety of the herd and leaving it open to attack. To date, timejacking remains only a theoretical vulnerability, as no reported cases exist. But for blockchain, the night is young.
The strategy rests on the fact that it is important for two computing systems to have a common understanding of the time when they interact. If too many versions of time attempt exist, the effect is similar to time jumping backwards and forwards, which can lead to chaos and network paralysis. To avoid this, nodes in a blockchain network are constantly “looking at each other’s watches”, and resetting their internal counters when they stray too far from the median.
By this stage in the article, it should be clear how an attacker would exploit this. By surrounding the victim with fake nodes (Eclipse) it is possible to trick the node into resetting its internal time counter with respect to a false median created. Eventually, the victim becomes isolated from the protection of the wider network, and comes to inhabit an alternative blockchain of the attacker’s design.
Various defenses against timejacking have been proposed, although none have been tested ‘in the wild’. A logical counter-measure is to restrict the acceptable delta from the median (e.g. from 70 minutes to 30 minutes) before a reset is required, thus limiting the potential distance a compromised node can stray from the broader network. Until timejacking becomes a proven risk, and battle-tested measures are deployed, the ideal solution is likely to remain unclear.
The common complaint of the IT professional is that no one praises you when you do your job well, but everyone notices when you don’t. This is the result of operating a function that exists primarily in the back-end, and requires technical knowledge to understand.
In the realm of blockchain security, the Network Attacks we have described in this article inhabit a sort of hinterland between the headline-grabbing consensus-based exploits (e.g. 51% attacks) and the more easily comprehensible wallet-based hacks (SIM swaps), which journalists can explain and consumers can more easily visualize.
This is, if anything, a reason to consciously direct attention to Network vulnerabilities as a class of risks. As we have seen, even in the case of a seemingly ‘simple’ attack such as Transaction Malleability, a node-level “street hustle” carried out at scale can bring an entire company to its knees.
As we began by observing, a blockchain network will ultimately and always rely on the functioning of the nodes on which it is based, and hence the integrity of these nodes will always be both vital and vulnerable. We should expect the list of network attacks to become longer and less theoretical as the ‘science’ of blockchain-based cyber attacks advances with the wider adoption of blockchain technology.
For an overview of blockchain threats see Security Threats to Blockchain Networks — A Holistic Overview
Originally published at https://crypto.security on June 18, 2022.