Spoiler alert: YES, Blockchain can be hacked!

Blockchain, by some seen as the answer to every problem, is promoted by many, including myself, as a possible solution for many cyber security issues. The structure of blockchain, combining distributed ledger, consensus on proof of work and proof of stake, encryption by design and linked blocks, provides a lot of layers of protection. This does however not mean that blockchain can’t be hacked at all, it just means that it would take a lot of effort and resources to do so.

What we have to be very careful with is creating false sense of security, something I keep stressing during my workshop Cybersecurity for Road Warriors (and Couch Potatoes) and publications on this topic, by hyping the security aspects way beyond reality. With the hype around blockchain and all blockchain based crypto-currencies, and “better than anything because we use blockchain” projects, we are setting ourselves up for yet another security myth by believing that blockchain is unhackable. This article is a collection of findings and theories during research on the currently known safety issues related to blockchain. Some attack vectors are already out in the field and have lead to high profile thefts and hacks, others are theoretical and listed for the purpose of demonstrating the concept.

 

Wallet attack

Not attacking the blockchain itself but solely attacking the (unsecured) wallets of owners of coins or other equity documented in a blockchain, the wallet attack targets the biggest vulnerability in each security concept. The problem which exists between the keyboard and chair – the users (PEBKAC). After gaining control of the wallet, the hackers initiate a valid transfer on behalf of the owner of the wallet, for example a crypto coin from the account of the wallet owner to the account of the hacker or a middle man, waits for it to be confirmed by the network and releases control over the wallet back to its owner. After taking ownership of the object in the blockchain by the hacker, the power of blockchain basically starts to work against the legitimate owner of the object. Because there now is a new owner of the object and the entire network confirms the ownership.

Even if blockchain platforms would offer registration of the entity initiating the transfer, which most blockchain platforms don’t due to the desire for anonymity, this wouldn’t help the victim since the transaction was initiated from the own wallet, abusing the credentials of the victim. Several platforms seek to mitigate the risks of hijacked wallets by implementing multiple levels of confirmation from the user. Researches have however demonstrated that users have wallets and accounts which match the famous “rockyou.txt” password list… As the old saying goes “while we were busy trying to make it foolproof, humanity responded by sending us bigger fools”!

Crypto advocates will argue that this is not a real hack of the blockchain itself, and to some extend they are right. Just as much as they are right by claiming that blockchain is secure, to some extend that is. Without users and wallets triggering transactions, blockchain is nothing but an energy consuming complicated distributed database. By the nature of distributed infrastructure and data, the users and wallets basically become the edge devices of the blockchain. Once this “edge device” is brought under the control of a hacker, it becomes a contaminated part of the network and can contaminate the network and blockchain itself. Attacking the weakest component to hit the strongest component is and will always be a very popular strategy of hackers. So yes, this is an attack on the blockchain itself!

 

51% attack

The foundation of the 51%-attack is that the attacker(s) get control over at least 51% percent of the hashes and thus becomes the majority in the consensus network of the blockchain. This attack hits blockchain where it was believed to be the strongest: even when a hacker would be able to hack a block in the chain, this hack would be rendered invalid because all other network nodes in the network still have the original valid blocks. This combination of distributed ledger and validation by consensus has long been seen as the unbreakable stronghold of blockchain. Not anymore! By taking control over more than 50% of the network’s hash rate, the hacker basically forms the majority in the network and becomes able to confirm its own transactions and manipulations of new blocks in the chain.

The 51%-attack has long been seen as an unrealistic scenario to attack blockchain networks because it would require too much resources to pull it off. Unrealistic rapidly became realistic and real with the wide spread of new small crypto currencies and exchanges. Remedies are sought in increased redundancy checks and limiting the maximum validation value of a cluster of nodes to well below 50%. The most secure remedy for now appears to be the size of the blockchain network, making it harder for a group of hackers to gain control over more than 50% of the network. Until of course, a malicious group finds a way to combine enough resources to do so…

 

Eclipse attack and Segmentation attack

