Trouble in Paradise: 30X

Exploit Impacts

The crypto sector is rife with risk. Lately, it seems that DeFi protocols have been exploited weekly. Exploits refer to when attackers steal funds deposited by investors to the protocol, or take advantage of the protocol for personal gain at the expense of the protocol and its’ users. The avenues used for such exploits are varied and range from highly technical and complex vectors such as re-entrancy, oracle/price manipulation and flash loans to simpler approaches which find and exploit bugs in the protocols’ source code. Examples of both a ‘simple’ and ‘complex’ attack have been broken down and analysed previously.

The impact of a succesful exploit by a malicious attacker is not only the lost investor funds. A succesful attack usually leads to negative price action for the protocols’ token. In some cases the attacks cause losses of such magnitude, that the protocol cannot recover. Due to the complexity of current attack methods, a succesful exploit leads to distrust between the community and developers, and a project with no users will ultimately die. There is a naval saying, “In calm waters, every ship has a good captain”. A succesful attack on a protocol, is most definitely not “calm waters”, but it does offer a unique opportunity to evaluate the protocols’ “captain”.

 

Stormy Seas & Trouble in Paradise

On the 28th of June 2021, the first malicious attack on THORChain occurred. The developer team handled the attack in a timely manner limiting the damage.

The attack siphoned assets worth approximately $140,000 from the protocol. The exact amount of assets and their approximate USD value when siphoned are listed below:

9,352 PERP (58.8K USD)

1.44 YFI (43K USD)

2,438 SUSHI (17K USD)

10.6 ETH (21.2K USD)

A timeline of the attack and the steps taken to contain the damage and limit the attackers’ profits is shown below. The attack was discovered and reported by a user who noticed unusual transactions. With the attack now discovered the network was halted, to make sure any more malicious transactions could not occur, and to protect the protocols’ funds. This led to queued malicious transactions awaiting execution when the protocol would restart. A timeline of how the exploit was handled by the developer team is shown below:

Attack noticed: Unusual transaction reported from user

5 minutes: Developers acknowledge the exploit and inform node operators.

20 minutes: Nodes stop the network, super majority needed (67% or more of nodes).

2 hours: Software fix shipped by developers,

4 hours: Super majority of nodes updated with the fix released.

6 hours: Resume normal operation of the network.

Response and Recovery after the attack

The funds stolen from the vaults have been replaced, with the protocol treasury supplying the replacement funds. Thus, no users/stakers were financially harmed, and the cost of the attack was borne by the protocol and developer team.

When the network resumed normal operation, node operators who did not have full consensus had their bonds slashed (i.e. their stake). This was due to the pausing of the network requiring a supermajority (67% or more of node operators). Nodes not within that supermajority would not have full consensus upon resumption of the network. The slashed bonds were refunded to the relevant nodes.

Lastly, the user who reported the suspicious transactions making the developer team aware of the exploit which was in progress received the appropriate Bug Bounty.

For THORChain to deploy on mainnet, a continuous period of 30 days with no major bugs is required. After this exploit, the 30-day counter  for mainnet launch has been reset . The developer team also has a scheduled audit of their code by TrailOfBits in 14 days, which should help prevent such exploits occurring in the future. The team will also establish bug bounties for finding and reporting bugs and make the community more aware of the existence of these bug bounties. These actions should help to ensure that THORChain remains secure and does not fall victim to other attacks.

Analysing the attack

The root cause of the attack was a line of code that led to a logic error in the Ethereum Bifröst. The line of code below, which is the bug enabling the attack, initialized all non-ETH assets with “ETH”. If the asset returned “ETH” the asset would be skipped.

Asset := common.ETHAsset

For example if the asset was Wootrade (WOO) or yearn.finance (YFI), the above line of code would output “ETH.WOO” or “ETH.YFI”, respectively. If the asset was Ethereum (ETH), the code would output “ETH.ETH”, and the code would skip this asset.

The attacker took advantage of this by creating their own ERC-20 token, ETHOS. When this asset was evaluated by the above line of code, the code returned “ETH.ETH”. This “tricked” the protocol into believing the attackers newly created token, ETHOS, was actually Ethereum (ETH).

The attacker then used their newly created ETHOS token as a substitute for Ethereum when interacting with the Ethereum Bifröst protocol. They exchanged 9.2 ETHOS for 2,438 SUSHI. Similarly, 29 ETHOS were exchanged for 9,352 PERP and 23.8 ETHOS for 1.44 YFI. Lastly, when the attacker was approving another malicious transaction with 10.6 ETHOS, the network was stopped, which led to the attacker receiving a refund for their failed transaction. Due to the bug however the attacker received a refund of 10.6 ETH and not 10.6 ETHOS. This is because the protocol believed ETHOS and ETH to be the same. ETHOS is of course worthless, as it was created by the attacker, solely for the purposes of this attack.

However, when the network was restarted, some malicious transactions were still in the queue to be processed. The attacker had continued sending malicious transactions after the network had been paused. To resolve the issue of the network processing these transactions when restarted, which would result in more funds being stolen; the developers added code into the update that would specifically ignore the queued malicious transactions coming from the attackers addresses.

The above exploit was enabled by the logic error explained above. The attacker could have named their token anything they wished as long as the name structure was ETH**, with the * representing any character [A->Z]. For example, ETHZZ, ETHXY or ETHAA would have worked just as well as ETHOS. As this attack method has now been made public, it is expected that potential attackers will check other protocols for similar coding errors to take advantage off.

Theoretically, protocols being exploited, and the attack methodology used for the succesful exploits being publicly analysed by developers and volunteers, should help protect other protocols from falling victim to similar attack methods. This of course requires the developer teams of other protocols to check their code for these types of vulnerabilities and fix them before an attacker finds them and exploits them. Looking forwards, it is expected that exploits will continue to occur as the risk/reward is extremely beneficial for the attackers. In the present attack, the attacker only had to pay gas fees for their malicious transactions to make off with a hefty profit, which would have been significantly larger if not for the vigilance of a user and the swift action of the developers and node operators.

A protocol falling victim of an exploit is not a red flag, as all protocols will most probably have vulnerabilities which may have not been discovered yet. What is important is how the developer team and community react to the attack and their subsequent actions, something the THORChain team did exceptionally well. 

 

 

Sign up for our FREE mailing list

Join 12,590 others now and get actionable research and analysis sent directly to your inbox.

Post a Comment

GET YOUR CRYPTO DAILY BRIEF

Delivered daily, straight to your inbox.