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

Preface

As ETH upgraded its PoS consensus system, the original PoW ETH chain successfully hard forked with the support of some communities (hereinafter referred to as ETHW). However, since some on-chain protocols were not prepared for possible hard forks at the beginning of their design, the corresponding protocols have certain security risks in the ETHW fork chain, the most serious of which is replay attacks.

After the hard fork was completed, at least two attacks using the replay mechanism occurred on the ETHW mainnet, namely the OmniBridge replay attack 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.

Type of replay

First of all, before we start the analysis, we need to have a preliminary understanding of the types of replay attacks. Generally speaking, we divide replay attacks into two categories: 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 transactions on the original chain to the target chain intact. It is a 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 the attack of Wintermute on Optimism, which directly led to the loss of more than 20 million OP Tokens. However, after the implementation of EIP 155, since the signature of the transaction itself carries the chainId (an identifier used to distinguish the chain itself from other forked chains), if the chainId of the replayed target chain is different, the transaction itself cannot be replayed.

Signed message replay

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

OmniBridge and Polygon Bridge attack principles

Next, we will analyze the attack principles of OmniBridge and Polygon Bridge. First of all, the conclusion is that these two attacks are not transaction replay attacks. The reason is that ETHW uses a chainId that is different from the ETH main network, so directly replaying transactions cannot be verified. Then the only option left is message replay. Next, we will analyze how each of them was attacked by message replay on the ETHW fork chain.

OmniBridge

OmniBridge is a bridge used to transfer assets between xDAI and ETH mainnet. It mainly relies on the bridge's designated validator to submit cross-chain messages to complete the transfer of cross-chain assets. In OmniBridge, the logic of the verification message submitted by the validator is as follows:

In this function, the signature check in line #L2 is used to determine whether the submitted signature is signed by the specified validator, and then the data message is decoded in line #L11. 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 to analyze.

By tracing the _executeMessage function, we found that the function checked the legitimacy of chaindId at line #L11.

By continuing to analyze the subsequent function logic, it is not difficult to find that the check for chainId does not actually use the evm native chainId opcode to obtain the chainId of the chain itself, but directly uses the value stored in the uintStorage variable. This value is obviously set by the administrator, so it can be considered that the message itself does not carry a chain identifier, so in theory, the signed message can be replayed.

Since all states before the hard fork will be retained intact on both chains, without any additional operations by the xDAI team, the states of the Omni Bridge contract on ETHW and the ETH mainnet will not change after the hard fork, which means that the validator of the contract will not change. Based on this, we can infer that the signature of the validator on the mainnet 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 a bridge used to transfer assets between Polygon and ETH mainnet. Unlike Omni Bridge, Polygon Bridge relies on block proof for withdrawals, and the logic is as follows:

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

The corresponding headerRoot is extracted from the _checkpointManager contract. Following this logic, we look at where _checkpointManager sets headerRoot.

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

Taking the address 0x7dbf18f679fa07d943613193e347ca72ef4642b9 as an example, this address successfully completed the arbitrage on the ETHW chain through the following steps:

First, rely on the currency ability to withdraw money from the main network trading platform.

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

The ETH mainnet calls the exit function of Polygon Bridge to withdraw coins;

Copy and extract the headerRoot submitted by the ETH mainnet proposer;

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

Call exit on Polygon Bridge in ETHW to withdraw coins

Why does this happen?

From the two examples analyzed above, it is not difficult to find that the two protocols suffered replay attacks on ETHW because the protocols themselves did not have anti-replay protection, resulting in the assets corresponding to the protocols being emptied on the forked chain. However, since the two bridges themselves do not support the ETHW forked chain, users did not suffer any losses. But what we need to consider is why these two bridges did not 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 simple, just used to transfer assets to the corresponding chain they designated, and there is no plan for multi-chain deployment, so the lack of replay protection does not cause 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 suffer from message replay attacks on the ETH mainnet.

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

This variable was first defined in EIP712. It contains chainId and was designed to prevent replay in multi-chain scenarios. However, according to the logic of the uniswapV2 pool contract, it is as follows:

DOMAIN_SEPARATOR has been defined in the constructor, which means that after the hard fork, even if the chainId of the chain itself has changed, the pool contract cannot obtain the new chainId to update the DOMAIN_SEPARATOR. If the user performs relevant authorization on ETHW in the future, the permit signature authorization on ETHW can be replayed on the ETH mainnet. In addition to Uniswap, there are many similar protocols, such as the yearn vault contract under a specific version, which also uses a fixed DOMAIN_SEPARATOR. Users also need to guard against the replay risk of such protocols when interacting on ETHW.

Precautions at the beginning of protocol design

For developers, when customizing the message signing mechanism for the protocol itself, possible multi-chain scenarios should be considered. If there is a possibility of multi-chain deployment in the roadmap, the chainId should be added to the signed message as a variable. 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 signed message should not be set as a contract variable, but should be retrieved before each verification and then verified to ensure security.

Influence

Impact on users

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

Impact on trading platforms and custodians

Since many trading platforms support ETHW Token, the tokens extracted due to the attack may be recharged to the trading platform for selling. However, it should be noted that such attacks are not malicious issuance caused by problems with the chain consensus itself, so there is no need for additional prevention for such attacks on the trading platform.

Summarize

With the development of multi-chain scenarios, replay attacks have gradually become a mainstream attack method from a theoretical level. Developers should carefully consider the protocol design. When designing the message signing mechanism, they should add factors such as chainId as signature content as much as possible and follow relevant best practices to prevent the loss of user assets.

Cobo is the largest cryptocurrency custodian in the Asia-Pacific region. Since its establishment, it has provided excellent services to more than 500 top industry institutions and high-net-worth individuals. While ensuring the safe storage of encrypted assets, it has also achieved steady gains in encrypted assets and is trusted by users around the world. Cobo focuses on building scalable infrastructure, providing multiple solutions such as secure custody, asset appreciation, on-chain interaction, and cross-chain and cross-layer for institutions to manage multiple types of assets, providing the most powerful technical underlying support and empowerment for institutions to move towards Web 3.0 transformation. Cobo's business segments include Cobo Custody, Cobo DaaS, Cobo MaaS, Cobo StaaS, Cobo Ventures, Cobo DeFi Yield Fund, etc. to meet your various needs.