This article is a community contribution. The author is Minzhi He, an auditor at CertiK.
The opinions expressed in this article are those of the contributors/authors and do not necessarily reflect the views of Binance Academy.
Summary
Blockchain bridges are fundamental to achieving interoperability in the blockchain space. Therefore, the security of cross-chain bridging technology is of vital importance. Some common blockchain bridge security vulnerabilities include insufficient on-chain and off-chain verification, improper handling of native tokens, and configuration errors. In order to ensure that the verification logic is reasonable, it is recommended to test the cross-chain bridge against all possible attack vectors.
Introduction
The blockchain bridge is a protocol that connects two blockchains and enables them 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 can achieve their goal without selling it.
Blockchain bridges are the foundation for interoperability in the blockchain space. They use various on-chain and off-chain validation to function, and therefore may have different security vulnerabilities.
Why is the security of blockchain bridges so important?
Blockchain bridges usually 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, the bridges will hold a large number of tokens, and this huge wealth will make them a target for hackers.
Furthermore, the attack surface of blockchain bridges is often large due to the many components involved. Therefore, bad actors have a strong incentive to target cross-chain applications in order to siphon off large amounts of funds.
According to CertiK’s estimates, in 2022, blockchain bridge attacks caused more than $1.3 billion in losses, accounting for 36% of the total losses that year.
Common cross-chain bridging security vulnerabilities
In order to enhance the security of blockchain bridges, it is important to understand common cross-chain bridging security vulnerabilities and test the blockchain bridge before launching. 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 level of on-chain verification. These bridges rely on a centralized backend to perform basic operations such as minting, burning, and token transfers, and all verification is performed off-chain.
Other types of bridges use smart contracts to authenticate messages and verify them on-chain. In this case, when a user deposits funds into a chain, the smart contract generates a signed message and returns the signature in the transaction. This signature is used as proof of deposit to verify the user's withdrawal request on the other chain. This process should prevent various security attacks, including replay attacks and forged deposit records.
However, if there are loopholes 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 fake proofs. This means that if there are loopholes in the verification process, the attacker can bypass the proof verification and mint new tokens in his account.
Some blockchain bridges implement the concept of “wrapped tokens.” For example, when a user transfers DAI from Ethereum to BNB Chain, their DAI will be taken out of the Ethereum contract and an equal amount of wrapped DAI will be issued on BNB Chain.
However, if this transaction does not validate correctly, an attacker could deploy a malicious contract that would route wrapped tokens from the bridge to the wrong address by manipulating this function.
The attacker also requires the victim to approve the cross-chain bridge contract before using the “TransferFrom” function to transfer tokens, thereby siphoning away assets from the cross-chain bridge contract.
But the tricky part is that many cross-chain bridges require dApp users to approve tokens indefinitely, which is a common practice. It can reduce gas fees, but allowing smart contracts to access unlimited tokens from users' wallets brings additional risks. Attackers can take advantage of these under-verification and over-approval to transfer tokens from other users to themselves.
Insufficient off-chain verification
In some cross-chain bridge systems, the off-chain backend server plays a vital role in verifying the legitimacy of messages sent from the blockchain. In this case, we want to focus on the verification of the top-up transaction.
The working principle of a blockchain bridge with off-chain verification is as follows:
Users interact with the dApp and deposit tokens into the smart contract on the source chain.
The dApp then sends the deposit transaction hash to the backend server via the API.
The transaction hash is 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.
Once the signature is received, 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 processes are real and not forged. This backend server determines whether the user can withdraw tokens on the target chain, so it becomes the first target of attack.
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, an attacker may deploy a malicious contract to forge a recharge event with the same structure as a legitimate recharge event.
If the backend server does not verify which address initiated the event, it will consider it a valid transaction and sign the message. The attacker can then send the transaction hash to the backend server, bypassing the verification and allowing it to extract tokens from the target chain.
Improper handling of native tokens
Cross-chain bridges use different approaches to handle native tokens and utility tokens. For example, on the Ethereum network, the native token is ETH, and most utility tokens conform to the ERC-20 standard.
If a user intends to transfer their ETH to another chain, they must first deposit it into the cross-chain bridge contract. To do this, the user only needs to attach 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 their tokens into the cross-chain bridge contract, the contract will destroy the user's tokens with the "burnFrom()" function or transfer the user's tokens to the contract with the "transferFrom()" function.
To distinguish which operation is which, you can use if-else statements in the same function. Or create two separate functions to handle each scenario. Due to the different handling methods, if a user tries to deposit ETH using the ERC-20 deposit function, the ETH may be lost.
When processing an ERC-20 deposit request, users usually provide the token address as an input parameter to the deposit function. This poses a significant risk as untrusted external calls may occur during the transaction. Using a whitelist to only include tokens supported by the cross-chain bridge is a common practice to minimize the risk. Only whitelisted addresses are passed as parameters. This prevents external calls because the project team has already filtered the token addresses.
However, when the cross-chain bridge handles the cross-chain transfer of native tokens, there is also a problem, because the native token has no address. The native token can be represented by a special address, namely the "zero address" (0x000... 0). But there is a problem with this. If the whitelist verification logic is not implemented correctly, using the zero address to pass 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 attackers to execute transactions 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 critical configurations. It is critical to ensure that all configurations are accurate, as seemingly minor oversights can result in significant losses.
In fact, there was an incident where an attacker successfully bypassed the transfer record verification due to a configuration error. The project team implemented a protocol upgrade a few days before the hacker attack, which changed a variable. The variable was the default value used to represent a trusted message. This change caused all messages to be automatically considered verified, so the attacker could submit any message and pass the verification.
How to improve the security of cross-chain bridges
The four common cross-chain bridge vulnerabilities described above show that the challenges faced by security in the interconnected blockchain ecosystem cannot be underestimated. To deal with these vulnerabilities, it is necessary to consider them in a "local" way. There is no one way to deal with all vulnerabilities.
For example, since each cross-chain bridge has unique verification requirements, it is difficult to ensure that the verification process is error-free by simply providing general guidelines. The most effective way to prevent bypassing verification is to thoroughly test the cross-chain bridge against all possible attack vectors and ensure that the verification logic is reasonable.
In summary, rigorous testing against potential attacks must be performed, with special attention paid to the most common security vulnerabilities in cross-chain bridges.
Conclusion
Due to the huge amount of money involved, cross-chain bridges have long been a target for attackers. 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 shrouded cross-chain bridges in the past few years. Cross-chain bridges are essential in a multi-chain world, but security must be a top consideration when designing and building effective Web3 infrastructure.
Further reading
What is a blockchain bridge?
What is cross-chain interoperability?
The three most popular cryptocurrency bridges and how they work
What are wrapped tokens?
Disclaimer and Risk Warning: The content of this article is factual and for general information and educational purposes only. It does not constitute any representation or warranty. This article should not be construed as financial, legal, or other professional advice, and does not constitute a recommendation that you purchase any specific product or service. You should seek advice from appropriate professional advisors. If this article is provided by a third-party contributor, please note that the opinions expressed herein are those of the third-party contributor and do not necessarily reflect the opinions of Binance Academy. For more information, please read our full disclaimer here. Cryptocurrency prices may fluctuate. The value of your investment may go down or up, and you may not get back the money you invest. You are solely responsible for your investment decisions, and Binance Academy is not responsible for any losses you may incur. This article does not constitute financial, legal, or other professional advice. For more information, please refer to our Terms of Use and Risk Warning.
