Why do cross-chain bridges have so many low-level accidents?

foreword

The recent frequent cross-chain security issues have attracted widespread attention from the market. This article hopes to start from the perspective of product design and tell readers why there are so many product security issues on this track. It should be declared that the problems pointed out in the article do not exist in every project. Most of the problems have already been designed with relevant coping strategies. The purpose of this article is mainly to hope that more people can understand this track. Complexity.

The writing logic of the article is: first explain clearly how general cross-chain bridges are designed, deepen readers’ understanding of cross-chain bridges, and then summarize the security problems that these cross-chain bridges may encounter.

1: The ever-changing cross-chain solution

The previous research report has actually explained several different types of information cross-chain solutions to everyone. No matter what the final presentation is, from the perspective of product design, only side chains (side chains in a broad sense, in the text) Speaking of rollup, it can also be summarized into three mechanisms: side chain, hash time lock, and notary.

(1) Side chain

Among the three schemes, the sidechain scheme has the highest security, such as various rollup and polkadot parachains. Security is shared between the main chain and side chains.

However, the sidechain scheme generally requires the original chain and the target chain to be isomorphic, so there are far fewer applicable scenarios. This is also the reason why Vitalik agrees with multi-chains, but not cross-chains, because there are too many problems with cross-chain solutions that cannot share security.

(2) Hash time lock

This solution claims to be the most decentralized peer-to-peer heterogeneous cross-chain solution, but the cost is high and the waiting time for users is too long, resulting in the current adoption rate is not high. And when we still need a third party to act as an intermediate node for currency exchange, we also need a so-called intermediate consensus layer to meet the requirements of security and decentralization.

(3) Notary mechanism

This is currently the most commonly used heterogeneous cross-chain bridge solution. Most products on the market are basically of the same origin, and there is almost no difference from the perspective of product design. The main differences may focus on the method and steps of information verification, the consensus algorithm of the notary, the signature algorithm of the escrow wallet, etc. There is not much difference in terms of user experience and safety. Therefore, from a security point of view, the security risks faced also have many common features.

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

Two: The product logic process of the notary mechanism

Before understanding the various risks faced by the notary mechanism, we need to understand the design logic of this type of solution from a product point of view.

(1) Brief introduction

This solution is actually very simple from the perspective of design philosophy. When we face the needs of cross-chain heterogeneous assets, the most intuitive solution is actually "mapping". Mapping means when user A transfers ETH from Ethereum to Fantom. We don't need to physically transfer the asset, or reissue it on Fantom (it can't). Instead, first store user A's ETH in an address that cannot be moved, and then issue corresponding 1:1 mapped assets on Fantom according to the amount of user A's ETH stored in this address. Mapped assets represent the right to use those ETHs on the original Ethereum chain. Because of the 1:1 anchor, users on Fantom also recognize the value of this asset.

The most simplified cross-chain process

(2) Difficulties in design

There will be many problems in this, the biggest problem is the management of the multi-signature wallet, because ETH crossing from Ethereum to Fantom is a deposit, and if user A wants to cross back, it will involve the issue of withdrawing coins.

The decentralization and security of deposit and withdrawal has become the biggest difficulty.

1: Who will manage the money?

2: Who will initiate?

3: Who will monitor the transaction?

4: How to confirm that there is indeed a user transferring money in?

5: How to confirm that the user's money is indeed the user himself wants to withdraw?

6: How to prevent replay attacks?

7: How to submit a failed transaction again?

8: What if the multi-signature manager does evil?

9: What should I do if there is a downtime?

I dare not think about it, the more I think about it, the more complicated it feels. The technology of cross-chain bridge not only involves multi-signature, but also involves asset issuance, cross-chain monitoring, asynchronous verification, and even needs to issue an independent intermediate consensus layer (a new chain).

Therefore, in order to further simplify the difficulty for users to understand, I will divide the entire cross-chain process into two parts: deposit and withdrawal. To help you learn more about:

(3) Further refinement of the process

1: Deposit coins

First of all, let me declare that the process drawn in the figure below is just my own deduced design plan without careful argumentation. The purpose is to explore possible security issues in the design logic, and it cannot be adopted as a finalized plan. It's all bullshit.

As shown in the figure: a deposit transaction from the original chain to the target chain will in principle include these steps:

(1) The user recharges to the hosting address

