This article is a community contribution. The author is Minzhi He, auditor of CertiK.

The views expressed in this article are those of the contributor/author and do not necessarily reflect the views of Binance Academy.

Summary

Blockchain bridge is fundamental to achieving interoperability in the blockchain field. Therefore, the security of cross-chain bridging technology is crucial. Some common blockchain bridge security vulnerabilities include insufficient on-chain and off-chain verification, improper handling of native tokens, and misconfiguration. To ensure that the verification logic is sound, it is recommended to test the cross-chain bridge against all possible attack vectors.

Introduction

Blockchain bridge connects two blockchains , a protocol that allows the two to interact. Through the blockchain bridge, if users want to participate in DeFi activities on the Ethereum network, they only need to hold Bitcoin and do not need to sell it to achieve their goals.

Blockchain bridge is the foundation for interoperability in the blockchain field. They use various on-chain and off-chain verifications to function, so there may be different security vulnerabilities as well.

Why is the security of blockchain bridges crucial?

Blockchain bridges typically hold tokens that users want to transfer from one chain to another. Blockchain bridges are usually deployed in the form of smart contracts. As cross-chain transfers continue to accumulate, a large number of tokens will be held on the bridge. This huge wealth will make them a coveted target for hackers.

Additionally, the attack surface of blockchain bridges tends to be large due to the many components involved. Therefore, criminals have strong incentives to target cross-chain applications in order to obtain large amounts of funds.

According to CertiK estimates, blockchain bridge attacks caused more than $1.3 billion in losses in 2022, accounting for 36% of the total losses that year. .

Common cross-chain bridging security vulnerabilities

In order to enhance the blockchain Bridge security, it is important to understand common cross-chain bridge security vulnerabilities and test the blockchain bridge before launching it. These vulnerabilities mainly come from the following four aspects:

Insufficient on-chain verification

For simple blockchain bridges, especially those designed for a specific dApp, there is usually only a minimal degree of on-chain verification. These bridges rely on a centralized backend to perform basic operations such as minting, burning, and token transfers, with all verification occurring off-chain.

While other types of bridges use smart contracts to verify messages and verify them on-chain. In this case, when a user deposits funds into the chain, the smart contract generates a signed message and returns the signature in the transaction. This signature will be used as proof of deposit and used to verify the user's withdrawal request on another chain. This process should prevent various security attacks, including replay attacks and falsified top-up records.

However, if there is a vulnerability in the on-chain verification process, the attack could cause serious damage. For example, if the blockchain uses Merkle trees to verify transaction records, an attacker can generate forged proofs. This means that if the verification process is vulnerable, an attacker can bypass proof verification and mint new tokens in their account.

Some blockchain bridges will implement the concept of "wrapped tokens". For example, when a user transfers DAI from Ethereum to BNB Chain, their DAI is taken out of the Ethereum contract and an equal amount of wrapped DAI is issued on BNB Chain.

However, if this transaction is not properly verified, an attacker can deploy a malicious contract and manipulate the function to convert the wrapped code Coins are routed from the bridge to the wrong address.

The attacker also needs the victim to approve the cross-chain bridge contract before using the "TransferFrom" function to transfer tokens from the cross-chain bridge contract Take away assets.

But the tricky thing is that many cross-chain bridges require dApp users to approve tokens indefinitely. This practice is very common and it Gas fees can be reduced, but allowing smart contracts to access an unlimited amount of tokens from the user’s wallet introduces additional risks. Attackers would exploit these under-verifications and over-approvals to transfer tokens from other users to themselves.

Insufficient off-chain verification

In some cross-chain bridge systems, off-chain backend servers play a crucial role in verifying the legitimacy of messages sent from the blockchain. In this case, we need to focus on the verification of the recharge transaction.

The working principle of the blockchain bridge with off-chain verification is as follows:

1. Users interact with the dApp and deposit tokens into smart contracts on the source chain.

2. Then, the dApp sends the deposit transaction hash to the backend server through the API.

3. The transaction hash needs to be verified multiple times by the server. If deemed legitimate, the signer signs a message and sends the signature back to the user interface via the API.

4. After receiving the signature, the dApp verifies it and allows the user to withdraw tokens from the target chain.

The backend server must ensure that the recharge transactions it handles are real and not forged. This backend server determines whether a user can withdraw tokens on the target chain, making it the first target of attacks.

The backend server needs to verify the structure of the transaction initiation event and the contract address that initiated the event. If the latter is ignored, attackers may deploy malicious contracts to forge recharge events with the same structure as legitimate recharge events.

