High-risk areas in the crypto world: What are the common vulnerabilities of cross-chain bridges?

Original Title: 《Cross-chain bridge vulnerability summary》

Original Author: lunaray

Compilation: ChinaDeFi

With the growth of blockchain and on-chain projects, the demand for multi-chain projects is increasing, and the cross-chain bridge business is also on the rise. Where there is business, there will be security issues. While cross-chain bridges provide convenience for users, they also offer convenience for hackers. After the Poly Network was attacked, security issues regarding cross-chain bridges emerged.

What is a cross-chain bridge?

A blockchain bridge, also known as a cross-chain bridge, connects two blockchains and allows users to send cryptocurrencies from one chain to another.

Cross-chain bridges achieve cross-chain operations of funds through token transfers, smart contracts, and data exchanges between two independent platforms.

A common operation of a cross-chain bridge is as follows:

• Users send asset A to a storage address on the original chain and pay a bridging fee;
• Asset A is locked by a randomly selected validator or trusted custodian in the smart contract;
• The same amount of asset A1 is issued on the target chain and sent to the user address on the target chain.

Vulnerabilities in cross-chain bridges

Common vulnerabilities in cross-chain bridges

ChainSwap attack incident:

In July 2021, the cross-chain asset bridge project ChainSwap was attacked. More than twenty projects on the cross-chain bridge were affected, resulting in nearly $8 million in asset losses and causing over ten projects to plummet by 99%.

This attack was primarily due to the protocol's failure to strictly check the validity of signatures, allowing attackers to sign transactions with signatures they generated themselves.

Factory contract

The main function of the receive method in the above image is to transfer the user's cross-chain funds to the user address on the target chain, requiring verification of the sending chain's signature. The current number of signatures to be verified is 1.

Due to the logic of the receive method and the methods named ecrecover and _decreaseAuthQuota not strictly checking signatures, the attacker used their generated signature, but the subsequent contract logic did not strictly check the mapping value signature and other calculations. This allowed the attacker to successfully execute the receive method and transfer funds to themselves.

Poly Network attack incident

In August 2021, the cross-chain interoperability protocol Poly Network was suddenly attacked by hackers. O3 Swap, which used the protocol, suffered severe losses. Assets on the Ethereum, Binance Smart Chain, and Polygon networks were almost completely drained. Within one hour, $250 million, $270 million, and $85 million worth of crypto assets were stolen, totaling losses of up to $610 million.

This attack was primarily caused by the replacement of the relay chain validator's public key. The attacker replaced the intermediate validator of the cross-chain with one they controlled.

Internal relationships of the protocol:

• The public key of the relay chain validator exists in the EthCrossChainData contract;
• The owner of the EthCrossChainData contract is the EthCrossChainManager contract;
• The putCurEpochConPubKeyBytes method of the EthCrossChainData contract can modify the relay chain validator role.
• EthCrossChainManager contract:

In the above image, the _executeCrossChainTx method does not impose strict restrictions on the incoming parameters, allowing the attacker to control the toContract method parameter. Due to the internal relationships of the protocol, after a hash collision, the attacker passed in the same method signature as the putCurEpochConPubKeyBytes method. This successfully called the putCurEpochConPubKeyBytes method of the EthCrossChainData contract, directly modifying the relay chain validator's public key to make it controllable, and then used the validator to sign malicious transactions to transfer funds, obtaining a large amount of money.

Multichain (AnySwap) attack incident

In January 2022, Multichain officially announced that the cross-chain bridge of the protocol had security risks, and some tokens were at risk of being attacked by hackers, urging users to revoke authorizations as soon as possible.

The core reason for the incident was that the underlying token contract called by the protocol did not implement the permit method but contained a fallback function, allowing the permit method to operate normally.

On the left is the AnyswapV4Router contract, and on the right is the WETH9 contract.

In the AnySwapOutUnderlyingWithPermit method in the above image, the first three parameters are all passed in by the caller, meaning that the tokens and other parameters are controlled by the attacker. When the parameters are controllable, the attacker deploys an attack contract to transfer the affected tokens. The contract address is set as the base token parameter.

The core issue is that WETH9 does not have a permit method, but it will call WETH9's fallback method for recharge operations, so there will be no erroneous calls (the transaction will not roll back), meaning that when the user authorizes the protocol, the attacker can quickly transfer the user's funds.

Qubit Bridge attack incident

