The growth of new blockchains has created additional complexity and risk in the crypto ecosystem. Cross-chain bridges are new attack vectors with inherent security limits that users and project teams should be aware of.

In 2022 alone, three major attacks have already occurred on cross-chain bridges. 

To better understand these incidents, we need to know what a bridge is and how it works. In short, a bridge moves assets from one blockchain to another. A cross-chain transaction can work as follows:

1. A user "deposits" tokens into a "bridge contract" on one chain and generates a proof specifying the required cross-chain information (e.g., the number of tokens to be withdrawn and the recipient address).
2. The bridge verifies the proof and, on the target chain, the user can “withdraw” the tokens from the bridge contract.

In the three recent incidents, attackers injected spoofed data, bypassed the verification, and withdrew the corresponding tokens on the target chain to a specified address.

Common attack vector on Bridges

Qubit Bridge Exploit

The attacker bypassed the verification process by evading the bridge contract, essentially providing proof of non-existent tokens to the bridge. This allowed the attacker direct access to the bridge's funds without inputting any real cryptocurrency.

The root cause of this stems from the fact that deposits of ETH and ERC-20 share the same proof of event. This allows the attacker to call the function to deposit ERC20 with malicious data that can generate proof to withdraw ETH on the other chain.  In this case, it triggered the vulnerability in the contract that the “safeTransferFrom” function does not revert when the token address is an EOA (i.e., address(0)). Therefore, the attacker gets the proof without sending any tokens to the contract.

Detailed analysis can be found here.

Meter.io Bridge Exploit

This exploit is quite similar to the Qubit Bridge Exploit. The attacker evaded the bridge and generated proof that allowed them to withdraw tokens on another chain.

The Bridge contract also provides two methods: deposit() to deposit ERC20 and depositETH() to deposit ETH, and emitting the same event. Because deposit() does not burn or lock WETH/WBNB, the hacker created fake deposit events by implementing deposit() to deposit WETH/WBNB without any legitimate deposits.

Detailed analysis can be found here.

Wormhole Bridge Exploit

On Solana, the attacker bypassed the “verify signature” process by injecting a malicious “sysvar account” to the instruction and forged a message to mint Wormhole-wrapped Ether.

The root cause is that in the “verify signature” process, the contract used an outdated function that does not verify the correctness of “sysvar account”. In this case, the attacker had the opportunity to inject the malicious “sysvar account” and bypass the verification.

Detailed analysis can be found here.

In conclusion, the above three attacks all resulted from a defect in the verification process. For the Qubit and Meter.io bridges, their code failed to handle edge cases. Namely, the function to deposit ERC20 can be used to generate proof that allows the withdrawal of ETH at the target chain. For the Wormhole bridge, the contract failed to verify the “sysvar account” input injected by the caller. 

Some key lessons learned from these attacks:

1. Separate the operation for depositing ETH with ERC20 by handling these cases differently.
2. Always remember to verify the user-injected inputs.
3. Keep an eye on recent exploits and check if the vulnerability exists in other projects.
4. Core contracts from each bridge need to be audited.

Recommendations if a bridge exploit occurs: 

1. Stop relaying messages to pause any further token transfers across the network. For bridge contracts, pause the function to deposit and withdraw tokens. 
2. Immediately inform communities, exchanges, and platform partners to monitor the flow of funds.
3. Set up one communication channel and invite respected security experts to have effective discussions and information sharing.
4. Identify, verify, and fix the vulnerability. Test to ensure the existing vulnerability is resolved and that no new vulnerability is introduced. Upgrade bridge contracts.
5. Assess the damage and communicate transparently with your community about the amount exploited, assets that are recoverable/recovered, and any compensation programs to be set up.