This article is a post from the community. The author is Minzhi He, an 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.
Summary
Blockchain bridges are important in achieving interoperability in the blockchain field. Therefore, bridge security is very important. Some common security vulnerabilities of bridges include weak on-chain and off-chain validation, improper handling of native tokens, and misconfiguration. Testing the bridge against all possible attack vectors is recommended to ensure reasonable verification logic.
Introduction
Bridge blockchain is a protocol that connects two blockchains to allow interaction between them. If you own bitcoins but want to participate in DeFi activities on the Ethereum network, blockchain bridges allow you to do so without selling bitcoins.
Blockchain bridges are essential to achieve interoperability in the blockchain field. This bridge functions using various on-chain and off-chain validations, so it has various security vulnerabilities.
Why is Bridge Security Important?
Bridges usually store tokens that users want to transfer from one chain to another. Bridges are often implemented as smart contracts and store large amounts of tokens as cross-chain transfers accumulate, making them tempting targets for hackers.
In addition, blockchain bridges have a large attack gap because they involve many components. Therefore, criminals are highly motivated to target cross-chain applications to drain large amounts of funds.
Bridge attacks have caused losses of more than 1.3 billion USD in 2022 which is 36% of the total losses for that year according to CertiK estimates.
Common Security Vulnerabilities of Bridges
To improve bridge security, it is important to understand common security vulnerabilities of bridges and test bridges before launch. These vulnerabilities can be categorized into four areas.
Weak on-chain validation
For simple bridges, especially those designed for specific DApps, on-chain validation is minimal. The bridge relies on a centralized backend to execute basic operations such as minting, burning, and token transfer while all verification is done off-chain.
In contrast, other types of bridges use smart contracts to validate messages and carry out on-chain verification. In this situation, when a user deposits funds into a chain, the smart contract will generate a signed message and return the signature in the transaction. This signature serves as proof of deposit and is used to verify user requests on other chains. This process should prevent various security attacks, including replay attacks and fake deposit records.
However, if a vulnerability exists during the on-chain validation process, an attacker could cause severe damage. For example, if a bridge uses a Merkle tree to validate transaction records, an attacker could generate false evidence. This means they can bypass proof validation and mint new tokens to their account if the validation process is vulnerable.
Some bridges implement the “wrapped token” concept. For example, when a user transfers DAI from Ethereum to BNB Chain, his DAI is taken from the Ethereum contract, and an equivalent amount of wrapped DAI is issued to BNB Chain.
However, if these transactions are not properly validated, an attacker can implement a malicious contract to route wrapped tokens from the bridge to the wrong address by manipulating its functionality.
The attacker also requires the victim to agree to the bridge contract in order to transfer tokens using the “transferFrom” function to drain assets from the bridge contract.
Unfortunately, this gets worse as most bridges require unlimited token approval from DApp users. This is a common practice that lowers gas fees, but introduces additional risk by allowing smart contracts to access tokens from an unlimited number of user wallets. Attackers can exploit the lack of validation and excessive approval to transfer tokens from other users to themselves.
Weak off-chain validation
In some bridge systems, off-chain backend servers play an important role in verifying the validity of messages sent from the blockchain. In this case, we focus on verifying deposit transactions.
The way a blockchain bridge works with off-chain validation is as follows:
Users interact with the DApp to deposit tokens into smart contracts on the source chain.
Then, the DApp sends the hash of the deposit transaction to the backend server via an API.
Transaction hashes require some validation by the server. If deemed valid, the signer signs the message, then sends the signature back to the user interface via the API.
After receiving the signature, the DApp verifies it, then allows the user to withdraw tokens from the target chain.
The backend server must ensure that the deposit transaction processed actually occurred and was not faked. This backend server determines whether users can withdraw tokens on the target chain, making it a high-value target for attackers.
The backend server must validate the event structure resulting from the transaction as well as the address of the contract that generated the event. If the contract address is ignored, then an attacker can implement a malicious contract to fake a deposit event using the same structure as a legitimate deposit event.
If it doesn't verify the address that generated the event, the backend server can assume this contract is valid and sign the message. Then, the attacker can send the transaction hash to the backend thereby bypassing verification and allowing them to withdraw tokens from the target chain.
Improper handling of native tokens
Bridge takes a variety of approaches to handling native tokens and utility tokens. For example, on the Ethereum network, the native token is ETH and most utility tokens follow the ERC-20 standard.
When a user intends to transfer his ETH to another chain, he must deposit it into the bridge contract first. To achieve this, users simply attach ETH to a transaction, and then 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 ERC-20 tokens, users must first allow the bridge contract to use their tokens. Once he agrees and deposits the tokens into the bridge 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 them is to use if-else statements 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 loss of funds.
When handling an ERC-20 deposit request, users typically provide a token address as input to the deposit function. This action poses significant risks, as untrusted external calls can occur during transactions. Implementing a whitelist that only includes bridge-backed tokens is a common practice to minimize risk. Only whitelisted addresses are allowed to be passed as arguments. This prevents external calls, because the project team already filters token addresses.
However, problems also arise when the bridge handles cross-chain transfers of native tokens, because native tokens do not have addresses. Address zero (0x000...0) represents the original token. This can be problematic, because passing a null address to a function can bypass whitelist verification even if implemented incorrectly.
When the bridge contract calls “transferFrom” to transfer user assets to the contract, the external call to address zero returns false because no “transferFrom” function is implemented in address zero. However, transactions can still occur if the contract cannot handle the resulting value correctly. This creates an opportunity for attackers to execute transactions without transferring tokens to the contract.
Configuration error
In most blockchain bridges, a privileged position is responsible for whitelisting or blacklisting tokens and addresses, assigning or changing signers, and other important configurations. Ensuring that all configurations are accurate is critical, as even seemingly trivial errors can cause major losses.
In fact, in one incident, an attacker managed to bypass transfer record verification due to a configuration error. The project team implemented a protocol upgrade several days before the hack that included changing a variable. The variable is used to represent the default value of trusted messages. This change causes all messages to be deemed automatically proven, allowing attackers to send messages at will and bypass the verification process.
How to Improve Bridge Security
The four common vulnerabilities of bridges described above demonstrate the challenges in ensuring security in an interconnected blockchain ecosystem. There are significant considerations regarding addressing each of these vulnerabilities. There is no single guideline that applies to everything.
For example, providing general guidelines to ensure an error-free verification process is difficult, as each bridge has unique 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 makes sense.
In summary, it is important to conduct rigorous testing for potential attacks and pay special attention to common security vulnerabilities in bridges.
Closing
Due to their high value, cross-chain bridges have long been a target for attackers. Builders can strengthen bridge security by conducting thorough testing before implementation and conducting third-party audits to reduce the risk of costly hacks that have plagued bridges over the past few years. Bridges are essential in a multi-chain world, but security must be a primary concern when designing and building an effective Web3 infrastructure.
Further Reading
What is Bridge Blockchain?
What Is Cross-Chain Interoperability?
Three Popular Crypto 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. This content should not be construed as financial, legal, or other professional advice nor is it intended to recommend the purchase of any particular product or service. You should seek advice from appropriate professional advisors. If the article is a contribution from a third party contributor, please note that the views expressed are those of the third party contributor and do not necessarily reflect the views of Binance Academy. Please read our full disclaimer here for further details. Digital asset prices can be volatile. The value of your investment may fall or rise. You may not get back the amount invested. You are fully responsible for your investment decisions. Binance Academy is not responsible for any losses you may experience. This material should not be considered financial, legal, or other professional advice. For more information, read our Terms of Use and Risk Warning.
