Flash Depth Data

Search Extension

Cobo Security Team: Hidden Risks and Arbitrage Opportunities in ETH Hard Forks

2022-09-28 22:00

Read this article in 20 Minutes

After the hard fork was completed, at least two attacks using the replay mechanism appeared on the ETHW main network.

Original title: " Cobo Security Team - Hidden Risks and Arbitrage Opportunities in ETH Hard Forks "

Original source: Cobo Global

This article is contributed by the Cobo blockchain security team. The team members are from well-known blockchain security vendors and have rich experience in smart contract auditing. A high-risk vulnerability was found in a DeFi project. The team is currently focusing on smart contract security, DeFi security, etc., researching and sharing cutting-edge blockchain security technologies.

We also hope that lifelong iterative learners who have a research spirit and scientific methodology in the field of encrypted digital currency can join us and export thinking insights and ideas to the industry. Research Views!

This is Cobo Global's first 16 article

Preface

With ETH upgrading the PoS consensus system, the original PoW mechanism of the ETH chain has been successfully hardened with the support of some communities Fork (hereinafter referred to as ETHW). However, because some on-chain protocols were not prepared for possible hard forks at the beginning of the design, the corresponding protocols have certain security risks in the ETHW fork chain, and the most serious security risks are replay attacks.

After the completion of the hard fork, there were at least two attacks using the replay mechanism on the ETHW main network, namely the replay attack of OmniBridge and the Polygon Bridge replay attack. This article will use these two events as cases to analyze the impact of replay attacks on forked chains and how the protocol should prevent such attacks.

Types of Replay

First of all, before starting the analysis, we need to Do a preliminary understanding of the types of replay attacks. Generally speaking, we divide replay attacks into two categories, namely transaction replay and signature message replay. Next, let's talk about the differences between these two types of replay mechanisms

Transaction Replay

Transaction replay refers to the operation of migrating the transactions in the original chain to the target chain intact. It belongs to the replay at the transaction level. After the replay, the transaction can be executed normally and the transaction verification can be completed. The most famous case is Wintermute’s attack on Optimism , which directly resulted in the loss of over 20 million OP Token. However, after the implementation of EIP 155, since the signature of the transaction itself has a chainId (an identifier used to distinguish the chain itself from other forked chains), the transaction itself cannot be completed if the chainId of the replayed target chain is different replayed.

Signature message replay

Signature message replay is different from transaction replay, it is for The replay of the message signed with the private key (e.g. Cobo is the best), in the signature message replay, the attacker does not need to replay the entire transaction, but only needs to replay the signed message. In the message signature, take Cobo is the best as an example. Since the message does not contain any special parameters related to the chain, the message can theoretically be valid in any forked chain after signing. You can pass the verification. In order to avoid the replay of the message on the fork, the chainId can be added to the message content, such as Cobo is the best + chainId(). After carrying a specific chain identifier, the content and signature of messages on different forked chains are different, so it cannot be directly replayed and reused.

The attack principle of OmniBridge and Polygon Bridge

Let’s analyze the attack of OmniBridge and Polygon Bridge Attack principle. First of all, the conclusion is drawn that these two attacks are not transaction replay attacks in themselves, because ETHW uses a chainId different from that of the ETH main network, so direct replay transactions cannot be verified. Then the only remaining option is message replay, so let’s analyze one by one how they are attacked by message replay on the ETHW fork chain.

OmniBridge

OmniBridge is used to transfer assets between xDAI and ETH mainnet The bridge used mainly relies on the designated validator of the bridge to submit cross-chain messages to complete the transfer of cross-link assets. In OmniBridge, the logic of the verification message submitted by the validator is like this

In this function, firstly, according to the signature check of line #L2, it will be determined whether the submitted signature is signed by the specified validator, and then the data message will be checked in line #L11 decoding. From the decoded content, it is not difficult to find that the returned field contains the chainId field, so does it mean that the signed message cannot be replayed? Let's continue the analysis.

By tracing the _executeMessage function, it is found that the function is in line #L11 Checked the validity of chaindId

By continuing to analyze the follow-up It is not difficult to find that the check for chainId actually does not use evm's native chainId opcode to obtain the chainId of the chain itself, but directly uses the value stored in the uintStorage variable, which is obviously set by the administrator Therefore, it can be considered that the message itself does not carry a chain identifier, so in theory, it is possible to replay the signed message.

Because during the hard fork process, all the states before the fork will be kept intact on the two chains, and there will be no additional operations by the xDAI team in the follow-up in the case of. After the fork, the state of the Omni Bridge contract on the ETHW and ETH mainnet will not change, that is to say, the validator of the contract will not change either. According to this situation, we can infer that the signature of the validator on the main network can also be verified on ETHW. Then, since the signature message itself does not contain the chainId, the attacker can use the signature replay to extract the assets of the same contract on ETHW.

Polygon Bridge

Like Omni Bridge, Polygon Bridge is used between Polygon and ETH The bridge for asset transfer on the main network. Unlike Omni Bridge, Polygon Bridge relies on block proofs for withdrawals, the logic is as follows:

