Common Cross-Chain Bridge Vulnerabilities

Introduction

In the early days of crypto, you could easily exist without knowing or using more than just one “home” chain. But today, multi-chain has become the dominant paradigm. Web3 is formed out of hundreds, if not thousands of blockchains, each one with its own features, aims, and goals.

With each new addition, the web3 ecosystem is becoming more complicated. With the addition of interaction between both emergent and mature chains, web3 security has become a complex and multilayered issue, especially when dealing with Layer 1s, Layer 2s, Layer 3s, and even Layer 0 blockchains.

In order for these standalone blockchains to solve the problem of cross-chain interoperability (communication across different blockchains), the crypto community has developed cross-chain bridges, which are special smart contracts designed to enable asset transfer between chains.

While the technical aspects of every bridge differ, the main concept of how they operate is pretty much the same:

• A user sends funds on one chain, for example, ETH on the Ethereum blockchain, and receives a wrapped version of the same token, in our case wETH, on another chain.
• When an asset is sent back, it is simply unwrapped, or exchanged back to the original ETH asset on the Ethereum blockchain.

Therefore, in order to ensure a good user experience, cross-chain bridges must store an exceedingly high amount of locked value to ensure liquidity at all times. This concentration of dollar value at bridges presents a tempting opportunity to blackhat hackers, putting bridges at ever-present risk of theft or exploitation.

In the interest of learning more about web3 hacking, let’s lift the veil on cross-chain bridges and reveal how some were hacked in the past, as well as what their most common vulnerabilities are!

1. Unsafe external call — the Poly Network hack

Topping the charts as the second biggest DeFi hack of all time, Poly Network was a network of cross-chain bridges that successfully connected 35 different blockchains, until it didn’t.

On August 10th, 2021, blackhat hackers drained $611,000,000 (surpassing the GDP of 191 countries) from three Poly Network smart contracts on the ETH and BNB chains. Now comes the big question: How did they do it?

There was a privileged contract called EthCrossChainManager in the Poly Network ecosystem, which is responsible for triggering messages from other chains. It had a function called verifyHeaderAndExecuteTx, which validates the correctness of the block header and also checks that the transaction was included in the block.

After that, it called another function, _executeCrossChainTx, that made an external call to a variable _toContract.

_toContract could be controlled by any arbitrary user(s). No checks were implemented for the function execution, so that users could pass any contract address as an input. Moreover, the function accepted a custom bytes _method variable, which was then used as a payload in the external call.

To sum up, the EthCrossChainManager contract was privileged, and it could make an external call to any contract with custom calldata.

Let’s take a closer look at the external call.

The Poly Network contract was able to call any contract with calldata that was generated like this:

(abi.encodePacked(bytes4(keccak256(abi.encodePacked(_method, “(bytes,bytes,uint64)”))), abi.encode(_args, _fromContractAddr, _fromChainId)))

In this piece of code, the _method argument was controlled by the user.

Remember, EthCrossChainManager is a privileged contract. So, what if we trick this contract into calling another Poly Network contract and modify the calldata so that our tx will call the function in a way that will allow us to drain all the funds and pass the onlyOwner modifier?

Well, that’s exactly what the attacker did. They brute-forced the proper _method variable and convinced the EthCrossChainManager contract to call another Poly Network contract, EthCrossChainData. In this call, the attacker called the function putCurEpochConPubKeyBytes.

The project then literally hacked itself. And more than 600 million dollars vanished into thin air.

2. Unauthorized access to private keys — Ronin Network, Harmony Bridge hacks

Most bridges are owned by special multisig (multiple-signature) wallets. Unlike regular wallets, they utilize more than one signature to sign a transaction and send it into the blockchain network. This makes it better than a regular crypto wallet for operating critical infrastructure such as bridges in that it is more secure.

Or it should be.

Key management practices can be tricky to monitor and perfect in organizations of all sizes. Even though it should be difficult just to gain access to even one private key, 3 bridges have been hacked due to unauthorized access to multiple private keys that are responsible for operating multisigs.

Once the keys have been gained, they would grant the hacker privileged access, allowing them to drain all of the funds. Let’s take a look at how it happened…

Hack 1: Ronin Network, Supply-chain attack

Ronin Network is an Ethereum side-chain launched in February 2021. Its main purpose is to enable users to create and send cheap transactions in order to play a very popular P2E game called Axie Infinity.

To reduce costs, the developers decided to use a Proof of Authority model for their chain. Using this model, only 9 validators were capable of validating the transactions. At the time of the hack, 5 of them (more than 50% — the exact amount that was needed for a successful attack) were controlled by Ronin Network’s partner, Sky Mavis, the studio that created the game.

The attacker infiltrated Sky Mavis’s network and obtained the 5 signatures that were used to sign the messages. What followed next was obvious — the attacker then validated two transactions, withdrawing 173,000 ETH and more than 25,000,000 USDC, with the latter being later swapped to ETH.

For now, this holds the first place as the largest DeFi hack ever to have been perpetrated, for a grand total of $624,000,000 in losses, or about 10 of the most expensive Van Gogh paintings sold combined.

Hack 2: Harmony bridge, Compromised keys

The Harmony Bridge was secured by a multisig that required an unfortunate 2 out of 5 signatures to sign a transaction. Although the exact method that the hackers used to obtain control of the addresses is unknown, some people in the industry speculated that it had to do with the signers being operated as hot wallets. Moreover, the private keys were stored in plaintext format, which is not much better than having a post-it note with your password on it.

After hackers obtained the private keys, they used them to sign malicious transactions. This led to a $100,000,000 loss in different tokens and assets. Most of them were swapped to ETH and then cashed out using Tornado Cash.