Unlike most other attempted attacks, the eclipse or segmentation attack targets the peer-to-peer infrastructure of a blockchain network. Theoretically, each node in a blockchain is connected to all the other nodes. In reality, each node is only connected to a limited amount of other nodes, which again are connected to other nodes, and so on. During an eclipse attack, a node is singled out and isolated from the nodes it should be connected with (hence the name eclipse). During the eclipse of the rest of the peer-to-peer network in the blockchain, the hacker can execute for example double spending against the victim.

Just like with the 51% attack, the eclipse attack was long seen as only a theoretical risk because the costs of the attack would be much higher than the possible gains. In reality, the peer-to-peer structure of the blockchain networks makes it way simpler for the hackers than researchers and developers originally expected. Where the size of a large network is an effective mean of protection against the 51% attack, the size of the network multiplies the risk of an eclipse attack by offering more nodes to be isolated and remain undetected until the hack is completed. Remedies are sought in increasing the frequency and triggers of seeding, and increasing the required seeding nodes. Other researchers suggested to add significantly more details on the identities of the nodes. Although this could significantly increase prevention of eclipse attacks in blockchain network, it is very unlikely that this will become an implemented solution for crypto currencies since anonymity is one of the main USP’s of crypto.

 

Sybil attack

First described by John Douceur, the Sybil attack is based on a single entity or collective, for example a network of hackers, having multiple spoofed identities which flood the peer-to-peer network while continuously creating new controlled nodes in the network. By combining the flood of spoofed nodes with an attack vector similar to the eclipse attack, hackers have successfully hijacked large amounts of crypto currencies by establishing a fake 51% consensus majority with spoofed nodes on a segment of the peer-to-peer network.

There are plenty of remedies against Sybil attacks. Bitcoin for example, eliminates the risk of Sybil attacks by a set of requirements for generating blocks and including nodes to the network, and a set of restrictions by design to limit the amount of blocks that can be created by a single node. Other platforms are seeking similar remedies which all come at the cost of lower speed and higher electricity consumption to do the complicated mining on transactions in the blockchain.

So the risk of Sybil attacks is significantly reduced by implementing measures in the same manner as Bitcoin did from the drawing board. Theoretically that is. With its hyped popularity and lucrative incentives for mining, professional miners have started to build huge farms of mining clusters. Researchers suggest that such a farm brought under the control of hackers can actually pull of a successful Sybil attack when all systems in this farm are connected to different nodes outside of the network. Such attack would setup a segment of the network for, for example, a 51% network.

 

Double spending exchange attack

This type of double spending attack targets the exchanges of crypto currency and as such not the blockchain platform itself. By using a combination of attack vectors followed by a 51% attack, for smaller platforms even just a 51% attack, the hackers attack accounts at exchanges by double spending and withdrawing transactions from the account(s) they control. Being in control of the confirmation network or at least a significant segment of the network facing the exchange platform, the hacker is able to withdraw, modify and exclude transactions against the coins they own. The major difference between this specific attack and general 51% attacks (and others), is that this attack is specifically directed against exchange platforms.

Remedies are sought by most exchanges to increase the amount of required confirmations of a transaction and by restricting the total sum for transactions per managed account within a set time frame. Exchanges appear however reluctant to implement such counter measures, since these would lead to significantly longer time required to confirm a transaction, and speed is basically what makes crypto currency holders select the exchanges. Analysis of the last high profile crypto currency attacks makes clear that hackers continue to outrun the counter measures by combining various attack vectors simultaneously, and are still able to abuse the most common issue in security: convenience in most cases outweighs security.

 

Quantum Computing (theoretical for now…)

Blockchain is depending on complex encryption, which at this moment is considered uncrackable. The time and resources required to decrypt the entire transaction and hashes, manipulate a transaction, encrypt it again and at the same time complete the proof of work before the other nodes in the network have confirmed the valid block exceeds by far the available computing power. For now. The question is how long it will take until quantum computing will be able to slaughter blockchain encryption and confirmation within the available timeframe. Not if, just when.

 

Unspent Orphan (theoretical)

This for now still theoretical attack uses generated unspent orphan blocks to flood a segment of the blockchain network with proof of work consensus requests to increase the speed of a 51% percent attack. Although there have not yet been evidence found that hackers apply this method, researchers indicate that hackers are finding ways of easing the required efforts to gain more than 50% control over (a segment of) a network and apply methods that could enable unspent orphans flooding. Which is seen as an indication that an unspent orphan flood could be coming in the near future.

 