Through the function logic, it is not difficult to find that the contract confirms the legitimacy of the message through two checks, namely by checking transactionRoot and BlockNumber to ensure that the transaction actually occurs in the sub-chain (Ploygon Chain), the first check can actually be Bypass, because anyone can construct their own transactionRoot through transaction data, but the second check cannot be bypassed, because it can be found by looking at the logic of _checkBlockMembershipInCheckpoint:

The corresponding headerRoot is extracted from the _checkpointManager contract, follow this logic to check the _checkpointManager setting headerRoot

It is not difficult to find that in the #L2 line of code, The signature data only checks the borChianId, but not the chainId of the chain itself. Since the message is signed by the proposer specified by the contract, the attacker can theoretically replay the proposer’s message signature on the forked chain , submit a legal headerRoot, and then call the exit function in the ETHW chain through Polygon Bridge and submit the corresponding transaction merkle proof, then the withdrawal can be successful and pass the headerRoot check.

Take the address 0x7dbf18f679fa07d943613193e347ca72ef4642b9 as an example, this address has successfully completed the arbitrage of the ETHW chain through the following steps

First of all, rely on the banknote ability to withdraw coins on the main network trading platform.

Deposit coins on the Polygon chain through the depositFor function of Polygon Bridge;

ETH main

Copy and extract the headerRoot submitted by the ETH main network proposer;

Replay the signature message of the proposer extracted in the previous step in ETHW;

Call exit on the Polygon Bridge in ETHW to withdraw coins

Why is this happening?

From the two examples analyzed above, it is not difficult to find that these two protocols encountered replay attacks on ETHW because the protocols themselves did not prevent replay protection, resulting in the assets corresponding to the agreement being hollowed out on the forked chain. However, since the two bridges themselves do not support the ETHW fork chain, users have not suffered any losses. But the thing we have to consider is why didn't these two bridges add replay protection measures at the beginning of their design? In fact, the reason is very simple, because whether it is OmniBridge or Polygon Bridge, the application scenarios they designed are very single, and they are only used to transfer assets to the corresponding chain designated by themselves. There is no plan for multi-chain deployment, so there is no replay protection There is no security impact on the protocol itself.

On the other hand, users on ETHW, since these bridges themselves do not support multi-chain scenarios, if users operate on the ETHW fork chain, they will be on ETH The mainnet suffers from a message replay attack.

Taking UniswapV2 as an example, currently in the pool contract of UnswapV2, there is a permit function, in which there is a variable PERMIT_TYPEHASH, which contains the variable DOMAIN_SEPARATOR.

This variable was first defined in EIP712, which contains chainId, at the beginning of the design, included the replay prevention of possible multi-chain scenarios, but according to the logic of the uniswapV2 pool contract, it is as follows:

DOMAIN_SEPARATOR has been defined in the constructor, that is to say, after the hard fork, even if the chainId of the chain itself has changed, the pool contract cannot obtain Update DOMAIN_SEPARATOR with the new chianId. If future users perform relevant authorization on ETHW, the permit signature authorization on ETHW can be replayed on the ETH main network. In addition to Uniswap, there are many similar agreements, such as the yearn vault contract under a specific version, which also uses a fixed DOMAIN_SEPARATOR. Users also need to guard against replay risks of such protocols when interacting on ETHW.

Precautionary measures at the beginning of protocol design

For developers, When customizing the message signature mechanism for the protocol itself, possible subsequent multi-chain scenarios should be considered. If there is a possibility of multi-chain deployment in the roadmap, chainId should be added as a variable to the signature message. At the same time, when verifying the signature, Since the hard fork will not change any state before the fork, the chainId used to verify the signature message should not be set as a contract variable, but should be reacquired before each verification, and then the signature should be verified to ensure security.

Impact

Impact on users

Generally, when the protocol does not support forked chains, you should try not to perform any operations on the forked chain to prevent the corresponding signed message from being replayed on the main network, causing users to lose assets on the main network

The impact on trading platforms and custodians

Because many trading platforms support ETHW Token , so these are extracted due to the attack Token It is possible to recharge to the trading platform for selling, but it should be noted that this type of attack is not a malicious additional issue caused by the chain consensus itself, so for the trading platform, such attacks do not require additional prevention

Summary

With the development of multi-chain scenarios, replay attacks have gradually become For mainstream attack methods, developers should carefully consider the protocol design. When designing the message signature mechanism, try to add factors such as chainId as the signature content as much as possible, and follow relevant best practices to prevent the loss of user assets.

Cobo is the largest cryptocurrency custody institution in the Asia Pacific region. Since its establishment, it has provided excellent services to more than 500 industry top institutions and high-net-worth individuals. Under the premise of safe storage of encrypted assets, it also realizes the steady gains of encrypted assets, and is deeply trusted by users around the world. Cobo focuses on building scalable infrastructure, providing organizations with multiple solutions for managing multiple types of assets, such as safe custody, asset value-added, chain interaction, and cross-chain and cross-layer, providing the most powerful technology for organizations to transform towards Web 3.0 Underlying support and empowerment. Cobo includes Cobo Custody, Cobo DaaS, Cobo MaaS, Cobo StaaS, Cobo Ventures, Cobo DeFi Yield Fund and other business sectors to meet your various needs.