The Security Risks of THORChain (RUNE)

According to THORChain’s treasury report for Q1 2022 released on April 1, the chain registered a growth in revenue despite the twofold impact of persistent market sluggishness and highly unstable geopolitical factors. According to public data, THORChain generated $2.17 trillion in revenue for Q1 2022. THORChain, acclaimed as the “cross-chain version of UniSwap”, gained a foothold in the cross-chain trading market relying on its unique advantages and earned extensive recognition among investors.

THORChain, despite all its glamour, is still plagued by hackers. The security of the chain was questioned since its inception on Ethereum. It has been subject to numerous security breaches. THORChain posted about phishing on April 11, warning people not to engage with them. [DeTHOR]Additionally, they may have other tokens that are not known to them. These issues raise concerns over its security.

The CoinEx security team works to create a solid security system for CoinEx products. However, they also keep track of security incidents within the blockchain space. This helps users understand different projects’ technical security as well as mitigate investment risk. To improve security in the blockchain sector, CoinEx’s security team studied the risks associated with THORChain. The team hopes that THORChain will be able to identify and minimize the following security risks, by optimising the appropriate smart contract code. This article also serves as a reminder to users that they should be aware of asset security in order to avoid any asset loss.

Is THORChain (RUNE), as secure?

The CoinEx security team discovered the following vulnerabilities through analysis of the contract code, logic and THORChain(RUNE) transactions:

To begin with, let’s check out the contract code of THORChain (RUNE):

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code

It is obvious that RUNE can be used as an ERC-20 token. It’s important to mention that RUNE is not only an ERC-20 token, but also has a THORChain interface (RUNE).

As shown above, transferTo states that THORChain is using tx.origin to create security threats. This is where we will explain the differences between msg.sender.

This is what happens when an address regular calls the smart-contract:

These cases have msg.sender as account.address and tx.origin as account.address. This means that msg.sender will be the same thing as tx.origin.

Here’s what happens when an account calls Contract A and Contract A calls Contract B.

If contract A calls Contract B, as illustrated above, we know that msg.sender equals contract A’s tx.origin.

In contract B however, contract.sender=contractA.address and tx.origin=account.address. The tx.origin variable is a global variable that runs through the call stack, returning the address of the account which originally sent the transaction. The key problem is that almost all attacks on THORChain have been directed at tx.origin.

Let’s now find out how attackers steal users’ RUNE tokens through tx.origin:

Attack No. 1: Pilfer a goat from a herd

On Ethereum, addresses can be divided into contract addresses and external addresses. The process of transferring ETH via external addresses to either one or the other is fundamentally different. According to the Official Documentation on solidity, a contract address must have a Receive Ether function in order to make transfers.

An Attack contract could be created by hackers based on the features of tx.origin

When the Attack contract receives an ETH transfer from a user, it will “pilfer a goat from a herd” — the contract will steal the user’s RUNE tokens in the process.

Attack No. 2: Internal Attack

An Internal attack is a unique type of attack. When trying to steal a user’s RUNE through an Internal Attack, the hacker needs to have a medium token. Additionally, the token should be capable of calling third-party contract. RUNE’s transfer records on Ethereum reveal that an attacker hacked RUNE using AMP Token transfers.

AMP Token utilizes ERC-1820 standards to handle Hook registration. Upon each transfer, Hook will be checked for accuracy. Hook is registered once Hook is called.

The contract code of AMP Token shows that the final implementation of the transfer is: _transferByPartition. Meanwhile, there are two calls involving transferHook: _callPreTransferHooks (before the transfer) and _callPostTransferHooks (after the transfer). In particular, _callPreTransferHooks is for the from address, while _callPostTransferHooks is for the to address (i.e. the recipient address.

Regular users will not be able to steal tokens. Therefore, attackers may exploit _callPostTransferHooks. Let’s now check out the codes of _callPostTransferHooks.

IAmpTokensRecipient(recipientImplementation).tokensReceived()

We can tell that the only callback that attackers could exploit is IAmpTokensRecipient(recipientImplementation).tokensReceived()

Next, we will illustrate how this call can be used to transfer a user’s RUNE while making an AMP Token transfer.

Step 1. It is necessary to have a contract for calling (as illustrated below).

Step 2 You can deploy the contract in order to get the Attack Address.

Step 3 Call the ERC-1820 contract interface (setInterfaceImplementer) to register the interface.

ERC-1820 Address: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

Interface for contracts: setInterfaceImplementer(address toAddr, bytes32 interfaceHash, address implementer)

Particularly, the receiving address for an AMP transfer is toAddr.

interfaceHash为AmpTokensRecipient的hash:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

interfaceHash represents the hash for AmpTokensRecipient

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

You can implement the Attack Address you obtained in Step 2.

Step 4 Induce a user into transferring AMP to the ToAddr in order to activate a callback and also steal his RUNE.

Attack No.3: Phishing Attack

A phishing attack promises incredible incentives to lure victims into contracting operations. We will now introduce you to a common form of phishing.

Step 1.An attacker may issue an ERC-20 token and write it into any contract interface that requires signatures.

Step 2Make a trading pairing on Uniswap and any other swap

Step 3Airdrops are available to RUNE token-holders and all addresses.

This is the main way to complete the initial phishing attacks. The attacker needs to wait until users trade on a Swap. Users risk losing their RUNE if they do not perform operations like approve, transfer or etc.

CoinEx discussed security concerns with PeckShield (a well-known industry security agency) in an effort to verify the security of the THORChain contract codes. PeckShield and SlowMist confirm that the above security risk exists.

We have so far covered many types of attacks as well as security threats that users face.

How should the project team optimize the contract code to make itself more secure and protect users’ assets?

You must be careful when using tx.origin.

What can users do to protect themselves and their assets from attacks? Here are some suggestions from the CoinEx security team.

  1. Attack No.1: Track your estimated gas consumption while making a Transfer. A Gas fee of 21,000 will cover a regular ETH transaction. If your Gas consumption is much higher than that, be careful.
  2. Use different wallets to isolate tokens in Attack 2. Multiple tokens may be kept at different addresses. You should be extra cautious when you are dealing with hot wallet addresses offered by exchanges.
  3. Attack No. 3: Greed leads to all evil. Don’t blindly accept any airdrop.

In the blockchain sector, security has always been an important concern. All players, including project teams and exchanges, should prioritize security during project operation, keep users’ assets safe and secure, and jointly promote the sound growth of the blockchain industry.

Get more Crypto News at CFX Magazine