This article is a community contribution. The author is Minzhi He, auditor of CertiK.
The opinions in this article are those of the contributor/author and do not necessarily reflect the views of Binance Academy.
Summary
Blockchain bridges are critical to achieving interoperability within the blockchain space. Therefore, your safety is of utmost importance. Some of the most common bridge security vulnerabilities include weak on-chain and off-chain validation, improper handling of native tokens, and misconfigurations. It is recommended to test the bridge against all possible attack vectors to ensure robust verification logic.
Introduction
A blockchain bridge is a protocol that connects two blockchains to allow interactions between them. If you have Bitcoin, but want to participate in a DeFi activity on the Ethereum network, a blockchain bridge allows you to do so without having to sell your Bitcoin.
Blockchain bridges are critical to achieving interoperability within the blockchain space. They work through various on-chain and off-chain validations, so they present different security vulnerabilities.
Why is bridge safety essential?
Typically, a bridge will hold the token that a user wants to transfer from one chain to another. Bridges, which are often implemented as smart contracts, hold a significant amount of tokens as cross-chain transfers accumulate, making them lucrative targets for hackers.
Additionally, blockchain bridges have a large attack surface because they include multiple components. With that in mind, malicious actors consider cross-chain applications to be very good targets for stealing large amounts of funds.
In 2022, bridge attacks generated losses of more than $1.3 billion, representing 36% of total losses for the year, according to estimates by CertiK.
Common Bridge Security Vulnerabilities
To improve the security of bridges, it is valuable to understand their most common vulnerabilities and test them before their release. These vulnerabilities can be classified 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 execute basic operations such as minting, burning, and transferring tokens, while all verifications are performed off-chain.
In contrast, other types of bridges use smart contracts to validate messages and perform on-chain verifications. In these cases, when a user deposits on-chain, the smart contract generates a signed message and returns the signature in the transaction. The signature serves as proof of the deposit and is used to verify the user's withdrawal request on the other chain. This process should be able to prevent various types of security attacks, including replay attacks and falsification of deposit records.
However, if there is a vulnerability in the validation process on-chain, the attacker can cause great damage. For example, if a bridge uses the Merkle tree to validate the transaction record, an attacker can generate forged receipts. This means that if the validation process is vulnerable, the attacker can bypass receipt validation and mint new tokens for your account.
Some bridges implement the concept of "wrapped tokens". For example, when a user transfers DAI from Ethereum to BNB Chain, the DAI is taken from the Ethereum contract and an equivalent amount of wrapped DAI is issued on BNB Chain.
However, if the transaction is not validated correctly, an attacker can implement a malicious contract to direct the wrapped tokens from the bridge to an incorrect address.
Attackers also need victims to approve the bridge contract in order to transfer tokens using the "transferFrom" function and thus drain assets from the bridge contract.
Unfortunately, this is made worse because many bridges request infinite approval of tokens from DApps users. This is a common practice that lowers gas fees, but creates additional risks by allowing a smart contract to access an unlimited number of tokens from the user's wallet. Attackers can exploit lack of validation and excessive approval to transfer tokens from other users to themselves.
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. This time we will focus on the verification of deposit transactions.
A blockchain bridge with off-chain validation works as follows:
Users interact with the DApp to deposit tokens into the source chain smart contract.
The DApp then sends the hash of the deposit transaction to the backend server via an API.
The transaction hash goes through several validations by the server. If deemed legitimate, a signer signs the message and sends the signature back to the UI via the API.
Upon receiving the signature, the DApp verifies it and authorizes the user to withdraw the tokens from the target chain.
The backend server must ensure that the deposit transaction it processes actually occurred and is not a forgery. This backend server determines whether the user can withdraw tokens on the target chain and is therefore a highly sought after attack target by cybercriminals.
The backend server must validate the structure of the transaction's emitted event, as well as the contract address that emitted the event. If the latter is neglected, an attacker could deploy a malicious contract to spoof a deposit event with the same structure as the legitimate deposit event.
If the backend server doesn't verify which address issued the event, it could consider it a valid transaction and sign the message. The attacker could then send the transaction hash to the backend, bypassing verification and managing to remove the tokens from the target chain.
Improper handling of native tokens
Bridges take different approaches to handling 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.
If a user tries to transfer their ETH to another chain, they must first deposit it into the bridge contract. To achieve this, the user simply attaches the ETH to the transaction, and the amount of ETH can be retrieved by reading the "msg.value" field of the transaction.
Depositing ERC-20 tokens is very different from depositing ETH. To deposit an ERC-20 token, the user must first allow the bridge contract to spend their tokens. After approval and tokens have been deposited into the bridge contract, the contract will burn the user's tokens using the "burnFrom()" function or transfer the user's token to the contract with the "transferFrom()" function.
One way to differentiate this is to use a conditional statement within the function itself. Another way is to create two separate functions to handle each scenario. Attempting to deposit ETH using the deposit feature for ERC-20 may result in loss of funds.
When handling ERC-20 deposit requests, users typically provide the token address as input to the deposit function. This involves significant risk, as unreliable external calls may occur during the transaction. Implementing a whitelist that only includes tokens supported by the bridge is a common practice to minimize this risk. Only whitelisted addresses can be passed as an argument. This prevents external calls, since the project team already leaked the token address.
However, problems can arise when bridges handle the transfer of native tokens cross-chain, since the native token does not have an address. A zero address (0x000...0) represents the native token. This can be problematic, as passing address zero to the function can bypass whitelist checking, even if implemented correctly.
When the bridge contract calls "transferFrom" to transfer the user's assets to the contract, the external call to address zero returns false because at address zero there is no "transferFrom" function implemented. However, the transaction can still occur if the contract does not properly handle the returned value. This creates an opportunity for attackers to execute the transaction without transferring any tokens to the contract.
Wrong configuration
In most blockchain bridges, the person responsible for whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other critical configurations is a privileged role. Ensuring all settings are accurate is critical, as even the most seemingly trivial oversights can lead to significant losses.
In fact, there was an incident where the attacker successfully bypassed the transfer log verification due to misconfiguration. The project team implemented a protocol update a few days before the hack, and this update involved changing a variable. The variable was used to represent the default value of the trusted message. This change caused all messages to be automatically classified as tested, allowing the attacker to send an arbitrary message and pass the verification process.
How to improve bridge safety
The four most common bridge vulnerabilities explained so far demonstrate the challenges in ensuring security in an interconnected blockchain ecosystem. There are significant considerations for handling each of these vulnerabilities and there is no easy solution that works for all of them.
For example, providing general guidelines to ensure an error-free verification process is difficult because each bridge has unique verification requirements. The most effective approach to prevent verification bypass is to thoroughly test the bridge against potential attack vectors and ensure that the verification logic is robust.
In short, it is essential to rigorously test against potential attacks and pay special attention to the most common bridge security vulnerabilities.
Conclusions
Due to their high value, cross-chain bridges have long been a target of attack. Developers can strengthen the security of their bridges by conducting extensive pre-deployment testing and engaging in third-party audits, reducing the risk of a recurrence of the devastating hacks that have plagued bridges in recent years. . Bridges are critical to the multichain world, but security must be a priority when designing and building 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?
Legal Notice and Risk Warning: This content is presented "as is" for general information and educational purposes only, without representation or warranty of any kind. It should not be construed as financial, legal or other professional advice nor is it intended to recommend the purchase of any specific product or service. You should seek individual advice from suitable professional advisors. As this article is contributed by a third party, please note that the opinions expressed are those of the third party contributor and do not necessarily reflect those of Binance Academy. For more information, read our full legal notice here. Digital asset prices can be volatile. The value of an investment can go down as well as up, and you may not get back the amount invested. Only you are responsible for your investment decisions. Binance Academy is not responsible for any losses you may incur. This material should not be construed as financial, legal or other professional advice. For more information, please see our Terms of Use and Risk Warning.
