The Security Threats of THORChain (RUNE)
According to THORChain’s treasury report for the first quarter of 2022, published on April 1, the chain recorded revenue growth, despite the dual impact of continued market sluggishness and highly volatile geopolitical factors. Public data shows that THORChain posted $2.17 billion in revenue in the first quarter of 2022. Hailed as the “cross-chain version of UniSwap”, THORChain gained a foothold in the cross-chain trading market based on its unique advantages and gained extensive recognition among investors.
Behind all this glamour, THORChain also suffers a lot from hacking. The chain has faced regular security breaches since its launch on Ethereum, a fact that casts doubt on its security. On April 11, THORChain tweeted about phishing attacks and warned users not to interact with [DeTHOR] or other unknown tokens in their wallets, again raising concerns about the security vulnerabilities.
While building a sound security system for CoinEx products, the CoinEx security team also tracks security incidents in the blockchain space to help users better understand the security of various projects from a technical security perspective and reduce investment risk. With the aim of improving the security criteria for the blockchain sector, the CoinEx security team has analyzed the security risks of THORChain (RUNE). The team hopes that THORChain can identify and mitigate the following risks by optimizing the relevant smart contract codes. In addition, this article is also a warning to users, to remind them to be more aware of asset security and avoid asset losses.
How secure is THORChain (RUNE)?
By analyzing the contract code and logic of THORChain (RUNE), the CoinEx security team found the following risks:
For starters, let’s take a look at THORChain’s (RUNE) contract code:
We can see that RUNE is a pretty standard ERC-20 token. It should be noted that in addition to the ERC-20 interface, THORChain (RUNE) provides an additional interface:
According to transferTo (as shown in the image above), THORChain (RUNE) uses tx.origin, which is one of the causes of the security vulnerabilities. Here we need to explain the difference between tx.origin and msg.sender:
The image below describes what happens when a regular address calls the smart contract:
In such cases, msg.sender = account.address and tx.origin = account.address, which means msg.sender is the same as tx.origin.
The following is what happens when an account calls contract A and contract A calls contract B:
When contract A calls contract B (as shown above), we can see that msg.sender equals tx.origin in contract A.
In contract B, msg.sender = contractA.address, while tx.origin = account.address. Therefore, tx.origin is like a global variable that iterates through the entire call stack and returns the address of the account that originally sent the transaction. Here’s the key point: so far, almost all known attacks on THORChain (RUNE) involve tx.origin.
Now let’s see how attackers steal RUNE tokens from users via tx.origin:
Attack No.1: Steal a goat from a herd
Addresses on Ethereum are divided into external addresses and contract addresses. Transferring ETH to these two types of addresses through external addresses is fundamentally different. The Official documentation of solidity states that a contract address must implement an Ether receive function before making transfers.
In light of the characteristics of tx.origin, hackers can create an attack contract:
When the Attack contract receives an ETH transfer from a user, it will “steal a goat from a herd” – the contract will steal the user’s RUNE tokens in the process.
Attack #2: Internal Attack
An internal attack is a special type of attack. When the hacker tries to steal a user’s RUNE through an internal attack, the hacker must have a medium token. In addition, the token must also summon contracts from third parties. According to RUNE transfer data on Ethereum, some attackers hacked into RUNE through AMP Token transfers.
AMP Token uses the ERC-1820 standard to manage Hook registration and examine if Hook is registered on every transfer. If Hook is registered, the Hook will be called.
The AMP Token contract code shows that the final execution of the transfer is: _transferByPartition. Meanwhile, there are two calls involving transferHook: _callPreTransferHooks (before the transfer) and _callPostTransferHooks (after the transfer). Specifically, _callPreTransferHooks is for the from address, while _callPostTransferHooks is for the to address (ie the receiving address).
For regular users, stealing tokens from themselves is pointless. Attackers can therefore exploit _callPostTransferHooks. Now let’s look at the codes of _callPostTransferHooks.
We can see that the only callback attackers can exploit is IAmpTokensRecipient(recipientImplementation).tokensReceived().
Next, we’ll illustrate how this call can be used to transfer a user’s RUNE during an AMP token transfer.
Step 1: A call contract is required (as shown below):
Step 2: Implement the contract to get the attack address.
Step 3: Call the ERC-1820 contract interface (setInterfaceImplementer) to register the interface.
ERC-1820 Address: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24
Contract interface: setInterfaceImlementer(address toAddr, bytes32 interfaceHash, address implementor)
Specifically, toAddr is the receive address of the AMP transfer,
interfaceHash is the hash of AmpTokensRecipient:
Implementer is the attack address obtained in step 2.
Step 4: Entice a user to transfer AMP to the toAddr to trigger a callback and steal their RUNE at the same time.
Attack #3: Phishing Attack
As the name suggests, in a phishing attack, the attacker promises to give away incredible benefits to trick users into performing certain contract operations. Here we introduce a common phishing attack.
Step 1: The attacker issues an ERC-20 token and can write it into any contract interface that requires signatures.
Step 2: Create a trading pair on Uniswap or any other swap;
Step 3: Offer airdrops to all users/addresses who have RUNE tokens;
The initial work of the phishing attack is basically completed by the above steps. Then the attacker just has to wait for users to trade on a swap, and users risk losing their RUNE once they perform operations like approve, transfer, etc.
In addition, to further verify the security risk of the THORChain contract code, CoinEx consulted with the security team of SlowMist and PeckShield, two well-known security firms in the industry. Confirmed by SlowMist and PeckShield, the aforementioned security risk exists.
So far, we’ve covered different types of attacks, as well as the security risks users are exposed to.
How should the project team optimize the contract code to make itself more secure and protect users’ assets?
The only answer is to be careful when using tx.origin.
How can regular users mitigate risk and protect their assets from attacks that seem inevitable? The CoinEx security team offers the following suggestions:
For Attack No.1: When making a transfer, keep track of the estimated gas consumption. For a regular ETH transfer, a gas fee of 21,000 is more than enough. Beware if the Gas consumption far exceeds that figure. For Attack No.2: Isolate your tokens by using different wallets. You can store different tokens at different addresses. Extra caution is advised when it comes to the popular wallet address offered by exchanges. For Attack No.3: Greed is the source of all evil. Do not blindly participate in an airdrop event.
Security has always been a top priority in the blockchain industry. All players, including project teams and exchanges, must prioritize security during project execution, keep users’ assets safe and secure, and collectively promote the healthy growth of the blockchain industry.