3. Cryptographic attacks — BNB Bridge, Wormhole Bridge hacks

Hack 1: BNB Bridge. Forging a cryptographic proof

BNB Bridge was functioning as a bridge between the old Binance Beacon Chain and the new Binance Smart Chain. It was exploited by an attacker in order to mint 2,000,000 BNB. This hack is also notable for the unique fact that the Binance Smart Chain was stopped for about 8 hours as a result of the hack. There were likely multiple traders whose positions were liquidated due to this halt, adding to the collateral damage caused by this hack.

The cryptographic protocol created for the BNB Bridge unfortunately allowed attackers to forge proofs that were needed to send arbitrary messages. The hackers were able to send just 2 messages, but that was all it took to enable the mint of 2 million new BNB tokens, allowing the theft of $586,000,000 in value. Let’s take a closer look and understand how the attacker managed to deal so much damage with what seems like a simple mechanism.

BNB Bridge used IAVL (Immutable AVL tree) to verify the transactions. However, the hacker was able to forge the cryptographic proofs for a specific block number 110217401.

If we look closer into the transactions used in the hack, we will see that the block used in the tx is the one listed above, and the proof used by the hacker was less than half the size of a genuine proof in the transactions of other users.

In order to accomplish this, the hacker needed to bypass two operations called iavl:v and multistore. Both operations had to be successful, and the last operation must return the hash of the specific block number. Moreover, the input for multistore is actually the output of iavl:v!

The hack did not stop there. The hacker also had to forge the root variable in avl:v that is computed by another function computehash. It takes the signatures of leaves and paths, and then computes hashes of them. So, the hacker added a leaf node and an inner node to match, and then somehow compelled the leaf to provide the correct root hash.

This allowed hackers to mint 2,000,000 BUSD tokens which were then deposited to Venus, a Binance lending protocol, as collateral. The hacker then borrowed stablecoins and cross-bridged them to Ethereum, several L2 chains, and then to Fantom, which received a 10% boost of the entire ecosystem’s TVL as a result of the hack.

Hack 2: Wormhole Network. Signature validation bypass

The Wormhole exploit was another notable bridge hack that resulted in the theft of $326,000,000. Let’s look closer at one of the most-discussed hack events in DeFi and understand how the hackers were able to steal almost 120,000 ETH.

Let’s start with the problem. The issue with the protocol was present in the verify_Signatures function. It took a set of signatures provided by “Guardians”, that were used to verify transfers between blockchains, and passed those signatures to the signatureSet function.

signatureSet then delegated the check to the Secp256k1 program solana_program::sysvar::instructions.

However, the wrong version of solana_program that contained the Secp256k1 function was set, and no actual check was performed. That meant that the attackers could create an account with the data that Secp256k1 function should return, bypassing signature validation completely.

Using the return of the signatureSet function, hackers called the post_vaa function in order to obtain valid VAA (Verified Action Approvals), so they could successfully generate a VAA account that the bridge could accept. After that, they simply called the complete_wrapped function and minted 120,000 ETH.

4. Zero values exploit — Nomad Bridge, Qubit Finance hacks.

Hack 1: Nomad Bridge, Initialization Error

Nomad Bridge is, according to its official website, “a security-first cross-chain messaging protocol”. It was hacked by blackhats in August 2022, resulting in $190,000,000 in losses. Some crypto users in the community also exploited the protocol, in order to return funds directly to the project

Let’s take a look into how one of the most chaotic hacks in DeFi occurred.

The problem was in the Replica contract on Moonbeam Network. Hackers could send transactions without any proof — they just called the process function directly, draining the bridge of wBTC tokens.

Such transactions did not revert because of incorrect initialization. Because, after a routine update of the contract, the Zero address was set as a trusted root, which meant that any transaction proofs were valid.

The first attempt to hack the bridge failed, and the hacker spent a whopping $350,000 on gas. This must have been stressful for the attackers. However, they managed to send the next transactions successfully.

Other users spotted the hack in progress and were able to copy the same transaction data and send it on their own, so a lot of random users also joined in on the hack, exploiting the protocol along with the blackhats. Some of the funds were hacked by whitehats and then returned to the protocol.

Hack 2: Qubit Finance, Irrevertable safeTransferFrom

Qubit Finance is a project that allows collateralization on several chains, such as locking funds on Ethereum and borrowing on BNB. To use this functionality, you would call the QBridge deposit function.

This function will then call the IQBridgeHandler(handler).deposit() function, which would verify the input data.

Hackers called the deposit function in QBridge with no ETH attached. However, the transaction did not fail as it was supposed to.

The problem here was in the ‘IQBridgeHandler’ contract: tokenAddress.safeTransferFrom(depositer, address(this), amount

The ETH token address is a zero address, and because of this, such transactions will not revert, despite the fact that no actual transfer of ETH really occurred.

The attackers made away with $80,000,000 of assets, most of which were converted to ETH and deposited to Tornado.Cash.

Conclusion

The web3 industry is still young and inexperienced, and the technology of cross-chain bridging is even more so. That’s why some mistakes can seem negligent, especially errors in the secure handling of private keys or initialization. However, it is important to note that most of the attacks described in the article are historical firsts, having no precedent to prepare teams for such a hard reality.

Most of the projects mentioned in the article were unaudited — which is a big red flag for any large projects these days, but more than common in the early era of crypto. Some of the projects also did not have any Bug Bounty Programs (BBPs) at the time.

The lack of both audits and a working BBP failed to reveal weaknesses that are inherent in the design and operation of the smart contracts and mechanisms used, even after the bridges started to accumulate user funds in the hundreds of millions.

This stresses the importance of vigilance and preventative security practices, such as securing audits before launch and BBPs after, both of which work hand-in-hand to stop hacks before they occur.