Why do cross-chain bridges become hotspots for incidents?

Original Title: 《Why Are There So Many Incidents with Cross-Chain Bridges?》

Original Author: 0xScope Team

Introduction

The recent frequent cross-chain security issues have attracted widespread attention in the market. This article aims to explain to readers why there are so many product security issues in this sector from the perspective of product design. It should be noted that the problems pointed out in this article do not exist in every project; most issues already have corresponding countermeasures in place during the design phase. The main purpose of this article is to help more people understand the complexity of this sector.

The writing logic of this article is as follows: first, clarify how general cross-chain bridges are designed to deepen readers' understanding of cross-chain bridges, and then summarize the security issues that these cross-chain bridges may encounter.

I: The Unchanging Nature of Cross-Chain Solutions

Previous research reports have already explained several different types of information cross-chain solutions. Regardless of the final presentation, from a product design perspective, there are only three mechanisms: sidechains (broadly defined, including rollups as sidechains in this article, so please don’t argue), hash time locking, and notary mechanisms.

(1) Sidechains

Among these three solutions, the sidechain solution has the highest security, such as various rollups and Polkadot's parachains. The main chain and sidechains share security.

However, the sidechain solution generally requires the original chain and the target chain to be isomorphic, which significantly reduces the applicable scenarios. This is also why Vitalik Buterin supports multi-chain but does not recognize cross-chain solutions, as cross-chain solutions that cannot share security have too many problems.

(2) Hash Time Locking

This solution claims to be the most decentralized heterogeneous cross-chain solution in a peer-to-peer manner, but it has high costs and long user wait times, resulting in low adoption rates. Moreover, when we still need a third party to act as an intermediary for currency exchange, we also need a so-called intermediate consensus layer to meet the requirements for security and decentralization.

(3) Notary Mechanism

This is currently the most commonly used heterogeneous cross-chain bridge solution, and most products in the market are fundamentally the same. From a product design perspective, there is almost no difference. The main differences may focus on the methods and steps of information verification, the consensus algorithms of notaries, the signature algorithms of custodial wallets, etc. Therefore, the differences in user experience and security are also minimal. Thus, from a security perspective, the security risks faced are also quite common.

This article will focus on summarizing and analyzing some common security risks faced by cross-chain bridges using the notary mechanism.

II: Product Logic Flow of the Notary Mechanism

Before understanding the various risks faced by the notary mechanism, we first need to understand what the design logic of this type of solution looks like from a product perspective.

(1) Overview

From the perspective of design philosophy, this solution is actually very simple. When we face the demand for heterogeneous asset cross-chain, the most intuitive solution is "mapping." Mapping means that when user A transfers ETH from Ethereum to Fantom, we do not need to actually transfer the asset or reissue it on Fantom (which is also not feasible). Instead, we first deposit user A's ETH into an immovable address, and then based on the amount of ETH user A has in that address, we issue a corresponding 1:1 mapped asset on Fantom. The mapped asset represents the usage rights of those ETH on the Ethereum original chain. Because of the 1:1 anchoring, users on Fantom also recognize the value of this asset.

Simplified Cross-Chain Process

(2) Design Challenges

There are many issues involved, the biggest of which is the management of multi-signature wallets. Since ETH is being deposited from Ethereum to Fantom, it involves the issue of deposits, and if user A wants to transfer back, it will involve the issue of withdrawals.

The decentralization and security of deposits and withdrawals become the biggest challenges.

1: Who manages the funds?

2: Who initiates the process?

3: Who monitors the transactions?

4: How do we confirm that a user has indeed transferred funds?

5: How do we confirm that the user's funds are indeed intended for withdrawal by the user?

6: How do we prevent replay attacks?

7: How do we resubmit failed transactions?

8: What if the multi-signature managers act maliciously?

9: What if there is a system failure?

It's daunting; the more you think about it, the more complex it feels. The technology behind cross-chain bridges involves not only multi-signatures but also asset issuance, cross-chain monitoring, asynchronous verification, and even the need to issue an independent intermediate consensus layer (a new chain).

To further simplify the understanding for users, I will divide the entire cross-chain process into two parts: deposits and withdrawals. This will help everyone gain a deeper understanding:

(3) Further Refinement of the Process

1: Deposits

First, I would like to clarify that the process illustrated in the diagram below is merely a design scheme I derived through reasoning and has not been rigorously validated. The purpose is to explore potential security issues that may arise in the design logic and should not be adopted as a finalized scheme; it is all speculative.

