What are the common cross-chain bridge security vulnerabilities?

Summary

Blockchain bridges are fundamental to achieving interoperability in the blockchain space. Therefore, the security of cross-chain bridging technology is crucial. Common security vulnerabilities in blockchain bridges include insufficient on-chain and off-chain validation, improper handling of native tokens, and configuration errors. To ensure the validation logic is sound, it is recommended to test all possible attack vectors on the cross-chain bridge before deployment.

Introduction

A blockchain bridge is a protocol that connects two blockchains, enabling interaction between them. Through a blockchain bridge, users can participate in Ethereum network DeFi activities simply by holding Bitcoin, without needing to sell it.

Blockchain bridges are the foundation for interoperability in the blockchain field. They utilize various on-chain and off-chain validation methods, which can also introduce different security vulnerabilities.

Why is the security of blockchain bridges so important?

Blockchain bridges often hold tokens that users want to transfer from one chain to another. These bridges are usually deployed as smart contracts, and as cross-chain transfers accumulate, they hold large amounts of tokens. This substantial wealth makes them attractive targets for hackers.

Additionally, because they involve many components, blockchain bridges often have a large attack surface. Malicious actors are highly motivated to target cross-chain applications in hopes of stealing significant funds.

According to CertiK estimates, in 2022, attacks on blockchain bridges caused over $1.3 billion in losses, accounting for 36% of total losses that year.

Common Security Vulnerabilities in Cross-Chain Bridges

To enhance the security of blockchain bridges, it is important to understand common vulnerabilities and test the bridge thoroughly before launch. These vulnerabilities mainly stem from four areas:

Insufficient On-Chain Validation

For simple blockchain bridges, especially those designed for specific dApps, on-chain validation is often minimal. These bridges rely on centralized backends to perform basic operations such as minting, burning, and token transfers, with all validation done off-chain.

Other types of bridges use smart contracts to verify messages and perform on-chain validation. In such cases, when users deposit funds, the smart contract generates a signed message and returns the signature in the transaction. This signature serves as proof of deposit, used to verify withdrawal requests on the other chain. This process should prevent various security attacks, including replay attacks and falsified deposit records.

However, if there are vulnerabilities in the on-chain validation process, attacks can cause severe losses. For example, if the blockchain uses Merkle trees to verify transaction records, an attacker could generate a forged proof. This means that if the validation process is flawed, attackers could bypass proof verification and mint new tokens in their accounts.

Some blockchain bridges implement the concept of “wrapped tokens” (wrapped tokens). For example, when users transfer DAI from Ethereum to BNB Chain, their DAI is withdrawn from the Ethereum contract and an equivalent amount of wrapped DAI is issued on BNB Chain.

But if this transaction is not properly validated, attackers could deploy malicious contracts and manipulate this functionality to route wrapped tokens to incorrect addresses.

Attackers also need the victim to approve the cross-chain bridge contract first, to use the “transferFrom” function to move tokens, thereby draining assets from the bridge contract.

A tricky aspect is that many cross-chain bridges require dApp users to approve tokens infinitely. While this reduces gas costs, it also allows smart contracts to access unlimited tokens in users’ wallets, introducing additional risks. Attackers can exploit these validation flaws and over-approval to transfer tokens from other users to themselves.

Off-Chain Validation Insufficiency

In some cross-chain bridge systems, off-chain backend servers play a critical role in verifying the legitimacy of messages sent from the blockchain. In these cases, the focus is on validating deposit transactions.

The working principle of a bridge with off-chain validation is as follows:

• Users interact with the dApp, depositing tokens into a smart contract on the source chain.
• The dApp sends the deposit transaction hash to the backend server via API.
• The server performs multiple validations on the transaction hash. If deemed legitimate, the signer signs a message and returns the signature via API to the user interface.
• After receiving the signature, the dApp verifies it and allows the user to withdraw tokens on the target chain.

The backend server must ensure that the deposit transaction is genuine and not forged. This server determines whether the user can withdraw tokens on the target chain, making it a prime attack target.

The server needs to verify the structure of the deposit event and the contract address that initiated it. Ignoring the latter, an attacker could deploy malicious contracts to forge deposit events with the same structure as legitimate ones.

If the server does not verify which address initiated the event, it may consider the transaction valid and sign the message. Attackers can then send transaction hashes to the server, bypass validation, and withdraw tokens from the target chain.

Improper Handling of Native Tokens

Cross-chain bridges handle native tokens and utility tokens differently. For example, on Ethereum, the native token is ETH, and most utility tokens conform to the ERC-20 standard.

If a user intends to transfer ETH to another chain, they must first deposit it into the bridge contract. This is done by attaching ETH to the transaction, which can be retrieved from the “msg.value” field.

Depositing ERC-20 tokens differs significantly. Users must first approve the bridge contract to spend their tokens. After approval and deposit, the contract either burns the tokens using “burnFrom” or transfers them into the contract with “transferFrom.”

To distinguish between these operations, one can use if-else statements within the same function or create separate functions for each scenario. Since the handling differs, attempting to deposit ETH via an ERC-20 deposit function could result in loss of ETH.

When processing ERC-20 deposit requests, users typically provide the token address as an input parameter. This poses a significant risk because external calls during transactions can be untrusted. Using a whitelist containing only supported tokens is a common way to minimize risk. Only whitelisted addresses are accepted as parameters, preventing external calls, as the project team filters token addresses.

However, when handling native tokens, there is a complication because native tokens lack an address. They can be represented by a special address, such as the “zero address” (0x000…000). But if the whitelist validation logic is not correctly implemented, passing the zero address could bypass whitelist checks.

When the bridge contract calls “transferFrom” to move user assets to the contract, external calls to the zero address will return false, since the zero address does not implement “transferFrom.” But if the contract does not handle the return value properly, the transaction may still proceed. This creates an opportunity for attackers to execute transactions without actually transferring any tokens.

Configuration Errors

In most blockchain bridges, a privileged role is responsible for whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other critical configurations. Ensuring all configurations are accurate is vital, as seemingly minor mistakes can lead to significant losses.

In fact, there have been incidents where attackers successfully bypassed transfer record verification due to configuration errors. For example, a project team performed a protocol upgrade days before a hack, changing a variable that indicates trusted messages. This change caused all messages to be automatically considered verified, allowing attackers to submit arbitrary messages that would pass validation.

How to Improve the Security of Cross-Chain Bridges

The four common vulnerabilities discussed above highlight the significant security challenges in the interconnected blockchain ecosystem. Addressing these vulnerabilities requires tailored solutions; there is no one-size-fits-all method.

For example, since each cross-chain bridge has unique validation requirements, providing generic guidelines to ensure error-free validation is difficult. The most effective way to prevent validation bypasses is to conduct comprehensive testing against all attack vectors and ensure the validation logic is sound.

In summary, rigorous testing for potential attacks and particular attention to the most common security vulnerabilities in cross-chain bridges are essential.

Conclusion

Due to the large amounts of funds involved, cross-chain bridges have long been prime targets for attackers. Builders can strengthen bridge security through thorough pre-deployment testing and third-party audits, reducing the risk of catastrophic hacks that have plagued bridges in recent years. Cross-chain bridges are vital in a multi-chain world, but security must be the top priority when designing and building effective Web3 infrastructure. ($STO