This article is a community submission. The author is Minzhi He, auditor at CertiK.
The views in this article are those of the contributor/author and do not necessarily reflect the views of Binance Academy.
TL;DR
Blockchain bridges are fundamental to achieving interoperability within the blockchain space. The security of blockchain bridges is of paramount importance. Some common bridge security vulnerabilities include issues with on-chain and off-chain validation, poor management of native tokens, and misconfigurations. It is recommended to test the bridge against all possible attack vectors to ensure solid verification logic.
Introduction
A blockchain bridge (or "blockchain bridge") is a protocol that connects two blockchains to allow interactions between them. If you own bitcoins but want to participate in DeFi activity on the Ethereum network, a blockchain bridge allows you to do so without having to sell your bitcoins.
Blockchain bridges are fundamental to achieving interoperability within the blockchain space. They work using various on-chain and off-chain validations and therefore present different security vulnerabilities.
Why is bridge security essential?
Generally, a bridge holds the token that a user wants to transfer from one blockchain to another. Bridges are often deployed as smart contracts and hold a significant amount of tokens as cross-chain transfers accumulate, making them potentially lucrative targets for hackers.
Furthermore, blockchain bridges have many points susceptible to attacks, as they involve many components. With this in mind, malicious users are motivated to target cross-chain applications in an attempt to steal large amounts.
In 2022, attacks on bridges caused losses of more than 1.3 billion dollars, representing 36% of the year's total losses, according to CertiK estimates.
Common Bridge Security Vulnerabilities
To increase the security of bridges, it is important to understand their common vulnerabilities and test them before release. These vulnerabilities can be categorized into the following four areas.
Weak on-chain validation
For simple bridges, especially those designed for specific DApps, on-chain validation is kept to a minimum. These bridges rely on a centralized backend to perform basic operations such as issuing, burning, and transferring tokens, while all verifications are performed off-chain.
On the other hand, other types of bridges use smart contracts to validate messages and perform on-chain verifications. In this scenario, when a user deposits funds on a blockchain, the smart contract generates a signed message and returns the signature in the respective transaction. This signature serves as proof of deposit and is used to verify the user's withdrawal request on the other blockchain. This process must be able to prevent various security attacks, including replay attacks and falsified deposit records.
However, if there is a vulnerability during the on-chain validation process, a hacker could cause serious damage. For example, if a bridge uses Merkle tree to validate the transaction record, an attacker can forge falsified evidence. This means that if the validation process is vulnerable, they can bypass proof validation and create new tokens on their accounts.
Some bridges implement the concept of “wrapped tokens.” For example, when a user transfers 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.
However, if this transaction is not properly validated, a hacker can deploy a malicious contract and manipulate the function to route the bridge's wrapped tokens to an incorrect address.
Hackers need victims to approve the bridge contract to transfer tokens using the “transferFrom” function and steal contract assets.
Unfortunately, this problem is made worse because many bridges request unrestricted access (infinite token approval) to DApp users' tokens. This is a common practice that reduces Gas fees, but creates additional risks by allowing a smart contract to access an unlimited number of tokens from the user's wallet. Some hackers are able to exploit the lack of validation and unrestricted access to steal tokens from other users.
Weak off-chain validation
In some bridge systems, the off-chain backend server plays a critical role in verifying the legitimacy of messages sent from the blockchain. In this case, we will focus on verifying deposit transactions.
A blockchain bridge with off-chain validation works as follows:
Users interact with the DApp to deposit tokens into the smart contract on the originating blockchain.
Then, the DApp sends the deposit transaction hash to the backend server via an API.
The transaction hash is subject to several validations by the server. If deemed legitimate, a signer signs a message and sends the signature back to the UI via the API.
Upon receiving the signature, the DApp verifies it and allows the user to withdraw their tokens from the originating blockchain.
The backend server must ensure that the processed deposit transaction actually occurred and was not forged. It is this server that determines whether a user can withdraw tokens on the target blockchain. Therefore, it is a valuable target for hackers.
The backend server needs to validate the structure of the event emitted by the transaction, as well as the address of the contract that emitted that event. If the latter is neglected, a hacker can deploy a malicious contract to forge a deposit event with the same structure as a legitimate event.
If the backend server does not check which address issued the event, it will consider this transaction valid and sign the message. The hacker can send the transaction hash to the backend, bypassing the verification and allowing them to withdraw the tokens from the blockchain.
Poor management of native tokens
Bridges use different approaches to dealing with native tokens and utility tokens. For example, on the Ethereum network, the native token is ETH and most utility tokens adhere to the ERC-20 standard.
When a user wants to transfer ETH to another blockchain, they must first deposit the tokens into the bridge contract. To do this, the user simply attaches ETH to the transaction and the amount can be retrieved using the “msg.value” function in the transaction field.
Depositing ERC-20 tokens differs significantly from depositing ETH. To deposit an ERC-20 token, the user must first allow the bridge contract to spend their tokens. After approval and deposit of tokens into the bridge contract, the contract will burn the user's tokens using the "burnFrom()" function or transfer the tokens to the contract using the "transferFrom()" function.
One approach to differentiate this is to use an if-else statement within the same function. Another approach is to create two separate functions to handle each scenario. Attempting to deposit ETH using the ERC-20 deposit function may result in the loss of funds.
For ERC-20 deposit requests, users typically provide the token address as input to the deposit function. This operation presents risks, as unreliable external calls may occur during the transaction. Implementing a whitelist including only tokens supported by the bridge is a common practice to minimize risks. Only whitelisted addresses are accepted as arguments. This avoids external calls, as the project team has already filtered the token address.
However, problems can also arise when bridges handle the cross-chain transfer of native tokens, as a native token does not have an address. A zero address (0x000...0) is representative of the native token. This can be problematic, as submitting address zero to the function can cause it to bypass the whitelist check, even if implemented incorrectly.
When the bridge contract calls the “transferFrom” function to transfer user assets to the contract, the external call to address zero returns false as there is no “transferFrom” function implemented at address zero. However, the transaction can still occur if the contract does not handle the return value appropriately. This creates an opportunity for hackers to execute the transaction without transferring any tokens to the contract.
Incorrect configuration
In most blockchain bridges, a privileged role is responsible for whitelisting tokens and addresses, assigning or changing signers, and other critical settings. Ensuring that all settings are accurate is crucial, as even seemingly trivial oversights can lead to significant losses.
In fact, there was an incident where the hacker was able to bypass the transfer log check due to incorrect configuration. A few days before the attack, the project team implemented a protocol update that involved changing a variable. The variable was used to represent the default value of the trusted message. Because of this change, all messages were automatically considered verified, thus allowing an attacker to send an arbitrary message and successfully pass the verification process.
How to improve bridge security
The four most common bridge vulnerabilities explained above highlight the challenges of ensuring security in an interconnected blockchain ecosystem. There are important considerations for dealing with each of these vulnerabilities, and there is no guide that applies to all of them.
For example, providing general guidelines to ensure an error-free verification process is challenging because each bridge has its own verification requirements. The most effective approach to preventing verification bypass is to thoroughly test the bridge against all possible attack vectors and ensure that the verification logic is sound and consistent.
In short, it is essential to carry out rigorous testing against possible attacks and pay special attention to the most common security vulnerabilities in bridges.
Final considerations
Due to their high value, cross-chain bridges have been a target of hackers for a long time. Developers can improve the security of their bridges through pre-deployment testing and third-party audits, reducing the risk of devastating hacking attacks like those of recent years. Bridges are essential in a world with multiple blockchains, but security must be a priority when designing and developing an effective Web3 infrastructure.
Further reading
What is a Blockchain Bridge?
What is cross-chain interoperability?
Three popular crypto bridges and how they work
What are Wrapped Tokens?
Risk Notice and Disclaimer: This content is presented to you “as is” for informational and educational purposes only, without warranty of any kind. The content should not be construed as financial, legal or professional advice, and is not intended to recommend the purchase of any specific product or service. You should seek your own advice from professional advisors. In the case of contributions and articles submitted by third-party contributors, please note that the opinions expressed are those of the respective author and do not necessarily reflect the opinions of Binance Academy. For more details, please read our disclaimer here. Digital asset prices can be volatile. The value of your investment may increase or decrease and you may not get back the amount invested. You are solely responsible for your investment decisions and Binance Academy is not responsible for any of your possible losses. This material should not be construed as financial, legal or professional advice. For more information, please see our Terms of Use and Risk Notice.