As shown in the diagram, a deposit transaction from the original chain to the target chain would generally include the following steps:

(1) User deposits into a custodial address.

(2) After the listener detects this transaction, a BP (consensus node and also multi-signature administrator) initiates the transaction.

(3) The contract verifies the correctness of the BP's signature.

(4) Is there fault tolerance through the node mechanism?

(5) If not, it is returned; if so, funds are deposited into the target chain address based on the mapping address relationship.

(6) BP confirms this deposit transaction.

(7) After Byzantine agreement, the mapped tokens are transferred to the user's address on the target chain.

It is important to note that this process aims to discuss general heterogeneous cross-chain scenarios, so compared to solutions like anyswap, it adds a step for users to bind address relationships on the intermediate consensus layer. This is mainly because different heterogeneous chains have different ways of carrying transaction information, so to unify processing, it is better to have users bind the mapping relationship first.

If all transactions are on EVM chains, this step is unnecessary; the target chain address can be directly included when initiating the transaction.

Back to the main topic: from the above process, we can see that starting from the second step, various logical verification issues and handling problems arise.

The main verification logic includes:

(1) Verifying the asset mapping and the transaction to user A on the target chain after the transaction is detected.

(2) Initiating the transaction on the target chain and verifying the transaction results.

Of course, in addition to the verification logic illustrated in my process, it should also include checks for fake token deposits and special handling issues required when calling different tokens.

To better summarize potential security risks that may arise later, let's continue to understand the withdrawal process.

2: Withdrawals

The withdrawal process demonstrates the logic of exchanging mapped assets on the target chain back to original chain assets. It is important to note that many tokens have been found to have multiple chain versions, meaning that many tokens have native tokens on multiple chains. Therefore, some bridge projects often set up asset pools. When the liquidity pool is sufficient, users do not feel the existence of mapped assets like anyDAI but directly exchange for the target chain version of the token, which does not affect the overall logic. So, the analysis continues:

As shown in the diagram, the transaction process for withdrawing from the target chain back to the original chain is as follows:

(1) User initiates the transaction (transfers an equivalent amount of mapped assets to the custodial wallet on the target chain).

(2) Verifies the BP's identity, and a certain BP initiates the withdrawal request.

(3) Confirms withdrawal permissions and signatures.

(4) After Byzantine agreement, completes the request to withdraw on the original chain, transferring funds from the original chain's custodial wallet to user A.

(5) If there are issues such as node verification errors or system failures in between, it must roll back and re-initiate.

From the above process, we can see that the main verification logic involved includes:

(1) Verification of initiation and signature permissions.

(2) Fault tolerance mechanisms in case of issues.

(4) Security Risks

1: Security Issues in Design Logic

After carefully understanding the design of cross-chain bridges, we can see that there are many challenges faced in the design logic. To summarize, there are mainly three aspects of issues (related theft cases are noted at the end of each issue):

(1) Deposits

a) Vulnerabilities in deposit contract permissions, leading to funds being directly transferred away. This is a foolish problem that almost all contract projects encounter.

b) Issues with fake token deposits; some projects do not verify the authenticity of cross-chain tokens, leading to fakeTOKEN -> realTOKEN (anyswap). To be honest, this is also somewhat foolish.

c) Issues with fake token deposits; native assets like ETH differ from ERC20 contracts, and many attacks arise from improper handling of ETH, leading to fakeETH -> realETH. This is also why wrapped assets like WETH are popular (thorchain).

d) Although different tokens are all ERC20 standards, their specific implementations may differ, or there may be additional logic (rebase, fallback, etc.). Developers may not conduct adequate research during adaptation, leading to increased complexity in cross-chain bridge judgments, as seen with (WETH, PERI, OMT, WBNB, MATIC, AVAX) where additional operations are performed by calling the sender's custom fallback function after the transfer is completed (anyswap 2022.1.18).

(2) Cross-Chain Message Transfer

After the deposit on chain A is completed and before the assets arrive on chain B, the handling of the cross-chain bridge resembles an independent blockchain system, requiring a consensus mechanism, typically using DPOS. The following are issues that need to be considered under the assumption of using DPOS, but I suspect that all nodes are controlled by the project party, which inherently carries centralization risks.

a) Who initiates the cross-chain processing proposal first after detecting the deposit message? Randomly? Alternately? Or according to the block order of the intermediate consensus layer?

