The recent 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 in this track. It should be stated 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 to hope that more people can understand this track. Complexity.
The writing logic of the article is: first clarify how the 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: An ever-changing cross-chain solution
The previous research report has actually explained to you several different types of information cross-chain solutions. No matter what the final presentation looks like, from the perspective of product design, there are 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, not bar), hash time lock, and notary.
(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 mainchain and sidechains.
However, the side chain scheme generally requires that the original chain and the target chain are isomorphic, so that the applicable scenarios are much less. This is also the reason why Buterin believes that he approves of multi-chain, but does not approve of cross-chain, because there are too many problems in cross-chain solutions that cannot share security.
(2) Hash time lock
This solution is claimed to be the most decentralized heterogeneous cross-chain solution in point-to-point, but the cost is high and the user wait time 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 Public Mechanism
This is the most commonly used heterogeneous cross-chain bridge solution. Most products on the market basically have the same root and the same origin, and there is almost no difference from the perspective of product design. The main differences may focus on the methods and steps of information verification, the consensus algorithm of the notary, the signature algorithm of the escrow wallet, etc. The difference in user experience and safety is not too big. Therefore, from a security point of view, the security risks faced also have many commonalities.
This article will focus on summarizing and analyzing some common security risks faced by the notary mechanism’s cross-chain bridge.
2: The product logic process of the notary mechanism
Before understanding the various risks faced by the notary mechanism, we need to understand the main design logic of this type of scheme from the product point of view.
(1) Brief description
This solution is actually very simple from a design philosophy point of view. When we face the cross-chain requirements of heterogeneous assets, the most intuitive solution is actually “mapping”. Mapping means when user A crosses ETH from Ethereum to Fantom. We don’t need to actually move the asset, or reissue it on Fantom (nor can it). Instead, first store user A’s ETH to an address that cannot be moved, and then issue the corresponding 1:1 mapping asset 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 peg, 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 here, the biggest of which is the management of multi-signature wallets, because ETH is charged from Ethereum to Fantom, and if user A wants to cross back, it will involve withdrawals.
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 what the user 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 about downtime?
I dare not think about it, the more I think about it, the more complicated it becomes. The technology of cross-chain bridge involves not only multi-signature, but also asset issuance, cross-chain monitoring, asynchronous verification, and even the issuance of an independent intermediate consensus layer (a new chain).
Therefore, in order to further simplify the understanding difficulty of users, I will explain the entire cross-chain process into two parts: deposit and withdrawal. To help you better understand:
(3) Further refinement of the process
Let me first state that the process shown in the figure below is just my own design plan after deduction. It has not been carefully demonstrated. The purpose is to explore the possible security problems in the design logic, and it cannot be used as a formed 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 escrow address
(2) After the listener listens to the transaction, the BP (the 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 fault tolerance mechanism through the node
(5) If there is no call back, if there is, recharge the target chain address according to the relationship between the mapped addresses
(6) BP confirms the recharge transaction
(7) After passing Byzantine, transfer the mapped tokens to the user’s address on the target chain
It should be noted that this process is designed to discuss general heterogeneous cross-chains, so compared with anyswap and other solutions, a 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 handle it uniformly, let the user bind the mapping relationship first.
If all transactions of the EVM chain are processed, this step is not required, and the target chain address can be attached directly when initiating the transaction.
Back to the topic: It can be seen from the above process that from the second step, various logic verification problems and processing problems in different situations will be encountered.
The main validation logic includes:
(1) Verification of the target chain transaction that initiates asset mapping and transfers to user A after the transaction is monitored
(2) Initiation of the target chain transaction and verification of the transaction result
Of course, in addition to the verification logic drawn in my process, it should also include the verification of the counterfeit currency recharge problem, as well as the special handling problems that need to be done when calling different tokens. In order to better summarize the potential security risks in the follow-up, let’s continue to understand the process of withdrawing coins.
The process demonstrated by the withdrawal is the logic of the target chain mapping assets to exchange the original chain assets. It should be noted that many tokens currently have multiple chain versions, which means that many tokens are on multiple chains. Own the native token. Therefore, some bridge projects often set up asset pools. When the fund pool is sufficient, users cannot feel the existence of mapped assets such as anyDAI, but directly replace the token of the target chain version, but this does not affect the overall logic. So, the analysis continues:
As shown in the figure: a transaction process of withdrawing coins 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, and a BP initiates a withdrawal request
(3) Confirm withdrawal permission and signature
(4) After passing Byzantine, complete the request to withdraw coins on the original chain, and transfer the money from the escrow wallet of the original chain to user A
(5) If there are problems such as node verification errors or downtime in the middle, it will be rolled back and restarted.
As can be seen from the above process, the main verification logic involved here are:
(1) Verification of origination and signature authority
(2) Fault-tolerant mechanism after the problem occurs
(4) Security risks
1: Design logic security issues
After a careful understanding of the design of the cross-chain bridge, we can find that there are many challenges faced by the cross-chain bridge in the design logic. To summarize the problems mainly include three aspects (the relevant theft cases are marked at the end of the question)
a) Permission loopholes in the deposit contract, resulting in the direct transfer of the deposited 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 a bit stupid.
c) The problem of counterfeit currency recharge. Native assets such as ETH are different from ERC20 contracts. Many attacks are caused by 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 research on adaptation, 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 deposit of the a chain is completed, and before the assets of the b chain are deposited into the account, the processing of the cross-chain bridge is like an independent blockchain system, that is, a consensus mechanism is required. Generally, dpos is used. The following are the assumptions of using dpos. Issues that need to be considered, but I suspect that all nodes are owned by the project, and there is a risk of centralization in the first place.
a) Monitor the deposit message, who will be the first to initiate a cross-chain processing proposal, random? Or take turns? 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 data providers such as infura, then infura is a single point of risk. The safest thing is to maintain nodes separately, which is costly.
c) How to confirm that the cross-chain processing is completed (the account has been received on b), and there are several situations when the processing is not completed:
i. Cross-chain bridge did not initiate processing
ii. The cross-chain bridge initiated processing, but the verification & consensus failed
iii. The cross-chain bridge verification 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
Most of the hardest hit areas with frequent problems are code logic problems
a) 3/5 signatures, I randomly construct signatures that are not in the multi-signature list, which is also +1 (chainswap).
b) The centralization problem, nominally multi-signature, is actually in the hands of the project party, which is a huge centralization risk.
c) Signature verification method, the development mode on different chains is different, which leads to unavoidable omissions when the developer is connected. For example, wormhole: The verification signature function on solana is a function in the system contract. Normally, the system contract should be called. , the address of the system contract should be written in the code. They pass the address of the system contract as a parameter here. The hacker passed a fake system contract address when withdrawing the coins, bypassing the signature verification and successfully withdrawing the coins. .
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 way to refund. For example, anyswap will first send a message to the user on the source chain when depositing coins. 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 what the problem is, users can represent their 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) The loophole that Thorchain broke out on July 23, 2021. The hacker used the code logic problem to construct a huge 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
However, the problems that can be displayed through the logical process are only business logic problems, not all.
From a security point of view, we should also consider three other aspects of risk:
(1) Systemic risk
For example, the deposit of the original chain was successful at the beginning, but it was rolled back later. This is a huge problem. V God has discussed that assets are crossed from Solana to Ethereum. After the cross-chain is completed, Solana is rolled back, and the user’s assets are doubled without any solution.
But such as layer2, which shares security with Ethereum, such as rollup, there will be no such problem.
(2) Front-end risks
a) Fake 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 http://www.xxxx.finance/?params=hackerscode12345, although the URL is indeed the official website, but the URL carries the code of the hacker, if the front-end development does not Be careful to prevent xss, then 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 of unknown origin.
c) Cors cross-site service attack. In the strict same-origin policy, browsers are only allowed to load content from this site, that is, all content displayed by the http://www.xxxx.finance site and the interface called should come from xxxx. Finance domain name, but most projects currently allow cross-site calls, that is, the front end of xxxx can call the interface of quickswap, 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 cross-chain assets, 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 directly calls the x contract regardless of what the x contract is. I did not expect that the x contract is a multi-signature contract on the b chain of the cross-chain bridge. 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).
1: The purpose of this report is to help users clearly understand the security risks of cross-chain bridges, not to render malicious cross-chain bridges vulnerable to attacks.
2: The cross-chain bridge scheme of the notary mechanism is the scheme with the best experience, the widest scope of application and the lowest cost at least from the current point of view. And any product will go through a process from scarred to mature, and the attacks on blockchain products are often “logical problems”. These questions are bound to get better with time and experience.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/why-are-there-so-many-low-level-accidents-across-the-chain-bridge/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.