Due to the wrong definition, if the ERC20 token symbol for cross-chain recharge is ETH, there will be a logical error; the attacker completed the cross-chain fake recharge by deploying a fake currency contract.
Original title: “Fake Money’s Face-changing Trick-Technical Dismantling of THORChain Cross-chain System “Fake Deposit” Vulnerability
Written by: Johan, working for the SlowMist Security Team
According to news from the SlowMist Zone, on June 29, 2021, the decentralized cross-chain transaction protocol THORChain tweeted that a malicious attack against THORChain was discovered, and THORChain nodes have responded and conducted isolation and defense. The SlowMist security team immediately intervened in the analysis. After analysis, it was found that this was a ” fake recharge ” attack against a cross-chain system. The results are shared as follows:
What is “fake top-up”?
When we are talking about ” fake recharge ” attacks, we usually talk about the attacker using certain features of the public chain to bypass the exchange’s recharge entry procedure, make a false recharge, and actually enter the account.
SlowMist has disclosed too many ” fake top-up ” attacks in the early days:
With the rise of cross-chain services such as RenVM and THORChain, cross-chain nodes have acted as exchanges. By scanning the asset transfer of another public chain, asset mapping is generated on the local public chain. THORChain uses this mechanism to transfer tokens on Ethereum to other public chains.
Vulnerability analysis
We trace and analyze the cause of this vulnerability from the business logic entrance.
First see that when processing the cross-chain recharge event, the **getAssetFromTokenAddress** method is called to obtain the token information, and the asset contract address is passed in as a parameter:
bifrost/pkg/chainclients/ethereum/ethereum block scanner.go
In the getAssetFromTokenAddress method, we see that it calls **getTokenMeta** to obtain the token metadata. At this time, the asset contract address is also passed in as a parameter, but there is a definition here that arouses our vigilance. When currency, the token symbol is given by default as ETH , which is one of the key points of the vulnerability: asset := common.ETHAsset , if the token symbol corresponding to the incoming contract address is ETH, then the verification of the symbol here will be Bypass.
bifrost/pkg/chainclients/ethereum/ethereum block scanner.go
Continuing to verify our guess, we see that when the coin address does not exist in the system, the contract information will be obtained from the Ethereum main chain, and a new coin will be constructed with the obtained symbol . At this time, all the causes of the vulnerabilities have been established. appear:
bifrost/pkg/chainclients/ethereum/ethereum block scanner.go
bifrost/pkg/chainclients/ethereum/tokens_db.go
bifrost/pkg/chainclients/ethereum/ethereum block scanner.go
To sum up, firstly due to the wrong definition, if the ERC20 token symbol for cross-chain recharge is ETH , then there will be a logical error, causing the recharged token to be recognized as the real ETH .
Restore the truth of the attack
Let’s look at the execution process of an attack transaction, we can extract the token contract address for recharge:
We check this token contract address on Etherscan:
It was found that the token symbol of the contract corresponding to this address was ETH , and the attacker completed this cross-chain fake recharge by deploying a fake currency contract.
Bug fix
Vulnerability patch:
After discovering the attack, the project party quickly repaired the code, deleted the default token type, used common.EmptyAsset to define empty tokens, and used asset.IsEmpty() in the subsequent logic to judge, filtering and not assigning values Of fake top-up tokens.
to sum up
Fortunately, the project party discovered this attack in time and did not cause huge property losses. However, as a cross-chain system, a huge amount of multi-chain funds may be gathered in the future, and the security cannot be ignored. Therefore, the SlowMist security team recommends designing a cross-chain system. The characteristics of different tokens in different public chains should be fully considered, “fake recharge” tests should be fully carried out, status monitoring and early warning should be done, and professional security companies can be contacted for security audits if necessary.
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended or regarded as actual investment advice.
