Foreword:

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 been designed with relevant coping strategies. The main purpose is to hope that more people can understand the complexity of this track .

secondary title

01. 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.

secondary title

02. The product logic flow 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

image description

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 a user has transferred 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 should I do 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 understand better.

(3) Further refinement of the process

1. Deposit

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) After passing Byzantium, transfer the mapping token to the user's address on the target chain

It should be noted that this process aims to discuss general heterogeneous cross-chains, so compared with anyswap and other solutions, an additional step is added to allow 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, it can be seen from the above process that starting from the second step, you 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 asset mapping initiated and transferred to the target chain transaction 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 verification of counterfeit currency recharge issues, and 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, the process of a transaction 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 identity of the BP. A BP initiates a coin withdrawal request (3) confirms the coin withdrawal authority and signature (4) completes the request to withdraw coins on the original chain after passing Byzantium, and transfers the money from the escrow wallet of the original chain to user A (5) if there is a node in the middle Problems such as verification errors or downtime need to be rolled back and re-initiated. From the above process, it can be seen that the main verification logic involved in this is: (1) verification of initiation and signature permissions (2) fault-tolerant mechanism after problems occur

(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 problem 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 also a bit stupid . d) The problem of counterfeit currency recharge, ETH and other native assets are different from ERC20 contracts, many attacks are due to improper handling of ETH, resulting in fakeETH -> realETH, which is why wrapped assets such as WETH are popular. (thorchain) c) Although different Tokens are all ERC20 standards, the specific implementation methods are different, or there are additional logics (rebase, fallback, etc.), the developer 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 coin recharge of chain a is completed, and before the assets of chain b arrive at 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 credited), there are several situations that have not been processed. i. The cross-chain bridge did not initiate processing ii. The cross-chain bridge initiated processing, but the verification & consensus did not pass iii. The bridge verification is passed, but no transaction is initiated on the b-chain iv. There is a transaction on the b-chain, but it fails (insufficient funds or other circumstances)

(3) Multi-signature verification problem

Most of the hardest hit areas with frequent problems are code logic problems a) 3/5 signatures, I just construct signatures that are not in the multi-signature list, which is also considered +1 (chainswap). b) The problem of centralization, which is multi-signature in name, is actually in the hands of the project party, a huge risk of centralization c) The signature verification method, the development model on different chains is different, resulting in inevitable omissions when developers connect , wormhole example: The verification signature function on solana is a function in the system contract. Normally, the system contract should be called, and the address of the system contract should be written in the code. They pass the address of the system contract as a parameter here. Hackers When withdrawing coins, a fake system contract address was passed, and the signature verification was bypassed, and the coins were withdrawn 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 anyToken, and then send anyToken to the user on the target chain, and then burn the anyToken of the source chain. The purpose of this is that no matter where the problem is, the user can represent the assets he holds 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 leaked 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, resulting in the hacker getting 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 the assets are transferred from Solana to Ethereum. solution. But for example, layer 2, which shares security with Ethereum, such as rollup, will 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.xxxx.finance/?params=hackerscode12345, although the URL is indeed It is the official website, but the website carries the code of the hacker. If the front-end development does not pay attention to preventing xss, this code will be executed on the page, causing the user to authorize the hacker’s transfer transaction to sign. Therefore, 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 front-end of xxxx can call the quickswap interface, and vice versa, which brings convenience to development, but also brings risks. If I visit xxxx.finance stored some sensitive data in the browser cache, and then I visited 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

secondary title

03. Epilogue

1. The purpose of this report is to help users understand the security risks of cross-chain bridges more clearly, 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.

Scan the QR code to join the community Product issues, please follow Jackson's personal Twitter to discuss @0xOar

About SeerLabs:

SeerLabs (Prophet Labs) is a leading institution in Asia that focuses on blockchain market incubation. We have global cutting-edge marketing concepts and growth hackers, and are committed to helping project parties and startups achieve lightning-fast growth. Successfully participated in the incubation of 30+ projects such as Ploygon (MATIC), HoDooi.com, DIA, Paralink, Swingby, XEND Finance, BOSON, etc.

join us:

Twitter: https://twitter.com/seerlabs_crypto

Product communication: https://twitter.com/0xOar

Cooperation email: sharon@seerlabs.io

Risk warning: Digital assets are a high-risk investment target. The general public is requested to view the blockchain rationally, raise risk awareness, and establish correct currency concepts and investment concepts.