In January 2022, the Qubit Finance cross-chain bridge between Ethereum and Binance was hacked, resulting in losses of over $80 million.

Core issue: When the fund address in the deposit method is address(0), it does not trigger a safeTransferFrom error, allowing the deposit function to execute normally.

QBridge contract

In the above image, the deposit is a normal deposit method. When calling IQBridgeHandler(handler).deposit in this method, if the resourceID passed in by the user maps to a tokenAddress of 0, the subsequent tokenAddress.safeTransferFrom(depositer, address(this), amount); transfer will execute normally, leading to the normal operation of the method and event, allowing the caller to successfully make a deposit.

More importantly, the official tokenAddress's ETH 0 address is made by the official (the official has declared that the deposit function is an ignored deprecated feature).

Meter Bridge attack analysis

In February 2022, the Meter.io cross-chain protocol did not prevent the direct interaction between wrapped ERC20 tokens and native gas tokens, resulting in losses of approximately $4.3 million.

The core issue of the event is that the deposit method does not verify the deposit status of WBNB when making a deposit, allowing attackers to bypass the judgment condition and obtain funds without making a deposit.

Bridge contract

In the above image, both the deposit and depositETH methods are deposit methods, but when depositing with the deposit method, there is no verification of whether the deposit is a native token. When the attacker makes a deposit, they pass in the WBNB address. This method does not verify the WBNB deposit, and then calls depositHandler.deposit to successfully bypass the judgment condition. Finally, the attacker successfully obtains a large amount of funds by exploiting this vulnerability.

Wormhole attack analysis

In February 2022, the important bridge (Wormhole) between Ethereum and Solana was attacked by hackers, resulting in losses of over $320 million.

The core reason for this vulnerability is that the loadinstructionat method called by verify_signatures does not validate the validity of the instructions, allowing attackers to forge verification signatures to obtain funds.

verify_signature.rs interface contract

In the above image, the verifysignatures method is the signature method called during the cross-chain verification process. Since the verifysignatures method calls the loadinstructionat method, after the protocol update, the loadinstructionat method is a deprecated method. This method does not strictly check the incoming instructions, which allows attackers to pass in a controllable value and use this signature method to sign their cross-chain requests, obtaining a large amount of funds.

Li.Finance attack analysis

In March 2022, the distributed cross-chain protocol Li.Finance on Ethereum was attacked. The attacker made 37 calls and obtained approximately $600,000 in assets (204 ETH) across multiple wallets.

The core issue of this attack is the lack of strict restrictions on incoming external data, allowing attackers to pass in their controllable calling logic.

CBridgeFacet contract

In the swapAndStartBridgeTokensViaCBridge method in the above image, the passed _swapData parameter is not strictly restricted. In the same LibSwap.swap call, this value is not strictly limited. Therefore, in the swap method, _swapData can successfully call the call method to execute malicious operations. The attacker exploited this vulnerability to make multiple calls to obtain funds.

Ronin Network attack analysis

In March 2022, the validator nodes of the Axie Infinity sidechain Ronin and the Axie DAO validator nodes were compromised, leading to the bridging of 173,600 ETH and $25.5 million USDC in two transactions.

Attack reasons:

Sky Mavis's Ronin chain currently consists of 9 validators. To identify deposit or withdrawal events, signatures from 5 of the 9 validators are required. The attacker controlled four of Sky Mavis's Ronin validators and a third-party validator operated by Axie DAO. (From November to December 2021, Axie DAO allowed Sky Mavis to sign various transactions on its behalf, and after the event stopped, the whitelist access was not revoked, allowing the attacker to gain access to the Sky Mavis system and use gasless RPC from the Axie DAO validator to obtain signatures).

Summary and recommendations

From the above cross-chain bridge attack incidents, it can be seen that several cross-chain bridge attacks have occurred from last year to this year. The number of cross-chain bridge attacks is significantly increasing, and the amount of stolen funds is considerable. Hackers have set their sights on the lucrative cross-chain bridge space. In summary, attacks mainly occur before cross-chain operations and at the signature stage, generally due to contract vulnerabilities, and there are also theft incidents caused by official negligence. Regarding the increasing number of cross-chain projects and the security of project contracts, the following recommendations are made:

• Complete contract security audits before project launch
• Strictly check the compatibility of contract calling interfaces
• Reassess the security of relevant interfaces and signatures during version updates
• Conduct strict reviews of cross-chain signers to ensure that signatures are not controlled by malicious actors