Analysis of the “Fake Deposit” Vulnerability in THORChain’s Cross-Chain System(Released in 2021)

According to the news from SlowMist Zone, on June 29, 2021, decentralized cross-chain trading protocol THORChain announced on Twitter that it had discovered a malicious attack against THORChain, and the THORChain node had responded by isolating and defending against the attack. The SlowMist Security Team immediately intervened to analyze the attack and found that it was a “fake deposit” attack against the cross-chain system. The results are as follows:

What is “fake deposit”?

When we talk about “fake deposit” attacks, we usually refer to attackers using certain features of a public blockchain to bypass the deposit accounting process of an exchange and perform fake deposits that actually result in real deposits.

SlowMist has previously disclosed multiple “fake deposit” attack incidents:

☟

【1】USDT fake deposit: USDT fake transfer security risk analysis | 2345 New Technology Research Institute Blockchain Lab

【2】EOS fake deposit: EOS fake deposit (hard_fail status attack) red alert details disclosure and repair plan

【3】Ethereum token fake deposit: Ethereum token “fake deposit” vulnerability details disclosure and repair plan

【4】Bitcoin RBF fake deposit risk: Bitcoin RBF fake deposit risk analysis

With the rise of cross-chain services such as RenVM and THORChain, cross-chain nodes have taken on the role of exchanges, scanning asset transfers on another public chain and generating asset mappings on the local public chain. THORChain uses this mechanism to transfer tokens from Ethereum to other public chains.

Vulnerability analysis

We will trace the cause of this vulnerability by starting with the business logic.

When processing cross-chain deposit events, the getAssetFromTokenAddress method is called to get token information, with the asset contract address passed as a parameter:

- bifrost/pkg/chainclients/ethereum/ethereum_block_scanner.go

In the getAssetFromTokenAddress method, we see that it calls getTokenMeta to get token metadata, with the asset contract address also passed as a parameter. But here we see a definition that raises our alert: when initializing a token, it is assigned a symbol of ETH by default, which is one of the key points of the vulnerability: asset := common.ETHAsset. If the symbol of the token corresponding to the contract address passed in is ETH, the validation of symbol here will be bypassed.

- bifrost/pkg/chainclients/ethereum/ethereum_block_scanner.go

• Continuing our verification of this hypothesis, we see that when the token address does not exist in the system, the contract information is retrieved from the Ethereum main chain, and a new token is constructed using the symbol obtained, which reveals all the causes of the vulnerability:

- bifrost/pkg/chainclients/ethereum/ethereum_block_scanner.go

• bifrost/pkg/chainclients/ethereum/tokens_db.go

• bifrost/pkg/chainclients/ethereum/ethereum_block_scanner.go

To summarize, the first cause of the logical error is the erroneous definition, where if the ERC20 token symbol for cross-chain deposit is ETH, the deposited token will be recognized as the real Ethereum ETH.

Reconstructing the attack

Let’s take a look at the execution process of an attack transaction, from which we can extract the address of the deposited token contract:

We look up this token contract address on Etherscan:

We find that the symbol of the contract at this address is ETH, and the attacker has completed the cross-chain fake deposit by deploying a fake token contract.

Vulnerability fix

Patch for the vulnerability:

After discovering the attack, the project team quickly made code fixes by deleting the default token type, defining an empty token using common.EmptyAsset, and filtering out fake deposit tokens using asset.IsEmpty() in subsequent logic.

Summary

The project team was fortunate to have discovered the attack in a timely manner and prevented significant financial loss. However, as a cross-chain system, it may accumulate substantial funds from multiple chains in the future, and security cannot be ignored. Therefore, the SlowMist Security Team recommends that cross-chain system designs should fully consider the characteristics of different public chains and tokens, conduct thorough “fake deposit” testing, establish state monitoring and warning, and engage professional security companies for security audits when necessary.

About SlowMist

SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, etc.

Website：
https://www.slowmist.com
Twitter：
https://twitter.com/SlowMist_Team
Github：
https://github.com/slowmist/