With the development of blockchain technology and the emergence of various new growths, the cryptocurrency ecosystem has created more security risks and complexities.

For details of the attack panorama in 2021, see [2021 DeFi Industry Security Report], welcome to click "Read the original text" at the bottom of the article to get the link to download the security report.

On the basis of 2021, another "powerful player" appeared on the attack track in 2022.

As a new attack vector, the cross-chain bridge has not yet matured in terms of security. Therefore, the cross-chain bridge is also one of the areas where all projects and developers should be vigilant.

Before the Spring Festival holiday in 2022 is over, two major attacks occurred on the cross-chain bridge. Including another similar incident before the Spring Festival, the three attacks in just 10 days made the hackers "proud" in the cross-chain bridge. people" achievement.

Before understanding these incidents, we need to know what a cross-chain bridge is and how it works.

first level title

Cross-chain transaction

The steps of cross-chain transaction are as follows:

1. The user "deposits" tokens into a "bridge contract" on one chain, and generates a proof specifying the required cross-chain information (e.g., the amount of tokens to withdraw and the recipient's address).

2. The bridge contract verifies the proof, then on the target chain the user can"Token."Token.

image description

first level title

Qubit Bridge Vulnerability Incident

The attacker forged data to bypass the data authenticity check of the bridge contract, and made the bridge contract generate a false time certificate that the attacker has deposited without providing any encryption currency.

The fundamental reason for this is that ETH and ERC-20 deposits share the same proof of event. This allows an attacker to call this function to generate a false ETH deposit event proof using the non-existent ERC20 deposit fact, and withdraw ETH on another chain.

In this case a bug in the contract is triggered - the "safeTransferFrom" function does not fallback when the token address is EOA (eg address(0)). Thus, the attacker obtained the proof without sending any tokens to the contract.

first level title

Meter Bridge Vulnerability Incident

The vulnerability is very similar to the Qubit bridge vulnerability - the attacker bypasses the bridge contract and provides proof of non-existing tokens to the bridge to skip the verification process, so that tokens can be withdrawn on another chain.

The Bridge contract provides two methods: deposit and depositETH. However, these two methods produce the same proof of deposit event, and the deposit function does not prevent the deposit transaction of WETH/WBNB, nor destroy or lock WETH/WBNB.

The hacker used deposit to make the bridge contract generate a false WETH/WBNB deposit event certificate without any real deposit.

For details of the event analysis, please refer to the CertiK public account【first level title】。

Solana cross-chain bridge wormhole event

In the Solana wormhole vulnerability incident, the attacker bypassed the "verify signature" by injecting a malicious "sysvar account" into the command, and forged a message to mint Wormhole-wrapped Ether.

The root cause of this vulnerability is that in the process of verifying signatures ("verify_signatures"), the program uses a "load_current_index" function that was deprecated when Solana was updated to 1.8.0. This function will not verify whether the input "sysvar account" is really "system sysvar", so the attacker can take the opportunity to forge this critical account.

Afterwards, the attacker used this fake account to generate false coinage information, and then extracted the corresponding real tokens on the target chain based on the obtained mintage information.

For details of the event analysis, please refer to the CertiK public account【first level title】。

Summary of Three "Bridge Bombing Cases"

The bridge code of Qubit and Meter.io failed to handle the critical situation, that is, the ERC20 deposit function of the contract can be used to generate a fake ETH/BNB deposit event certificate, and the latter becomes the proof of withdrawing the real ETH/BNB on the target chain .

Wormhole bridge is the "sysvar account" injected by its contract unverified caller, thus generating false minting information.

first level title

How to deal with such vulnerabilities?

There are some key lessons we can learn from the above attacks:

1. For different functions, such as ERC20 deposit and ETH/BNB deposit, the contract should generate different event proofs.

2. Always remember to validate user injected input.

3. Pay close attention to recent vulnerability incidents and check whether similar situations exist in other projects.

4. The core contract of each bridge needs to be audited accordingly.

In addition, when the vulnerability occurs, we should:

1. Stop the relay message layer and suspend token transfer, and the bridge contract should also suspend all deposit and withdrawal functions.

2. Immediately notify the community, exchanges, and platform partners to monitor the flow of funds.

3. Establish communication channels with authoritative security experts for effective discussion and information sharing.

4. Identify, verify, and fix vulnerabilities. Test in time to ensure that existing vulnerabilities are resolved and no new vulnerabilities are created, and the bridge contract is upgraded at the same time.

5. Assess the damage and communicate candidly with the community about the number of assets exploited, assets that can be recovered, and compensation plans