This article is a contribution from the community. The author is Minzhi He, auditor at CertiK.
The views expressed in this article are those of the contributor/author and do not necessarily reflect the views of Binance Academy.
In brief
Blockchain bridges are the foundation for achieving interoperability in the blockchain sector. Therefore, securing bridges is very important. Some common bridge security vulnerabilities include weak on-chain and off-chain authentication, improper handling of native tokens, and misconfigurations. The bridge should be tested to ensure it can withstand all attack vectors and ensure proper verification logic.
Introduce
A blockchain bridge is a protocol that connects two blockchains to enable interaction between them. If you own bitcoin but want to participate in DeFi activity on the Ethereum network, the blockchain bridge will allow you to do so without selling your bitcoin.
Blockchain bridges are fundamental to achieving interoperability in the blockchain sector. They operate using different on-chain and off-chain authentications, and thus have different security vulnerabilities.
Why is bridge security important?
Bridges typically hold tokens that users want to transfer from one chain to another. Often deployed as smart contracts, bridges 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 involve many components. Given that nature, malicious actors are highly motivated to target cross-chain applications to withdraw large sums of funds.
Bridge attacks lead to losses of more than $1.3 billion in 2022, accounting for 36% of total losses for the year, according to CertiK estimates.
Common bridging vulnerabilities
To improve bridge security, it is valuable to understand common bridge vulnerabilities and test bridges before launching them. These vulnerabilities can be classified into four types as follows.
Weak on-chain authentication
For simple bridges, especially those designed for specific DApps, on-chain validation is often minimal. These bridges rely on a centralized backend to perform basic operations such as minting, burning, and transferring tokens while all verification is done off-chain.
In contrast, other types of bridges use smart contracts to validate messages and perform on-chain verification. In this case, when a user deposits money into a chain, the smart contract generates a signed message and returns the signature in the transaction. This signature serves as proof of deposit, used to verify a user's withdrawal request on another chain. This process will be able to prevent various security attacks, including replay attacks and fake deposit records.
However, if there are vulnerabilities in the on-chain authentication process, an attacker can cause serious damage. For example, if a bridge uses a Merkle tree to authenticate transaction records, an attacker could create tampered proofs. This means they can bypass proof authentication and mint new tokens into their accounts if the authentication process is vulnerable.
Some bridges implement the concept of “wrapped tokens.” For example, when a user transfers DAI from Ethereum to BNB Chain, their DAI is taken from the Ethereum contract and an equivalent amount of wrapped DAI is released on the BNB Chain.
However, if this transaction is not properly authenticated, an attacker can deploy a malicious contract to route wrapped tokens from the bridge to an incorrect address by manipulating the functionality.
The attackers also need the victim to approve the bridge contract to transfer the tokens using the “transferFrom” function to withdraw assets from the bridge contract.
Unfortunately, this gets worse because many bridges require unlimited token approval from DApp users. This is a popular method that reduces gas fees but creates additional risk by allowing the smart contract to access an unlimited number of tokens from the user's wallet. Attackers can exploit the lack of authentication and excessive approvals to transfer tokens from other users to them.
Weak off-chain authentication
In some bridge systems, off-chain backend servers play an important role in verifying the legitimacy of messages sent from the blockchain. In this case, we are focusing on verifying deposit transactions.
A blockchain bridge with off-chain authentication works as follows:
Users interact with the DApp to deposit tokens into a smart contract on the source chain.
This DApp then sends the deposit transaction hash string to the backend server via API.
The transaction hash string is subject to some server validation. If deemed legitimate, the signer signs a message and sends the signature back to the user interface via the API.
Upon receiving a signature, the DApp will verify it and allow users to withdraw their tokens from the target chain.
The backend server must ensure that the deposit transaction it processes actually took place and has not been tampered with. This backend server determines whether users can withdraw tokens on the target chain and is therefore a high-value target for attackers.
The backend server needs to validate the structure of the transaction's emitted event, as well as the contract address that emitted the event. If the latter is ignored, an attacker can deploy a malicious contract to fake a deposit event with the same structure as a legitimate deposit event.
If the backend server does not verify which address issued the event, it considers this a valid transaction and signs the message. The attacker can then send the transaction hash to the backend, bypassing verification and allowing them to withdraw tokens from the target chain.
Improper handling of native tokens
Bridges have different approaches to handling native tokens and utility tokens. For example, on the Ethereum network, native tokens are ETH and most utility tokens comply with the ERC-20 standard.
When users intend to transfer their ETH to another chain, they must first deposit it into the bridge contract. To achieve this, users simply need to attach ETH to the transaction and the amount of ETH can be obtained by reading the “msg.value” field of the transaction.
Sending ERC-20 tokens is significantly different from sending ETH. To deposit an ERC-20 token, users must first authorize the bridge contract to spend their tokens. Once they have approved this and deposited the tokens into the bridging contract, the contract will either burn the user's tokens using the "burnFrom()" function or transfer the user's 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 situation. Attempting to deposit ETH using the ERC-20 deposit function may result in the loss of these funds.
When processing ERC-20 deposit requests, users typically provide token addresses as input to the deposit function. This poses a significant risk as untrusted outside calls can occur during the transaction. Implementing a whitelist that only includes bridge-supported tokens is a popular way to mitigate risk. Only whitelisted addresses are allowed to be passed as arguments. This prevents external calls because the project team has filtered token addresses.
However, problems can also arise when bridges handle cross-chain transfers of native tokens, since native tokens do not have an address. Address number 0 (0x000...0) represents the original token. This can be problematic because passing address 0 to a function can bypass whitelist verification even if implemented incorrectly.
When the bridge contract calls "transferFrom" to transfer the user's assets to the contract, the external call to address zero returns false because there is no "transferFrom" function implemented in address zero. However, the transaction can still occur if the contract does not handle the return value appropriately. This creates an opportunity for attackers to make transactions without transferring any tokens to the contract.
Wrong configuration
In most blockchain bridges, a privileged role is responsible for whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other important configurations. Ensuring that all configurations are correct is crucial, as even seemingly small errors can lead to significant losses.
In fact, there was an issue where an attacker successfully bypassed transfer record verification due to misconfiguration. The project team performed a protocol upgrade a few days before the hack, which involved changing a variable. Variable used to represent the default value of a trusted message. This change results in all messages being automatically considered proven, thus allowing an attacker to send an arbitrary message and bypass the verification process.
How to improve bridge security
The four common bridging vulnerabilities explained above demonstrate the challenges of ensuring security in an interconnected blockchain ecosystem. There are important considerations for addressing each of these vulnerabilities, and no single playbook 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 prevent verification bypass is to thoroughly test the bridge against all possible attack vectors and ensure proper verification logic.
In summary, it is essential to perform rigorous testing against potential attacks and pay special attention to the most common security vulnerabilities for bridges.
summary
Due to their high value, cross-chain bridges have long been a target for attackers. Developers can increase the security of their bridges by conducting thorough testing before deployment and using third parties to participate in auditing, to reduce the risk of vulnerabilities. devastating attacks - which have plagued bridges over the past few years. Bridges are very important components in a multi-chain world, but security must be a top concern to design and build an effective Web3 infrastructure.
Read more:
What is a Blockchain Bridge?
What is Cross-Chain Interoperability?
Three Popular Cryptocurrency Bridges and How They Work
What are wrapped tokens?
Disclaimer and Risk Warning: This content is presented to you on an "as is" basis 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 as a recommendation to purchase any specific product or service. You should seek your own advice from appropriate professional advisers. In cases where articles are contributed by third-party contributors, please note that the views expressed belong to the third-party contributor and do not necessarily reflect the views of Binance Academy. Please read our full disclaimer here for more details. Digital asset prices may fluctuate. The value of your investment may go down as well as up and you may not get back the amount you invested. You are solely responsible for your investment decisions and Binance Academy is not liable for any losses you may incur. This material should not be construed as financial, legal or other professional advice. For more information, see our Terms of Use and Risk Warning.