Repeat the Thorchain "false recharge" vulnerability

2021-06-30 17:34

Read this article in 10 Minutes

AI summary

View the summary

Title of the original article: Counterfeit Money Trick -- Technology Dismantling Thorchain Cross-chain System "Counterfeit Recharge" Vulnerability

Original source: Johan, Slow Fog Technology

On June 29, 2021, decentralized cross-chain transaction protocol Thorchain tweeted that a malicious attack against Thorchain had been detected, and the Thorchain node had responded to isolate and defend itself. The slow fog security team got involved in the analysis for the first time. After analysis, it was found that this was a "false recharge" attack targeting the cross-chain system. The results were shared as follows:

What is a "fake top up"?

When we talk about "fake top-up" attacks, we're usually talking about attackers taking advantage of some features of the public chain to bypass the exchange's top-up procedures to make fake top-up payments and make real top-up payments.

Slow Fog has disclosed a number of "fake recharge" attacks in the early days:

[1] USDT false recharge:USDT false transfer security risk analysis | 2345 new science and technology institute of block chain laboratory

[2] EOS false recharge:EOS false top up (hard_fail state attack) red alert details disclosure and repair plan

[3] Ethereum token fake recharge:Ethereum token "fake recharge" vulnerability details disclosure and fix plan

[4] Bitcoin RBF false recharge risk:Risk analysis of bitcoin RBF false recharge

With the rise of cross-chain services such as RenVM and Thorchain, cross-chain nodes act as exchanges and generate asset maps on the local public chain by scanning the transfer of assets in another public chain. It is through this mechanism that Thorchain transfers tokens from Ethereum to other public chains.

Vulnerability analysis

We trace the cause of the vulnerability from the business logic entry.

The first thing you see is that is called when handling a cross-chain recharge event; getAssetFromTokenAddress Method to get the substitution information and passes in the asset contract address as an argument:

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

In & have spent getAssetFromTokenAddress Method, we see that it calls getTokenMeta The asset contract address is also passed in as a parameter, but there is a definition here that causes us to be alarmed. When initializing the token, the token symbol is given by default as Asset := common.ethAsset. If the token that is passed in to the contract address is ETH, then the value of the token that is passed in to the contract address is symbol The validation of the

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

Continuing to test our speculation, we see that when the token address does not exist in the system, it will fetch contract information from the Ethereum mainchain, and obtain the symbol The new token is built, at which point all the bug causes have been revealed:

- 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, first of all due to the incorrect definition, if the cross-chain recharging ERC20 token symbol is ETH, then there will be a logic error that causes the charged token to be identified as the real Ether. The ETH.

Restore the attack truth

Let's look at the execution process of an attack transaction. We can extract the address of the token contract that has been recharged:

Let's look at this token contract address on Etherscan:

The token of the contract corresponding to this address is ETH, the attacker is through the deployment of the fake currency contract, completed the cross-chain false recharge.

Bug fix

Bug patch:

The project team quickly fixed the code after discovering the attack, removing the default token type and using common.EmptyAsset NULL token definition and use in subsequent logic asset.IsEmpty() It makes a judgment to filter the false top-up tokens that have not been assigned.