A summary of THORChain's ETH router exploits post-mortem.
During the past few weeks, THORChain suffered two exploits on its ETH router. In both cases, the attackers managed to exploit a Bifrost interface. It was tricked into reporting receiving assets it had not.
To get a better understanding of what has happened, the THORChain team issued a post-mortem on their Medium page.
Understanding how these events unfolded will help both the team and community to identify and prevent similar events from happening in the future.
After the network was halted, the team and community members came together to create a 5-Pronged Plan that will solve insolvency and security issues.
The attacker managed to deploy a contract that was sitting in front of the router, which was able to maliciously call the deposit() function.
The attacker deposited fake ETH into the contract many times, swapping to other ERC20 tokens. This lead to an artificial rise in prices which consequently led to paying large amounts of fees. All of this enabled the attacker to siphon out ~4,200 ETH by forcing a refund using a deliberately bad memo.
Following this incident, a premature return to trading during a high pressure update rollout caused an additional loss of funds by arbitragers.
Impact: $8m USD
A fix was issued to patch the above-mentioned ETH exploit but it was unknown at the time that another critical vulnerability was present in the ETH router.
An attacker managed to create a fake router and initiate a deposit event with a malicious memo. The fix that was deployed also contained logic to divert the arb transactions to the treasury since the system was insolvent and could not fulfill them. In short, the attacker exploited the returnVaultAssets() function.
The fake deposit event was intercepted by the Bifrosts as a normal deposit and refunded to an attacker due to a bad memo definition.
Impact: ~$8m USD
In the post-mortem, the THORChain team outlined five key problems that need to be addressed in order to make the network operational and more secure.
Implementing all of these fixes in full will require 2-3 months of development work, but the network can be brought back online in stages.
View our Operation Roadmap for up-to-date timelines.