Partnered With:

Why do chain Bridges have so many low-level accidents?

Read this article in 25 Minutes

The cross-chain scheme and complex design ideas make cross-chain Bridges have security risks.

Original title: Why do Chain Bridges have so many accidents?

Original author: 0xScope team

preface

Recently, frequent cross-chain safety problems have attracted wide attention from the market. This paper hopes to start from the perspective of product design and tell readers why there are so many product safety problems in this circuit. It should be noted that the problems pointed out in this article do not exist in every project. Most of the problems have been designed with relevant countermeasures. The main purpose of this paper is to hope that more people can understand the complexity of this track.

The writing logic of this article is: first, explain clearly how the common cross-chain Bridges are designed, deepen the readers' understanding of cross-chain Bridges, and then summarize the safety problems that these cross-chain Bridges may encounter.

A: all changes from its cross-chain solution

In fact, previous research reports have explained several different types of information cross-chain schemes. No matter what the final presentation is, from the perspective of product design, there are only three mechanisms: side chain (in the broad sense, side chain; rollup is also summarized as side chain and other bars), hash time locking and notary public.

(1) Side chain

Among the three schemes, the side chain scheme has the highest security, such as various parallel chains of Rollup and Polkadot. Security is shared between the backbone and side chains.

However, the side chain scheme generally requires the original chain to be isomorphic to the target chain, so it can be applied to far fewer scenarios. This is also why V God believes that multi-chain, but not cross-chain, because there are too many problems in cross-chain schemes that cannot share security.

(2) Hash time lock

This solution is claimed to be the most decentralized heterogeneous cross-chain solution from point to point, but the high cost and long waiting time of users have led to low adoption rate. And while 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 public mechanism

This is the most commonly used heterogeneous cross-chain bridge scheme at present. Most of the products in the market are basically the same root and homology, and there is almost no difference from the perspective of product design. The main differences may focus on the way the information is verified, the consensus algorithm of the notary public, the signature algorithm of the escrow wallet, etc. The differences in experience and security are not too great. Therefore, from the perspective of security, the security risks faced by the security also have many commonalities.

This paper will focus on the summary and analysis of the notary mechanism of cross-chain Bridges faced with some common security risks.

Two: the notary mechanism of the product logic process

Before we look at the various risks faced by the notary system, we need to understand the main design logic of this type of scheme from a product point of view.

(1) Brief introduction

This solution is very simple from a design philosophy point of view. When we look at the need for heterogeneous assets across chains, the most intuitive solution is actually "mapping". Mapping means when user A crosses ETH from Ethereum to Fantom. We didn't have to actually transfer the assets or reissue them on Fantom (which we couldn't). Instead, user A's ETH is first saved to an immovable address, and then A 1:1 mapping asset is issued on Fantom based on the number of user A's ETH in this address. The mapped assets represent access to those ETH on the original Ethereum chain. With a 1:1 anchor, users on Fantom recognize the value of this asset.

The most simplified cross-chain process

(2) design difficulties

There will be A lot of problems in this, among which the biggest problem is the management of multi-sign wallet, because ETH from Ethereum to Fantom is to charge coins, and if user A wants to cross back, it will involve the issue of withdrawing coins.

The decentralization and security of charging and withdrawing coins have become the biggest difficulty.

1: Who will manage the money?

2: Who will initiate it?

3: Who listens to transactions?

4: How to confirm that some users have transferred money?

5: How to confirm that the user's money is really the user wants to put forward?

6: How do I prevent replay attacks?

7: How to resubmit a failed transaction?

8: How to do more than sign the manager evil?

9: What about downtime?

I can't imagine. The more I think about it, the more complicated it gets. Cross-chain bridging techniques involve not only multi-signing, but also asset issuance, cross-chain listening, asynchronous verification, and even the need to issue a separate intermediate consensus layer (a new chain).

Therefore, in order to further simplify the user's understanding difficulty, I divided the whole cross-chain process into two parts: coin charging and coin withdrawal. To help you understand more:

(3) Further refinement of the process & NBSP;

1: filling currency