b) How do multiple notaries verify the correctness of the deposit? If the data sources are all from providers like Infura, then Infura becomes a single point of risk. The most reliable method is for each to maintain their own nodes, which incurs significant costs.

c) How do we confirm that the cross-chain processing is complete (the assets have arrived on B)? There are several scenarios where it may not be processed:

i. The cross-chain bridge did not initiate processing.

ii. The cross-chain bridge initiated processing, but verification & consensus did not pass.

iii. The cross-chain bridge verified successfully but did not initiate a transaction on chain B.

iv. There is a transaction on chain B, but it failed (due to insufficient funds or other reasons).

(3) Multi-Signature Verification Issues

This is a hotspot for frequent problems, mostly due to code logic issues.

a) 3/5 signatures; I can randomly construct a signature not in the multi-signature list, and it still counts as +1 (chainswap).

b) Centralization issues; nominally multi-signature, but actually controlled by the project party, posing significant centralization risks.

c) Signature verification methods; different development models on different chains lead to inevitable omissions during integration. For example, in the wormhole case: the verification signature function on Solana is a function within the system contract. Normally, it should call the system contract, and the address of the system contract should be hardcoded in the code. However, they treated the system contract address as a parameter, allowing the hacker to bypass verification by providing a fake system contract address during withdrawal and successfully withdraw the funds.

(4) Refunds

a) As discussed in (2)-c, there are many possible states for cross-chain transactions. In any case, users need to be provided with a refund method. For example, anyswap first issues anyToken to users on the source chain during deposits, then issues anyToken to users on the target chain, and finally burns the source chain's anyToken. This ensures that regardless of where the issue arises, users can represent their held assets through anyToken. This process involves three chains (source, target, cross-chain bridge) and four assets (original tokens/anyToken on both the source and target chains), making it very easy for code logic issues to arise.

b) The vulnerability exposed by Thorchain on July 23, 2021, where hackers exploited a code logic issue to construct a massive fake deposit, which the cross-chain bridge could not process, leading to the refund logic being triggered and hackers receiving a huge refund.

2: Other Security Risks

However, the issues that can be displayed through logical processes are only business logic problems and not exhaustive.

From a security perspective, we should also consider three additional aspects of risk:

(1) Systemic Risks

For example, if the deposit on the original chain is initially successful but later rolled back, this poses a significant problem. Vitalik has discussed that if assets are transferred from Solana to Ethereum and the cross-chain is completed but Solana rolls back, the user's assets double, with no solution available.

However, layer 2 solutions like rollups that share security with Ethereum would not face such issues.

(2) Front-End Risks

a) Fake URLs, such as oxdao.fi, 0xdao.fi, oxdai.fi, etc.

b) XSS attacks, or cross-site scripting attacks, are a type of code injection attack. For example, www.xxxx.finance/?params=hackerscode12345; although the URL is indeed the official site, it carries the hacker's code. If front-end developers do not take precautions against XSS, this code will execute on the page, leading users to authorize transactions to hackers. Therefore, do not open links from unknown sources.

c) CORS cross-site service attacks; under strict same-origin policies, browsers only allow loading content from the same site. That is, all content displayed on www.xxxx.finance and all APIs called should come from the xxxx.finance domain. However, currently, the vast majority of projects allow cross-site calls, meaning that the xxxx front end can call quickswap's API and vice versa. While this brings convenience to development, it also introduces risks:

If I visit xxxx.finance and store some sensitive data in the browser cache, then visit a malicious site, if xxxx's same-origin policy is not restricted, that malicious site can freely access the data cached in xxxx.

(3) Risks from Additional Features
Some cross-chain bridge projects not only provide asset cross-chain but also offer cross-chain contract calls, which adds extra complexity.

An attacker initiates a call to contract x on chain B from chain A. The cross-chain bridge directly calls contract x without knowing what it is, only to find out that contract x is the multi-signature contract of the cross-chain bridge on chain B. This call changes the multi-signature account to the attacker's address. Once executed successfully, the hacker can freely control the funds of the cross-chain bridge on chain B (poly network).

III: Conclusion

1: The purpose of this report is to help users clearly understand the security risks associated with cross-chain bridges, not to maliciously portray cross-chain bridges as being easily susceptible to attacks.

2: The notary mechanism cross-chain bridge solution is currently the best experience, the most widely applicable, and the lowest cost solution. Moreover, any product will go through a process from being riddled with issues to maturity. The attacks faced by blockchain products are often "logical problems." These issues will certainly improve over time with increased experience.