(2) After the listener monitors the transaction, the BP (consensus node is also a multi-signature administrator) initiates the transaction

(3) The contract verifies the correctness of the BP signature

(4) Whether there is a node fault tolerance mechanism

(5) If there is no call back, if there is, recharge the target chain address according to the relationship of the mapped address

(6) BP confirms the recharge transaction

(7) Transfer the mapping token to the user's address on the target chain after passing Byzantium

It should be noted that this process is aimed at discussing general heterogeneous cross-chains, so compared with anyswap and other solutions, it adds a step of allowing users to bind address relationships on the intermediate consensus layer. This is mainly due to the different ways of attaching information to different heterogeneous chain transactions. In order to deal with it uniformly, it is better to let users bind the mapping relationship first.

If you are dealing with transactions on the EVM chain, you don’t need this step, just attach the address of the target chain when initiating the transaction.

Back to the topic: From the above process, we can see that starting from the second step, we will encounter various logic verification problems and processing problems in different situations.

The main verification logic includes:

(1) After listening to the transaction, verify the transaction that initiates asset mapping and transfers to the target chain of user A

(2) Initiation of target chain transactions and verification of transaction results

Of course, in addition to the verification logic drawn in my process, it should also include the verification of counterfeit currency recharge issues, as well as the special processing issues that need to be done when calling different tokens. In order to better summarize the potential safety hazards that may arise in the future, let's continue to understand the process of withdrawing coins.

2: Withdraw coins

The process demonstrated by the coin withdrawal is the logic of exchanging target chain assets back to the original chain assets. It is important to note that many tokens currently have multiple chain versions, which means that many tokens are on multiple chains. Own native tokens. Therefore, some bridge projects often set up asset pools. In the case of a sufficient fund pool, users will not feel the existence of mapped assets such as anyDAI, but directly replace them with tokens of the target chain version, but this does not affect the overall logic. So, the analysis continues:

As shown in the figure: a transaction flow from the target chain to the original chain is as follows:

(1) The user initiates a transaction (transfers the same amount of mapped assets to the escrow wallet on the target chain)

(2) Verify the BP identity, and a BP initiates a withdrawal request

(3) Confirm withdrawal authority and signature

(4) Complete the request to withdraw coins on the original chain after passing Byzantium, and transfer the money from the custody wallet of the original chain to user A

(5) If there is a node verification error or downtime in the middle, it needs to be rolled back and re-initiated

As can be seen from the above process, the main verification logic involved here is:

(1) Verification of initiation and signature authority

(2) Fault tolerance mechanism after the problem occurs

(4) Security risks

1: Security issues in design logic

After a more careful understanding of the design of the cross-chain bridge, we can find that there are many challenges in the design logic of the cross-chain bridge. To summarize, there are three main problems (the relevant stolen cases are marked at the end of the question)

(1) Deposit

a) There is a loophole in the authority of the coin charging contract, which leads to the direct transfer of the charged money. This is a stupid question that almost all contract projects will encounter,

b) The problem of counterfeit currency recharge, some projects have not verified the authenticity of the cross-chain Token, resulting in fakeTOKEN -> realTOKEN (anyswap), to be honest, this is a bit stupid.

c) The issue of counterfeit currency top-up, native assets such as ETH are different from ERC20 contracts, and many attacks are due to improper handling of ETH, resulting in fakeETH -> realETH, which is why wrapped assets such as WETH are popular. (thorchain)

d) Although different Tokens are all ERC20 standards, the specific implementation methods are different, or there are additional logics (rebase, fallback, etc.), the developers did not do a good job of research when adapting, such as (WETH, PERI, OMT , WBNB, MATIC, AVAX), etc. will call the sender’s custom fallback function to do additional operations after the transfer is completed, which increases the complexity of cross-chain bridge judgment (anyswap 2022.1.18)

(2) Cross-chain message transfer

After the a-chain deposit is completed and before the b-chain assets arrive in the account, the cross-chain bridge is handled like an independent blockchain system, which requires a consensus mechanism, generally using dpos, and the following are all assumed to use dpos Issues to be considered, but I suspect that all nodes belong to the project side, and there is a risk of centralization in the first place.

a) To monitor coin deposit messages, who will be the first to initiate a cross-chain processing proposal, randomly? Or take turns? Or in accordance with the order of the blocks produced by the intermediate consensus layer?