First, I want to declare that the process drawn below is only my design scheme after deduction, without careful argumentation. The purpose is to explore the possible safety problems in the design logic, and it can not be used as a shaped scheme. It is all nonsense.

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

(1) Users recharge to the hosting address

(2) BP (the consensus node is also the multi-sign administrator) initiates the transaction after the listener detects the transaction

(3) The contract verifies the correctness of BP signature

(4) Whether there is fault tolerance mechanism through nodes

(5) If there is no call back, recharge the target chain address according to the mapping address

(6) BP confirms this top-up transaction

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

It is important to note that this process is designed to discuss generic heterogeneous cross-chains, so compared to schemes like Anyswap, a step is added to bind the address relationship between users at the intermediate consensus layer. This is mainly because the way of information attached to different heterogeneous chain transactions is not the same. In order to unify the processing, simply let the user bind a good mapping relationship first.

If you are dealing with EVM chain transactions, you do not need this step. You can simply initiate the transaction with the target chain address.

Back to the point: As you can see from the above process, starting from the second step, you will encounter various types of logical verification problems and processing problems in different situations.

The main verification logic includes:

(1) Verify the transaction initiated by asset mapping and transferred to the target chain of user A after the transaction is monitored

(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 the counterfeit coin recharge problem and the special handling that needs to be done when invoking different tokens. In order to better summarize the potential security risks in the future, we will continue to understand the process of currency withdrawal.

2: money

The process demonstrated by the coin withdrawal is the logic of the target chain mapping assets back to the original chain assets. Special attention should be paid to the fact that many current tokens have found multiple chain versions, that is to say, many tokens have native tokens on multiple chains. Therefore, some bridge projects tend to set up asset pools. In the case of sufficient capital pool, users can not feel the existence of mapped assets like anyDAI, but directly replace the token of the target chain version, but this does not affect the overall logic. So, the analysis goes on:

As shown in the figure, the transaction process of a coin withdrawal from the target chain to the original chain is as follows:

(1) Users initiate transactions (transfer the same amount of mapped assets to the escrow wallet on the target chain)

(2) Verify the identity of BP, and a BP initiates a request to withdraw money

(3) Confirm the withdrawal authority and signature

(4) After the Byzantine court, complete the request to withdraw the currency in the original chain, and transfer the money from the escrow wallet of the original chain to User A

(5) If this is due to node verification error or breakdown and other problems, it needs to be rolled back and restarted

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

(1) Verification of initiating and signing permissions

(2) Fault tolerance mechanism after the problem occurs

(4) Security risks & NBSP;

1: Security issues in design logic

After a more careful understanding of the design of cross-chain Bridges, we can find that there are many challenges in the design logic of cross-chain Bridges, which mainly include three aspects (related theft cases are marked at the end of the problem).

(1) & have spent Charge money

a) The loophole in the authority of the rechargeable currency contract leads to the direct transfer of the money. This is a silly question that almost every contract project has,

b) Counterfeit coin recharge problem, some items have not verified the authenticity of the cross-chain Token, resulting in fakeTOKEN -> RealTOKEN (Anyswap), which is actually kind of stupid.

c) Counterfeit currency recharge problem, ETH and other native assets are different from ERC20 contracts, many attacks are due to ETH special improper treatment, resulting in. -> RealETH, which is also why wrapped assets such as WETH are popular. (thorchain)

d) Although different tokens are ERC20 standard, the specific implementation method is different, or there are additional logic (Rebase, fallback, etc.), the developer did not do a good research when adapting. Such as (WETH, PERI, OMT, WBNB, MATIC, AVAX) will still call the fallback function defined by the sender to do additional operations after the transfer is completed, which increases the complexity of cross-chain bridge judgment. (anyswap 2022.1.18)

(2) & have spent Cross-chain message transfer

After the completion of currency charging in chain A and before the assets in chain B are transferred to the account, the processing of the cross-chain bridge is like an independent blockchain system, that is, a consensus mechanism is needed, and DPOS is generally used. The following are the issues to be considered under the assumption that DPOS is used, but I doubt that all nodes belong to the project side, which has the risk of centralization in the first place.

