https://github.com/demining/blockchain-attack-vectors
Blockchain Attack Vectors & Vulnerabilities to Smart Contracts
https://github.com/demining/blockchain-attack-vectors
attack attacker attacks bitcoin blockchain blockchain-technology cryptocurrency ethereum exploit exploiting exploiting-vulnerabilities hack hacking smart-contracts vulnerabilities vulnerability vulnerability-scanners
Last synced: 11 months ago
JSON representation
Blockchain Attack Vectors & Vulnerabilities to Smart Contracts
- Host: GitHub
- URL: https://github.com/demining/blockchain-attack-vectors
- Owner: demining
- Created: 2022-12-19T16:54:34.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2022-12-27T09:47:33.000Z (over 3 years ago)
- Last Synced: 2025-04-02T06:35:52.614Z (about 1 year ago)
- Topics: attack, attacker, attacks, bitcoin, blockchain, blockchain-technology, cryptocurrency, ethereum, exploit, exploiting, exploiting-vulnerabilities, hack, hacking, smart-contracts, vulnerabilities, vulnerability, vulnerability-scanners
- Language: HTML
- Homepage: https://cryptodeeptech.ru/blockchain-attack-vectors
- Size: 11.9 MB
- Stars: 26
- Watchers: 2
- Forks: 10
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
In this article, we will talk about all known attacks on the blockchain, as well as smart contract vulnerabilities. Blockchain isn’t really as secure as we tend to think. Though security is integrated throughout all blockchain technology, even the strongest blockchains come under attack by modern cybercriminals.
Blockchains can resist traditional cyber attacks quite well, but cybercriminals are coming up with new approaches specifically for hacking blockchain technology. In this article, we describe the main attack vectors against blockchain technology and take a look at the most significant blockchain attacks to date.
Cybercriminals have already managed to misuse blockchains to perform malicious actions. Ransomware attacks like WannaCry and Petya wouldn’t have been so massive if attackers hadn’t received their rewards in cryptocurrencies. Now, it looks like hackers consider exploiting blockchain security vulnerabilities as their main source of revenue.
In March 2019, white hat hackers found 43 bugs in various blockchain and cryptocurrency platforms in just 30 days. They even found vulnerabilities in such famous platforms as Coinbase, EOS, and Tezos.
However, weak spots are often challenging to detect, since they can be hidden in unobvious places. For instance, the Parity multisig wallet was hacked by breaking a library that had a withdraw function in it. The attacker managed to initialize the library itself as a wallet and claim owner rights to it. As a result, 573 wallets were affected, $30 million worth of crypto was stolen, and another $180 million rescued by a white hat hacker group was later returned to the rightful owners.
----
* Tutorial: https://youtu.be/7pqVNbcGzls
* Tutorial: https://cryptodeeptech.ru/blockchain-attack-vectors
----
By attacking such huge networks as Bitcoin and Ethereum, cybercriminals show that they’re clever enough to disprove the myth of blockchain security. Let’s consider the five most common blockchain attack vectors:
Blockchain Network Attacks
A blockchain network includes nodes that create and run transactions and provide other services. For instance, the Bitcoin network is formed by nodes that send and receive transactions and miners that add approved transactions to blocks. Cybercriminals look for network vulnerabilities and exploit them with the following types of attacks.
Distributed Denial of Service
Distributed denial of service (DDoS) attacks are hard to execute on a blockchain network, but they’re possible.
When attacking a blockchain network using DDoS, hackers intend to bring down a server by consuming all its processing resources with numerous requests. DDoS attackers aim to disconnect a network’s mining pools, e-wallets, crypto exchanges, and other financial services. A blockchain can also be hacked with DDoS at its application layer using DDoS botnets.
In 2017, Bitfinex suffered from a massive DDoS attack. It was especially inconvenient for the IOTA Foundation, which had launched their IOTA token on the platform the day before Bitfinex informed users about the attack. Three years later, in February 2020, Bitfinex experienced another DDoS attack just a day after the OKEx cryptocurrency exchange noticed a similar attack.
Transaction Malleability Attacks
A transaction malleability attack is intended to trick the victim into paying twice. In the Bitcoin network, every transaction has a hash that’s a transaction ID. If attackers manage to alter a transaction’s ID, they can try to broadcast the transaction with a changed hash to the network and have it confirmed before the original transaction. If this succeeds, the sender will believe the initial transaction has failed, while the funds will still be withdrawn from the sender’s account. And if the sender repeats the transaction, the same amount will be debited twice. This hack is successful once the two transactions are confirmed by miners.
Mt. Gox, a Bitcoin exchange, went bankrupt as the result of a malleability attack in 2014. However, Bitcoin seems to have solved this issue by introducing the Segregated Witness (SegWit) process, which separates signature data from Bitcoin transactions and replaces it with a non-malleable hash commitment to each signature.
Timejacking Attack
Timejacking exploits a theoretical vulnerability in Bitcoin timestamp handling. During a timejacking attack, a hacker alters the network time counter of the node and forces the node to accept an alternative blockchain. This can be achieved when a malicious user adds multiple fake peers to the network with inaccurate timestamps. However, a timejacking attack can be prevented by restricting acceptance time ranges or using the node’s system time.
The timejacking attack is also an extension of the Sybil attack. Each node maintains a time counter which is based on the median time of its peers, and if the median time differs from the system time by a certain value, then the node reverts to the system time. An attacker can flood the network with nodes reporting inaccurate timestamps, which can cause the network to slow down or speed up, leading to a desynchronization.
Routing Attacks on Cryptocurrencies
A routing attack can impact both individual nodes and the whole network. The idea of this hack is to tamper with transactions before pushing them to peers. It’s nearly impossible for other nodes to detect this tampering, as the hacker divides the network into partitions that are unable to communicate with each other. Routing attacks actually consist of two separate attacks:
- A partition attack, which divides the network nodes into separate groups
- A delay attack, which tampers with propagating messages and sends them to the network
-
Sybil Attacks in Cryptocurrency Mixers
A Sybil attack is arranged by assigning several identifiers to the same node. Blockchain networks have no trusted nodes, and every request is sent to a number of nodes.
Figure 1. Sybil attack
During a Sybil attack, a hacker takes control of multiple nodes in the network. Then the victim is surrounded by fake nodes that close up all their transactions. Finally, the victim becomes open to double-spending attacks. A Sybil attack is quite difficult to detect and prevent, but the following measures can be effective: increasing the cost of creating a new identity, requiring some type of trust for joining the network, or determining user power based on reputation.
A sybil attack is defined by Wikipedia as “a type of attack on a computer network service in which an attacker subverts the service’s reputation system by creating a large number of pseudonymous identities and uses them to gain a disproportionately large influence.” If the network does not keep the count of the nodes, then the attacker can completely isolate the victim node from the network. The sybil attack on blockchain also works similarly, where an attacker tries to flood the network with their controlled nodes so that the victim only connects to the attacker controlled nodes. This can lead to a wide variety of damages where the attacker can prevent genuine blocks from being added to the chain, the attacker can add their own blocks to the chain, or they can cause confusion among the nodes, hampering the general functioning of the blockchain network.
In the above visual representation, the red nodes are controlled by the attacker, and they flood the network, making the victim connect only to a malicious node.
Sybil Attacks on Identity-Augmented Proof-of-Stake
IdAPoS is an identity-based consensus protocol for decentralised Blockchain networks that implements a trustless reputation system by extending Proof-of-Stake to facilitate leader selection in non-economic contexts. Like any protocol operating in a public/permissionless setting, it is vulnerable to Sybil attacks in which byzantine actors interfere with peer sampling by presenting artificially large numbers of identities. This paper demonstrates what influence these attacks have on the stability of member selection of a Blockchain system using the IdAPoS protocol and investigates how attacks can be mitigated. As a novel protocol, its vulnerability to this type of attack has not previously been researched. The research question is approached via an agent-based model of an IdAPoS system in which both honest and malicious actors are represented as agents. Simulations are run on some reasonable configurations of an IdAPoS system that employ different attack mitigation strategies. The results show that a super strategy that combines multiple individual mitigation strategies is more effective for containing Sybil attacks than the unmitigated protocol and any other individual strategies proposed. In the simulation this strategy extended the time until a system was taken over by a malicious entity approximately by a factor of 5. These positive initial results indicate that further research into the practical viability of the protocol is warranted
Eclipse Attacks on Bitcoin
An eclipse attack requires a hacker to control a large number of IP addresses or to have a distributed botnet. Then the attacker overwrites the addresses in the “tried” table of the victim node and waits until the victim node is restarted. After restarting, all outgoing connections of the victim node will be redirected to the IP addresses controlled by the attacker. This makes the victim unable to obtain transactions they’re interested in. Researchers from Boston University initiated an eclipse attack on the Ethereum network and managed to do it using just one or two machines.
Eclipse attack arises in the blockchains, where the architecture partitions workloads and assigns tasks among the peers. As an example, if a chain has a node that has only eight outgoing connections and can support at most 128 threads at any given moment, each node has view access to only the nodes that are connected to it. The view of the chain for the victim node can be changed if an attacker attacks a specific node and gains control of the eight nodes connected to it. This can lead to a wide variety of damages that include double spending of the coins by tricking a victim that a particular transaction has not occurred, and also the attacks against the second layer protocols. The attacker can make the victim believe that a payment channel is open when it is closed, tricking the victim to initiate a transaction. The following diagram demonstrates a node under Eclipse attack.
In the above visual representation, the red nodes are controlled by the attacker, and they can change the copy of the chain of the victim node by making it connect to attacker controlled nodes.
Eclipse Attacks on Ethereum
In this technical report, we present three vulnerabilities affecting the Ethereum blockchain network and client. First, we outline an eclipse attack that allows an adversary to partition the peer-to-peer network without monopolizing the connections of the victim. This is attack is possible by exploiting the block propagation design of Ethereum. Second, we present an exploit to force a node to accept a longer chain with lower total difficulty than the main chain. Finally, we outline a bug in Ethereum’s difficulty calculation. We provide countermeasure proposals for each reported vulnerability.
Long-Range Attacks in Proof-of-Stake Systems
Long range attacks target networks that use the proof of stake (PoS) consensus algorithm, in which users can mine or validate block transactions according to how many coins they hold.
These attacks can be categorized into three types:
-
Simple — A naive implementation of the proof of stake protocol, when nodes don’t check block timestamps
-
Posterior corruption — An attempt to mint more blocks than the main chain in a given time frame
-
Stake bleeding — Copying a transaction from the honestly maintained blockchain to a private blockchain maintained by the attacker
-
When conducting a long-range attack, a hacker uses a purchased or stolen private key of a sizable token balance that has already been used for validating in the past. Then, the hacker can generate an alternative history of the blockchain and increase rewards based on PoS validation.
2. User Wallet Attacks
Actually, blockchains and cybersecurity go together like salt and pepper until people interact with them. It may sound surprising, but blockchain users pose the greatest security threat. People know about the use of blockchain in cybersecurity, and tend to overestimate the security of the blockchain and overlook its weaknesses. User wallet credentials are the main target for cybercriminals.
To obtain wallet credentials, hackers try to use both traditional methods like phishing and dictionary attacks and new sophisticated methods like finding weaknesses in cryptographic algorithms. Here’s an overview of the most common ways of attacking user wallets.
Phishing Attacks
In 2018, there was an attack on IOTA wallets initiated with iotaseed.io (now offline), a fake online seed generator. Hackers conducted a phishing campaign with this service and collected logs with secret seeds. As a result, in January 2018, hackers successfully stole more than $4 million worth of IOTA from victims’ wallets.
Dictionary Attacks
During these attacks, a hacker attempts to break a victim’s cryptographic hash and salt by trying hash values of common passwords like password1. By translating clear text passwords to cryptographic hashes, attackers can find wallet credentials.
Vulnerable Signatures
Blockchain networks use various cryptographic algorithms to create user signatures, but they may also have vulnerabilities. For example, Bitcoin uses the ECDSA cryptographic algorithm to automatically generate unique private keys. However, it appears that ECDSA has insufficient entropy, which can result in the same random value in more than one signature. IOTA also faced cryptographic problems with its old Curl hash function.
Flawed Key Generation
Exploiting vulnerabilities in key generation, the hacker known as Johoe got access to private keys provided by Blockchain.info in December 2014. The attack happened as the result of a mistake that appeared during a code update that resulted in poor randomness of inputs for generating public user keys. Though this vulnerability was quickly mitigated, the flaw is still possible with the ECDSA algorithm.
Lattice Attack
If the signing nonce NONCES is ever disclosed, the private key can be immediately recovered , which breaks our entire signature scheme .
Also, if two nonces ever repeat, no matter what the messages are, an attacker can easily detect this and immediately recover the secret key , again breaking our whole scheme.
In the Bitcoin blockchain, we found a certain transaction:
transaction: 08d917f0fee48b0d765006fa52d62dd3d704563200f2817046973e3bf6d11f1f
for Bitcoin Addresses: 15N1KY5ohztgCXtEe13BbGRk85x2FPgW8E
and we managed to multiply the fake signatures and apply the lattice
where using the Python script algorithmLLL.py with the installation of packages in GOOGLE COLAB
INSTALL >> SAGE + ECDSA + BITCOIN + algorithm LLL
We managed to get Private Key to Bitcoin Wallet from one weak transaction in ECDSA.
Installation
Run Bash script: lattice.sh
Result in HEX format Private key found!
File: ONESIGN.txt (ECDSA Signature R, S, Z Value)
We propagated fake signatures for the Python script algorithmLLL.py
File: PRIVATEKEY.txt
File: ADDRESS.txt
Let’s open bitaddress and check:
Private key found!
https://www.blockchain.com/btc/address/15N1KY5ohztgCXtEe13BbGRk85x2FPgW8E
0.001 BTC
ADDR: 15N1KY5ohztgCXtEe13BbGRk85x2FPgW8E
WIF: 5JCAmNLXeSwi2SCgNH7wRL5qSQhPa7sZvj8eDwxisY5hJm8Uh92
HEX: 31AFD65CAD430D276E3360B1C762808D1D051154724B6FC15ED978FA9D06B1C1
RangeNonce
«RangeNonce» is a script to find the range of the secret key
Let’s choose the version for the distribution kit GNU/Linux . Google Colab provides UBUNTU 18.04
Upload all files to Google Colab
RangeNonce + Google Colab
Let’s allow permissions for the script and run the script «RangeNonce»
Teams:
chmod +x RangeNonce
./RangeNonce
cat Result.txt
Everything will be saved to a file: Result.txt
This is the partial disclosure of bytes of information the value of “K” (NONCES)
So our secret key is in the range :
K = 070239c013e8f40c8c2a0e608ae15a6b00000000000000000000000000000000
K = 070239c013e8f40c8c2a0e608ae15a6bffffffffffffffffffffffffffffffff
Pay attention to the initial 32 digits and letters HEX of the format, the value of the signature Z matches the range of the secret key , that is, the value "K" (NONCES)
This is a very serious ECDSA signature error
Frey-Rück Attack
With a critical vulnerability in the Bitcoin blockchain transaction, we can solve the rather difficult discrete logarithm problem to extract the ECDSA secret key"K" (NONCE) from the vulnerable signature in order to ultimately restore the Bitcoin Wallet, since knowing the secret key we can get the private key.
To do this, there are several algorithms from the list of popular attacks on Bitcoin , one of which is “Frey-Rück Attack on Bitcoin” .
Rowhammer Attack
The biggest cryptographic strength of the Bitcoin cryptocurrency is a computational method in discrete mathematics that takes the problem of factorization of large integers and the problem of hidden numbers (HNP)in the Bitcoin signature transaction as a basis ECDSA.
Rowhammer Attack on Bitcoin, allows us to efficiently find all zeros for normalized polynomials modulo a certain value, and we adapt this method to a signature algorithm, ECDSAmore precisely, to critically vulnerable transactions in the Bitcoin blockchain.
We will apply multiplication by different powers of the same element of the finite field, which, oddly enough, can coincide and give us a certain function over the finite field, which can be specified using the Lagrange interpolation polynomial .
WhiteBox Attack
Differential fault analysis (DFA)was briefly described in the literature in 1996 when an Israeli cryptographer and cryptanalyst Eli Biham and an Israeli scientist Adi Shamir showed that they could use error injection to extract the secret key and recover the private key using various signature and verification algorithms.
We implement the “WhiteBox Attack on Bitcoin” with the differential bugs described in this research paper. The classic DFAthat we described in the previous article is called F(). Some of these attacks also require two signature pairs ECDSA.
Attacks on Cold Wallets
Hardware wallets, or cold wallets, can also be hacked. For instance, researchers initiated an Evil Maid attack by exploiting bugs in the Nano S Ledger wallet. As a result of this hack, researchers obtained the private keys as well as the PINs, recovery seeds, and passphrases of victims.
One of the latest cold wallet attacks happened in 2019, when the UPbit cryptocurrency exchange was transfering funds to a cold wallet. This is a common way to freeze crypto when you’re expecting a cyberattack. The hackers managed to steal 342,000 ETH, apparently because they knew the timing of the transaction.
Attacks on Hot Wallets
Hot wallets are internet-connected apps for storing private cryptographic keys. Though owners of cryptocurrency exchanges claim they keep their user data in wallets disconnected from the web, a $500 million attack on Coincheck in 2018 proved this isn’t always true.
In June 2019, an attack on GateHub resulted in unauthorized access to dozens of native XRP wallets and the theft of crypto assets. Singapore-based crypto exchange Bitrue also experienced a hot wallet attack at almost the same time due to a system vulnerability. As a result, hackers managed to steal funds worth over $4.5 million in XRP and $237,500 in ADA.
Smart Contract Attacks
We’ve already accumulated rich experience in analyzing and avoiding vulnerabilities in smart contracts based on the Ethereum, EOS, and NEO platforms. The main blockchain security issues associated with smart contracts relate to bugs in source code, a network’s virtual machine, the runtime environment for smart contracts, and the blockchain itself. Let’s look at each of these attack vectors.
PDF: Smart Contract Vulnerability Detection Technique: A Survey
The Smart Contract examples used are issues that have occurred on the Ethereum blockchain. They are applicable to any platform that uses the Ethereum Virtual Machine and the concepts can be applied to any form of smart contracts. The topic will also cover known best practices to mitigate these issues.
The Topology attacks explore possible attack vectors on the Bitcoin network, and subsequently any networks that rely on a controlled amount of peer-peer communication for validation. The issues explored will be on two levels: Vulnerable Smart Contract codes and Topology attacks.
Jorden Seet’s interest in the Cybersecurity world started in 2013 when he competed in his first CTF after a 2-day penetration testing bootcamp. Ever since, he has grown a passion in cybersecurity and explored many facets of it, from Cryptography to Social Engineering.
Currently, he is working on a National Research Foundation – Tel Aviv University (NRF-TAU) granted project on using Network Topology Analytics for Cyber Attack Deterrence in SMU. He was previously with the Cyber Security Agency of Singapore’s Penetration Testing department as an intern and is currently working with BlockConnectors on Smart Contract Audit and Blockchain development.
In his spare time, he works on Smart Contract Hacking as well as explore potential blockchain attack vectors. He firmly believes that decentralization is a paradigm that could have real potential in revolutionizing the security industry, such as in DDoS prevention, Data integrity and IoT security.
Vulnerabilities in Contract Source Code
If a smart contract has vulnerabilities in its source code, it poses a risk to parties that sign the contract. For instance, bugs discovered in an Ethereum contract cost its owners $80 million in 2016. One of the common vulnerabilities in Solidity opens up a possibility to delegate control to untrusted functions from other smart contracts, known as a reentrancy attack. During this attack, contract A calls a function from contract B that has an undefined behavior. In turn, contract B can call a function from contract A and use it for malicious purposes.
Vulnerabilities in Virtual Machines
Vulnerabilities in virtual machines
The Ethereum Virtual Machine (EVM) is a distributed stack-based computer where all smart contracts of Ethereum-based blockchains are executed. The most common vulnerabilities of the EVM are the following:
- Immutable defects — Blockchain blocks are immutable by nature, which means that once a smart contract is created, it can’t be changed. But if a smart contract contains any bugs in its code, they also are impossible to fix. There’s a risk that cybercriminals can discover and exploit code vulnerabilities to steal Ether or create a new fork, as happened with the DAO attack.
- Cryptocurrency lost in transfer — This is possible if Ether is transferred to an orphaned address that doesn’t have any owner or contract.
- Bugs in access control — There’s a missed modifier bug in Ethereum smart contracts that allows a hacker to get access to sensitive functionality in a contract.
-
Short address attack — This is possible because the EVM can accept incorrectly padded arguments. Hackers can exploit this vulnerability by sending specifically crafted addresses to potential victims. For instance, during a successful attack on the Coindash ICO in 2017, a modification to the Coindash Ethereum address made victims send their Ether to the hacker’s address. -
Also, hackers can compromise smart contracts by applying other methods that are typical for compromising blockchain technology, including DDoS, eclipse, and various low-level attacks.
However, younger blockchains such as Cardano and Zilliqa use different virtual machines: IELE, KEVM, and others. These new blockchains claim to guarantee smart contract security within their protocols.
Transaction Verification Mechanism Attacks
Unlike financial institutions, blockchains confirm transactions only after all nodes in the network are in agreement. Until a block with a transaction is verified, the transaction is classified as unverified. However, verification takes a certain amount of time, which creates a perfect vector for cyberattacks.
Double-spending is a common blockchain attack exploiting the transaction verification mechanism. All transactions on a blockchain need to be verified by users in order to be recognized as valid, which takes time. Attackers can use this delay to their advantage and trick the system into using the same coins or tokens in more than one transaction.
Figure 2. A double-spending attack
Here are the most common types of attacks based on exploiting the intermediate time between a transaction’s initiation and confirmation.
Finney Attacks
A Finney attack is possible when one transaction is premined into a block and an identical transaction is created before that premined block is released to the network, thereby invalidating the second identical transaction.
The Finney attack can be termed as an extension of the selfish mining attack. The attacker mines a block stealthily and sends the unconfirmed transaction to the other node, possibly to a merchant node. If the merchant node accepts the transaction, then the attacker can further add a new block to the chain in a small-time frame, reversing that transaction and inducing a double spending attack. The attack window in the case of a Finney attack is considerably small, but this can cause a lot of damage if the value of the transaction is large enough.
Race Attacks
A race attack is executed when an attacker creates two conflicting transactions. The first transaction is sent to the victim, who accepts the payment (and sends a product, for instance) without waiting for confirmation of the transaction. At the same time, a conflicting transaction returning the same amount of cryptocurrency to the attacker is broadcast to the network, eventually making the first transaction invalid.
In a race attack, the attacker does not pre-mine the transaction but simply broadcasts two different transactions, one of them to the merchant and one of them to the network. If the attacker is successful in giving the merchant node the illusion that the transaction received by them is the first one, then they accept it, and the attacker can broadcast a completely different transaction to the entire network.
Besides these core blockchain level attacks, there are a number of other attacks that can happen at the application implementation level. One of the most infamous of them was the DAO attack that happened in June 2016, leading to a theft of about $70 million. The attacker contributed to the crowdfunding campaign of a company and requested a withdrawal. However, a recursive function was implemented for the withdrawal that didn’t check the settlement status of the current transaction. To recover the money, the Ethereum chain went into a hard fork, with the old chain continuing on as Ethereum Classic. This severely damaged the reputation of the chain, and the autonomy of the chain also came into question.
Some general measures to prevent these attacks from happening:
- It should be ensured that there are no logical inconsistencies in the chain code and consensus algorithm.
- The peers should be selected with sufficient complexity and caution, and the transactions should be reviewed regularly.
- In case any suspicious activity is detected, the network should be vigilant enough to isolate the bad actor node immediately.
- A proper review process should be deployed for the network for each new node when it joins the network.
- Rate limiting algorithms should be present at all the relevant processes to limit the damage and prevent attacks as and when they happen.
- 2FA should be present at all the concerned authentication points, and it should be ensured that all the authentication level bugs should be fixed at the application level itself to the extent possible
- Most of the time, the approach of blacklisting and whitelisting does not work due to scalability issues. So, a better approach should be to make the attacks costly enough to be performed and increase the complexity of the system to be resilient enough and make successful exploitation extremely difficult.
Multiple other bugs and vulnerabilities exist in different kinds of the blockchain networks, the most common and concerning of them being at the smart contract level, but they are a topic for another time.
Vector76 Attacks
Vector76 is a combination of two previous attacks. In this case, a malicious miner creates two nodes, one of which is connected only to the exchange node and the other of which is connected to well-connected peers in the blockchain network. After that, the miner creates two transactions, one high-value and one low-value. Then, the attacker premines and withholds a block with a high-value transaction from an exchange service. After a block announcement, the attacker quickly sends the premined block directly to the exchange service. It along with some miners will consider the premined block as the main chain and confirm this transaction. Thus, this attack exploits the fact that one part of the network sees the transaction the attacker has included into a block while the other part of the network doesn’t see this transaction.
After the exchange service confirms the high-value transaction, the attacker sends a low-value transaction to the main network, which finally rejects the high-value transaction. As a result, the attacker’s account is credited the amount of the high-value transaction. Though there’s a high chance for success with this type of attack, it’s not common because it requires a hosted e-wallet that accepts the payment after one confirmation and a node with an incoming transaction.
Alternative History Attacks
An alternative history attack — also called a blockchain reorganization attack — may happen even in the case of multiple confirmations but requires a huge amount of computing power from the hacker. In this case, a malicious user sends a transaction to a recipient and at the same time mines an alternative fork with another transaction that returns the same coins. Even if the recipient considers the transaction valid after n confirmations and sends a product, for instance, the recipient may lose money if the attacker releases a longer chain and gets the coins back.
One of the latest blockchain reorganization attacks happened to Ethereum Classic in August 2020 when a miner used old software and lost access to internet access for a while when mining. A reorganization happened when two versions of the blockchain competed for validity from nodes in the network and resulted in about a 3000-block insertion.
51% or Majority Attacks
A majority attack is possible when a hacker gets control of 51% of the network hash rate and creates an alternative fork that finally takes precedence over existing forks. This attack was initially the only known blockchain vulnerability and seemed unrealistic in the near past. However, at least five cryptocurrencies — Verge, ZenCash, Monacoin, Bitcoin Gold, and Litecoin Cash — have already suffered from 51% attacks. In each of these cases, cybercriminals collected enough hashing power to compromise the network and pocket millions of dollars.
The recent 51% attack on Ethereum Classic (ETC) that happened in August 2020 resulted in approximately $5.6 million worth of the ETC cryptocurrency being double-spent. Apparently, the hacker had good knowledge of the ETC protocol and managed to mine 4,280 blocks over four days until the platform noticed an attack. Just five days after the incident, ETC suffered from a second 51% attack, in which a miner conducted a 4,000-block network reorganization.
Unfortunately, all small cryptocurrencies are still at risk of majority attacks. Since these cryptocurrencies attract fewer miners, attackers can just rent computing power to gain a majority share of the network. The developers of Crypto51 have tried to draw attention to the potential risks of hacking smaller cryptocurrencies. Their website shows the expected costs of a 51% attack on various blockchains.
Possible measures for preventing double-spending attacks include monitoring received transactions during a listening period, forwarding double-spending attempts, inserting other nodes to observe transactions, and rejecting direct incoming connections.
Moreover, there’s an innovative technology called the lightning network that’s designed to solve the problem of exploiting weaknesses in the transaction verification mechanism. This network allows users to instantly verify transactions through a network of bidirectional payment channels without delegating custody of funds. However, it’s still susceptible to DDoS attacks, one of which already happened in March 2018.
51% attack happens when a particular miner or a set of miners gain more than 50% of the processing power of the entire blockchain network, which helps them gain a majority in regard to the consensus algorithm. This attack vector is primarily related to the Proof of Work algorithm, but it can be extended as a test case to other consensus algorithms also, where there is a risk of a single party gaining enough influence in the network to unduly modify the state of the chain. This can lead to multiple damages including rewriting the chain data, adding new blocks, and double spending. The following diagram shows how this attack happens.
In the above visual representation, the red nodes are controlled by the attacker, and they can change the copy of the chain by adding new blocks post gaining majority consensus.
Some of the major chains that have suffered a 51% attack are the Bitcoin Gold Blockchain (in May 2018, 388,000 BTG worth around $18 million were stolen from multiple exchanges), Bitcoin Satoshi’s Vision (in August 2021, they suffered a 51% attack after which the coin suffered a 5% loss in value) and the Ethereum Classic blockchain. Rented Hash Power can also lead to 51% attacks. In this method, the attackers can rent computing power on servers to calculate hashes faster than other participants and gain consensus. Mining pools are also an interesting party in this, since they too can sometimes exceed the consensus requirements. In July 2014, the mining pool ghash.io gained more than 50% processing power for a brief period, after which it committed to reducing its power voluntarily.
The culprits behind the recent 51% attacks on Ethereum Classic used rented mining hash power to carry off their heists, exploiting a vulnerability common to cryptocurrencies that rely on “proof of work” as their underlying technology.
Rented mining hash power is at the center of all three attacks on ETC last month, which resulted in millions of dollars in losses and delivered a significant blow to the reputation of PoW protocols previously believed to be immutable and “unhackable.”
“It’s actually a huge vulnerability in the system,” said Terry Culver, CEO of ETC Labs, an incubator of projects on Ethereum Classic, in an interview with Forkast.News.
“Three attacks in one month will tell you that security is an issue on Ethereum Classic. And we believe and know that other blockchains get attacked more regularly, maybe with less visibility,” Culver said. “It’s a universal problem.”
The cryptocurrency space has been trying to weed out criminals and tighten up security, including the implementation of “know your customer” and anti-money laundering (KYC/AML) procedures, increased regulations from governments, and enhanced security systems to stave off hacking.
But despite these efforts, malicious actors continue to exploit a core feature of many blockchain systems — decentralization and the requirement that there must be a 51% consensus of the protocol’s nodes to control the network.
“The [cryptocurrency] system is maturing, but the hash rental market is actually growing,” Culver said. “Think of it like, you turn the light on, and where do the mice go? [Malicious actors have] left the exchanges for the most part, and they’ve moved into the hash rental market.”
Proponents of PoW systems would say that the 51% requirement needed to gain consensus would make it very hard to hack large blockchain protocols like Bitcoin and Ethereum. But there is still a theoretical possibility if someone or a group manages to gain 51% control over those networks. The risks of a 51% attack increases for smaller cryptocurrencies that don’t have as many nodes, as it would be relatively easier to take over the network of a smaller network while still turning a profit.
For example, it would take over US$513,000 to perform a 51% attack (at the time of this publication) for one hour on Bitcoin, but only about US$3,800 for a similar attack on Ethereum Classic, which is why the smaller network may be much easier and more profitable for malicious actors to attack.
“The hash rental market is like under a rock somewhere, it’s totally anonymous,” Culver said. “They’re basically money laundering operations. So you could take your BTC from ill-gotten gains, rent hash power, and get out freshly-minted tokens with no provenance.”
The cost of launching a 51% attack on various top cryptocurrencies through NiceHash. Image: Crypto51
What does renting hashpower do?
How did they do it? The malicious actors behind the first two attacks on ETC in August were able to achieve 51% dominance over the network by renting hash power from NiceHash provider daggerhashimoto, based on an analysis by Bitquery, a data intelligence firm.
Slovenia-based NiceHash is an online platform where customers can rent hashing power from sellers providing the computing power to mine cryptocurrencies.
By using this rented hash power, the attackers behind the first and second attacks on Ethereum Classic were able to “double spend” over US$7 million by overwriting entries in the blockchain, reversing or even changing the destination of transactions. In other words, the attackers had almost complete control over the network and were able to route money as they pleased.
NiceHash has previously been embroiled in controversy. In 2019, its former chief technology officer and co-founder Matjaz Skorjanec was arrested in Germany over U.S. charges of being involved in a hacking group that organized the theft of millions of dollars.
NiceHash itself was hacked in 2017, resulting in the loss of an estimated US$78 million in bitcoin.
The August hacks were not the first time Ethereum Classic suffered from such breaches, as a similar 51% attack occurred against ETC in January 2019. Hackers have also launched successful 51% attacks on a number of other smaller cryptocurrencies, including Bitcoin Gold, Verge and Monacoin in 2018.
“Computers are getting better, it’s going to keep getting easier and easier to get control of the computer power necessary to do these things,” said Benjamin J. A. Sauter, partner at New York-based international law firm Kobre & Kim, which is representing ETC Labs in investigating and suing the hackers.
Moreover, the concentration of hashing power in China has also been shown to be a risk for cryptocurrencies, as