Forking Loop (theoretical)

Most blockchain platforms have implemented a solution for the unlikely event that more than one node at the same time reach the same solution for proof of work to be added to the chain. This solution is called forking which would under normal circumstances not be a problem at all since it is even more unlikely that the following block would lead to yet another forking so the chain will start to recover itself from this very unlikely event with the following blocks in the chain.

So it is very unlikely that a forking is needed because it is very unlikely that it will happen. And if it would happen, which no matter how unlikely it might appear, already did on most active high volume blockchain platforms, it is even more unlikely that it would happen again before the chain of blocks can recover itself. Theoretically speaking, that is.

In reality, this scenario becomes more and more realistic with the growing amount of mining farms. Mining blockchains can be very lucrative when enough computing power is involved so professional miners have started to build farms of computers to mine all kinds of coins. Hundreds of computers, sometimes even thousands, working on solving the equations to confirm a transaction. All equipped with exact the same components, all connected to the same network, all using the same operating system, all using the same release of blockchain software, and with a little luck chunking away at the same block in the same blockchain.

At this moment, there are 3 known instances of recurring forks originating from a mining farm, and in one case 3 sequential forks occurred originating from the same farm. In the last case, this obviously occurred by coincidence and was triggered by the signal to drop the ongoing operation and start validation of a new block. As it so happens, the sequence of blocks which caused this event all originated from within the farm itself, enforcing not only that the entire farm worked on a set of blocks and started doing so at the exact same moment, but also enforcing that the farm started working on the set of blocks before any other node outside of the farm but within the network did.

So the very unlikely and the even more unlikely repeating of the very unlikely have already happened, as far as known at this moment without causing any harm to the blockchain itself. What if hackers find a way to trigger and repeat this at a larger scale, rendering a platform invalid for enough time to launch any of the other attack vectors to execute what most crypto advocates and crypto owners fear the most: double spending against coins they own or services they offer.

 

Refunding Attack (theoretical, or at least we think it still is)

This multi-vector attack scenario is directed against eCommerce merchants which accept blockchain based payments which support incomplete, pending or reserved transactions. A group of hackers order duplicate items from the merchant and pay through crypto / blockchain currency. The merchant accepts the order and the hackers confirm the payment in status pending, where the transaction is confirmed when the item is shipped/delivered. Platforms that support pending transactions have also implemented a maximum timeframe in which a transaction is allowed to be pending, after which the transaction either automatically will be completed or voided.

Within that timeframe but prior to shipping by the merchant, the hacker cancels one of the duplicate orders which in most countries is a mandatory privilege of every consumer. This order cancelation is processed by the merchant, and the pending transaction is released, including the coin within that transaction. The hacker on purpose waits with confirming releasing the previous transaction. Because the transaction is now neither confirmed nor released, the hacker owns a ghost transaction which the merchant no longer claims.

The hacker, hands over the coin in that ghost transaction to the next hacker in the group who then uses it to order an item either at the same merchant or even another merchant. The coin in that ghost transaction is released by the original merchant but not by the hacker. This doesn’t stop the next hacker from spending it because the transaction itself never left the pending state and the merchant no longer claims stake on this coin. Hackers can build chains of duplicate orders in relatively short time.

The real hack starts when the hacker is notified of shipment of the item, which should trigger the confirmation of the transaction. The hacker now confirms the other transaction which was released by the merchant and the coin within is already set to pending in another transaction. By using the hash and credentials from the ghost transaction, the network will confirm the transaction as valid and most merchants will only validate the payment itself, not the coin within. By the time the merchant realizes that the coins and transactions are ghosts, the hackers have already received the items and moved on to another victim. Chains of middle man involved in receiving the items will make it impossible for the merchant to track the hackers.

PS: Similar attacks using credit cards and digital wallets have already costed many merchants around the globe a lot of money! We have to assume that sooner or later, hackers will work out ways of using the same pending transactions vulnerabilities against blockchain platforms. So far they always did…