a) Who will be the first to initiate a cross-chain processing proposal, random? Or take turns? Or in the order of the blocks in the middle consensus layer?

b) How do multiple notary public verify the correctness of charging currency? If the data sources are all from data providers such as Infura, Infura is a single point of risk, and the most prudent is to maintain the nodes individually, which costs a lot.

c) How to confirm that cross-chain processing is finished (B has been posted to the account)? There are several situations when it is not finished:

i. The cross-chain bridge does not initiate processing

ii. Cross chain bridge initiated processing, but verification & AMP; The consensus was not passed

iii. Cross-chain bridge verification is passed, but no transaction is initiated on chain B

iv. There was a transaction on chain B, but it failed (lack of funds or something)

(3) Multiple signature verification problem

The most common problem is the code logic problem

a) 3/5 signature, I randomly constructed the signature that is not in the multi-signature list, also counted as +1 (Chainswap).

b) The problem of centralization is nominally multi-signing, but in fact it is in the hands of the project side, which is a huge risk of centralization.

c) The signature verification method varies with the development mode on different chains. As a result, developers may miss something during interconnection. Solana on validation of the signature function is a function of the system's contract, should go to a normal call system, contract system is the address of the contract should write dead in the code, the system contracts address here is incoming as parameters, the hackers make money when a fake address system contracts, bypassing the attestation, smoothly to withdraw money.

(4) & have spent A refund

a) As discussed in (2) -c, there are many possibilities of cross-chain status, and in any case, a refund method should be provided to the user. For example, Anyswap will first send anyToken to the user on the source chain and then send anyToken to the user on the target chain when charging coins. Then take the anyToken of the source chain; Burn, the purpose of this is that no matter what the problem is, the user can hold an anyToken to represent the asset he owns. In this process, there are 3 chains (source, destination, cross-chain bridge) and 4 assets (original Token/anyToken on source chain and destination chain), which is very prone to code logic problems.

b) In the vulnerability of Thorchain on July 23, 2021.21, hackers used the code logic problem to construct a huge amount of fake recharge, which could not be handled by the cross-chain bridge, so they entered the refund logic, resulting in a huge amount of refund for hackers.

2: indicates other security risks

But the problems shown through the logical flow are only the business logic problems, not the whole story.

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

(1) Systemic risk

For example, the coin charging of the original chain was successful at the beginning, but later rolled back, which was a huge problem. V God discussed that the asset crossed from Solana to Ethereum, and Solana rolled back after the completion of the cross-chain, then the user's asset doubled without any solution.

But Rollup, a Layer2 that shares security with Ethereum, doesn't have this problem.

(2) Front-end risks

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

b) An Xss attack, or cross-site scripting attack, is a code injection attack, such aswww.xxxx.finance/? params=hackerscode12345Although the website is indeed the official website, the website carries the hacker's code. If the front-end development does not pay attention to preventing XSS, this code will be executed on the page, leading to the user's authorization signature for the hacker's transfer transaction. Therefore, do not open links of unknown origin.

c) Cors cross-site service attack, in strict homology policy, the browser is only allowed to load content from the site, i.ewww.xxxx.financeAll the content displayed in the site and the interface called should be from the xxxx.finance domain name, but most of the current projects allow cross-site call, that is, the XXXX front end can call the interface of QuickSwap, and vice versa, which brings convenience to the development, but also brings risks:

Suppose I access xxxx.finance, store some sensitive data in the browser cache, and then I access a malicious website, if XXXX's homology policy is not restricted, the malicious website can freely access the data stored in XXXX's cache.

(3) Risks of additional functions

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

The attacker initiates a call to the X contract on chain B in chain A, and the cross-chain bridge directly calls the X contract no matter what the X contract is. Unexpectedly, the X contract is the multi-sign contract on chain B across the chain bridge. This call is to change the multi-sign account to the attacker's own address. Hackers can now spend as much money as they like on chain B as they like. The network).

Three: conclusion

1. The purpose of this report is to help users understand the security risks of cross-chain Bridges more clearly, rather than to render how vulnerable cross-chain Bridges are to attacks maliciously.

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