Verichains reports a flawed upgrade deployment script caused the $10M Ronin bridge exploit on August 6, according to the blockchain security firm.
The upgrade deployment script did not call for an essential initialization function, which resulted in a zero vote threshold and the ability for anyone to withdraw “without signature.”
According to Verichains, the update lowered the voting bar for validators to zero, effectively enabling any user to leave the bridge “without signature.” Later, the bot’s owner gave the Ronin team the money back.
Verichains’ investigation exposed the hazards consumers incur when interacting with upgradeable intelligent contracts. The protocol might have lost the entire money if the attacker had avoided the frontrunner by paying more for petrol.
A blockchain network called Ronin is devoted to hosting Web3 games. The play-to-earn monster breeding game Axie Infinity, which peaked in 2022 with over 2 million players, is why it is most famous. Players of the Ronin game use the bridge to move money between Ethereum and Ronin.
Verichains’ report states that the bridge uses the variable mimimumVoteWeight to stop users from taking money that isn’t theirs. This variable specifies the minimum number of validators that must approve each transaction. TotalWeight is an input variable used in the computation of minimumVoteWeight.
Prior iterations of the bridge included a distinct contract named “MainchainBridgeManager,” which housed total weight. Instead of keeping this variable in the other contract, the developers wished to relocate it to the bridge’s internal storage when they developed the new upgrade. This implied that they would have to initialize the variable at deployment time, assigning the value from the prior iteration to TotalWeight.
Regretfully, this is the point at which the upgrade went wrong. Verichains claims that the “initialize” functions the Ronin developers wrote were intended to be called at deployment time. The version numbers of these functions varied. The necessary initialization of total weight was present in the third version. However, only version 4 was called when the developers wrote the deployment script, leaving the total weight at its initial zero value.
Following this update, users could demonstrate their right to withdraw without providing validators with signatures. Since “it met the minimumVoteWeight condition (which was 0 due to uninitialized),” they were able to withdraw “without signature.”
Composable Security smart contract auditor Damian Rusinek provided more information about the circumstances that led to the attack in a post on August 7 on X. The attacker signed the document using an address that ended with B849f, according to Rusinek. However, the bridge workers said this address was “not on the list.” Because “the minimum votes of the operators was 0,” it was not required to be on the list of bridge operators. As a result, “just ONE signature was needed, and it could be any legitimate signature.”
In an August 6 X post, Ronin stated that the vulnerability was caused when the upgrade “introduced an issue leading the bridge to misinterpret the required bridge operators vote threshold to withdraw funds,” albeit it did not go into as much detail as either Verichains or Rusinek.
Blockchain evidence reveals that “Frontrunner Yoink,” an MEV bot, front-ran this attack transaction and was influential in draining the bridge of nearly $10 million in cryptocurrency. The bot is most likely “simulated changing address and amount and using their signature,” according to Rusinek. The transaction was completed after this simulation demonstrated that the exploit would function.
The owner of the frontrunner Yoink returned most of the money the same day, and the Ronin team said they could retain $500,000 as a bug bounty.
Users of Ronin had a near miss with the August 6th vulnerability. Fortunately, an honest white hat operator owned an MEV bot that spearheaded the attack. However, the fact that the attack was so close to being successful highlights how dangerous upgradeable cross-chain bridges may be.
According to specific networks, this issue will be resolved when Ethereum layer 2s reach “stage 2,” all updates are postponed for at least seven days following launch. Opponents contend that it is taking too long to reach this point and might never end.