b) How do multiple notaries verify the correctness of deposits? If the data sources are all from data providers such as infura, infura is a single point of risk. The safest thing is to maintain their own nodes, which costs a lot.

c) How to confirm that the cross-chain processing is completed (b has been uploaded to the account), and there are several situations in which the processing is not completed:

i. The cross-chain bridge did not initiate processing

ii. The cross-chain bridge initiated processing, but the verification & consensus failed

iii. The verification of the cross-chain bridge is passed, but no transaction is initiated on the b-chain

iv. b There is a transaction on the chain, but it fails (insufficient funds or other circumstances)

(3) Multi-signature verification problem

The hardest hit areas with frequent problems, most of which are code logic problems

a) 3/5 signatures, I randomly construct signatures that are not in the multi-signature list, it is also +1 (chainswap).

b) The problem of centralization, nominally multi-sig, is actually in the hands of the project party, which poses a huge risk of centralization.

c) Signature verification method, the development mode on different chains is different, which will inevitably cause developers to miss when docking, wormhole example: the verification signature function on solana is a function in the system contract, and the system contract should be called normally , the address of the system contract should be hard-coded in the code. Here they pass the system contract address as a parameter. When the hacker withdraws the currency, he passes a fake system contract address, which bypasses the signature verification and withdraws the currency smoothly. .

(4) Refund

a) As discussed in (2)-c, there are many possibilities for cross-chain status. In any case, it is necessary to provide users with a refund method. For example, when anyswap deposits coins, it will first send users anyToken, and then send anyToken to the user on the target chain, and then burn anyToken of the source chain. The purpose of this is that no matter where the problem is, users can represent their own assets by holding anyToken. There are 3 chains (source, target, cross-chain bridge) and 4 assets (original Token/anyToken on the source chain and target chain) in this process, which is very prone to code logic problems.

b) Thorchain’s vulnerability was revealed on July 23, 2021. Hackers used code logic problems to construct a huge amount of fake recharge. The cross-chain bridge could not handle it, so it entered the refund logic, causing the hacker to get a huge refund.

2: Other security risks

But the problems that can be shown through the logical process are only business logic problems, not all of them.

From a security point of view, we should also consider three other risks:

(1) Systemic risk

For example, the deposit of the original chain was successful at the beginning, and then rolled back. This is a huge problem. V God has discussed that assets are transferred from Solana to Ethereum. After the cross-chain is completed, Solana rolls back, and the user’s assets will double. solution.

But layer 2, such as rollup, which shares security with Ethereum, does not have this problem.

(2) Front-end risks

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

b) Xss attack, that is, cross- site scripting attack, is a code injection attack, such as www. Pay attention to prevent xss, this code will be executed on the page, causing the user to authorize the signature of the hacker's transfer transaction, so do not open links from unknown sources.

c) Cors cross-site service attack. Under the strict same-origin policy, browsers are only allowed to load content from this site, that is, all content displayed on the www.xxxx.finance site and the interface called should come from xxxx. Finance domain name, but most of the current projects allow cross-site calls, that is, the xxxx front-end can call the quickswap interface, and vice versa, which brings convenience to development, but also brings risks:

If I visit xxxx.finance, store some sensitive data in the browser cache, and then I visit a malicious website, if the same-origin policy of xxxx is not restricted, this malicious website can freely obtain the data stored in the cache of xxxx .

(3) Risk of additional functions

Some cross-chain bridge projects not only provide assets cross-chain, but also provide cross-chain contract calls, which brings additional complexity.

The attacker initiates a call to the x contract on the b chain on the a chain, and the cross-chain bridge calls it directly regardless of the x contract. Unexpectedly, the x contract is a multi-signed contract of the cross-chain bridge on the b chain. It is to change the multi-signature account to the attacker's own address. After the execution is successful, the hacker can freely control the funds of the cross-chain bridge on the b-chain (poly network).

Three: Conclusion

1: The purpose of this report is to help users have a clearer understanding of the security risks of cross-chain bridges, and it is not malicious rendering of how vulnerable cross-chain bridges are to be attacked.

2: The cross-chain bridge solution of the notary mechanism is the solution with the best experience, the widest scope of application and the lowest cost at least for now. And any product will go through a process from being scarred to mature, and the attacks on blockchain products are often "logical problems." These questions are bound to get better with time and experience.