If the backend server does not verify which address initiated the event, it will consider it a valid transaction and sign the message. An attacker can then send the transaction hash to the backend server, bypassing verification and allowing it to withdraw tokens from the target chain.

Improper native token handling

Cross-chain bridges take a different approach to native tokens and utility tokens. For example, on the Ethereum network, the native token is ETH, and most utility tokens comply with the ERC-20 standard.

If users plan to transfer their ETH to another chain, they must first deposit it into the cross-chain bridge contract. To do this, the user simply attaches ETH to the transaction and can retrieve the amount of ETH by reading the "msg.value" transaction field.

Depositing ERC-20 tokens is very different from depositing ETH. To deposit ERC-20 tokens, users must first allow the cross-chain bridge contract to use their tokens. After they approve and deposit the tokens into the cross-chain bridge contract, the contract will use the "burnFrom()" function to destroy the user's tokens, or the "transferFrom()" function to transfer the user's tokens to the contract.

To distinguish which operation it is, you can use an if-else statement in the same function. Or create two separate functions to handle each scenario. Due to different processing methods, if a user attempts to deposit ETH using the ERC-20 deposit function, the ETH may be lost.

When processing ERC-20 deposit requests, users usually provide the token address as an input parameter and pass it to the deposit function. This poses a significant risk, as untrusted external calls may occur during transactions. Using a whitelist to only include tokens supported by a cross-chain bridge is a common practice to minimize risk. Only whitelisted addresses are passed as parameters. This prevents external calls because the project team has filtered the token addresses.

However, when the cross-chain bridge handles the cross-chain transfer of native tokens, there is also a trouble because the native tokens have no addresses. Native tokens can be represented by a special address, the "zero address" (0x000... 0). But there is a problem with this, if the whitelist verification logic is not implemented correctly, passing a zero address to the function may bypass the whitelist verification.

When the cross-chain bridge contract calls "TransferFrom" to transfer user assets to the contract, the external call to the zero address will return false , because the "transferFrom" function is not implemented in the zero address. However, if the contract does not handle the return value correctly, the transaction may still continue to occur. This creates an opportunity for an attacker to execute a transaction without transferring any tokens to the contract.

Configuration error

In most blockchain bridges, there is a privileged role responsible for whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other key configurations. It is critical to ensure that all configurations are accurate, as seemingly trivial oversights can lead to significant damage.

In fact, there have been incidents where attackers successfully bypassed transmission record verification due to configuration errors. The project team implemented a protocol upgrade days before the hack in which a certain variable was changed. This variable is the default value used to represent trusted messages. This change causes all messages to be automatically considered authenticated, thus allowing an attacker to submit a random message and pass the validation.

How to improve the security of cross-chain bridges

As mentioned above Four common cross-chain bridge vulnerabilities demonstrate that security challenges in connected blockchain ecosystems cannot be underestimated. To deal with these vulnerabilities, we need to consider "according to local conditions". No method can be a panacea to deal with all vulnerabilities.

For example, since each cross-chain bridge has unique verification requirements, simply providing general guidelines would ensure that the verification process does not Wrong, this is hard to do. The most effective way to prevent verification bypass is to thoroughly test the cross-chain bridge against all possible attack vectors and ensure that the verification logic is reasonable.

All in all, rigorous testing must be conducted against potential attacks, with special attention paid to the most common security vulnerabilities in cross-chain bridges.

Conclusion

Cross-chain bridges have long been targeted by attackers due to the huge amount of funds. Builders can strengthen the security of cross-chain bridges by conducting comprehensive pre-deployment testing and incorporating third-party audits, thereby reducing the risk of catastrophic hacks that have loomed over cross-chain bridges over the past few years. Cross-chain bridges are crucial in a multi-chain world, but security must be a primary consideration when designing and building effective Web3 infrastructure.

Extended reading

What is a blockchain bridge?

What is cross-chain interoperability?

Three popular cryptocurrency bridges and their working principles

What is a wrapped token?

Disclaimer and Risk Warning: The contents of this article are facts and are for general information and educational purposes only and do not constitute any representation or warranty. This article should not be construed as financial, legal, or other professional advice and is not a recommendation that you purchase any specific product or service. You should seek your own advice from appropriate professional advisers. If this article was provided by a third-party contributor, please note that the views expressed in this article belong to the third-party contributor and do not necessarily reflect the views of Binance Academy. For more information, please clickhereto read our full disclaimer. Digital asset prices may fluctuate. The value of your investment may fall as well as rise and you may not get back the principal invested. You are solely responsible for your own investment decisions and Binance Academy is not responsible for any losses you may suffer. This article does not constitute financial, legal or other professional advice. For more information, please see ourTerms of UseandRisk Warning.