Attacks on Blockchain

WEB3 is the new buzzword in the town of tech, and blockchain is the core technology that is powering this seismic shift in the sea of internet. Cybersecurity and blockchain most often work in a complementary manner, and both are interdependent. Blockchain-based systems are inherently more secure than traditional systems since they work on a distributed architecture compared to the traditional client-server architecture. However, blockchains come with their own problems in regard to cybersecurity, and they have some unique attack vectors. These attack vectors can originate at the application level and also at the core blockchain level. In this blog piece, we will try to explore some of the key attacks that are possible on the core blockchain designs. These can occur due to design flaws or even some unforeseen circumstances, and hence the relevance and the level of fixes are also dependent on the type of vulnerability.

While most of these attacks may seem theoretical or difficult to exploit, many of them have been successfully exploited in the past and have caused a massive amount of physical damage. Without much ado, let us take a look at some of the key attacks.

Attacks on Blockchain:

51% Attack:

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.

Eclipse Attack:

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.

Sybil Attack:

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.

Timejacking Attack:

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.

Selfish Mining Attack:

This attack occurs when an attacker is able to mine blocks stealthily and create a copy of the chain that is longer than the common chain being worked upon by the other nodes. The attacker mines some blocks and does not broadcast them to the entire network. They keep mining and then publish a private fork once they are sufficiently ahead of the network in terms of the length of the chain. Since the network will shift to the chain that has been most worked upon (aka the longest chain rule), the attacker’s chain becomes the accepted one. With the help of a selfish mining attack, the attacker can publish some transactions on the public network and then reverse them with the help of stealthily mined blocks.

Finney Attack:

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 Attack:

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 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.

About Author

Abhishek Bhati

Jr.Security Analyst