The $10 million Ronin bridge exploit on Aug. 6 was caused by a faulty upgrade deployment script, according to a report from blockchain security firm Verichains. 

The upgrade reduced the voting threshold for validators to zero, essentially allowing any user to withdraw from the bridge “without signature,” Verichains stated. 

 The bot’s owner later returned most of the funds to the Ronin team.

Verichains’ analysis lays bare the risks that users take when they interact with upgradeable smart contracts. The protocol could have lost the full amount had the attacker paid more in gas and, therefore, avoided the frontrunner.

Ronin is a blockchain network dedicated to hosting Web3 games. It is most well-known for being the home of Axie Infinity, a play-to-earn monster breeding game that claimed to have over 2 million players during its peak in 2022. Ronin game players use the bridge to transfer funds between Ethereum and Ronin.

According to Verichains’ report, the bridge relies on the variable mimimumVoteWeight to prevent users from withdrawing funds that don’t belong to them. Each transaction must be authorized by a minimum number of validators set by this variable. When minimumVoteWeight is computed, it uses another variable, totalWeight, as an input.

In earlier versions of the bridge, totalWeight existed on a separate contract, called “MainchainBridgeManager.” When the developers created the new upgrade, they wanted to move this variable to the bridge’s own internal storage, instead of leaving it in the other contract. This meant that they needed to initialize the variable at the moment of deployment, setting TotalWeight to the value it had been in the previous version.

Unfortunately, this is where the upgrade went horribly wrong. According to Verichains, the Ronin developers wrote several different “initialize” functions that were supposed to be called at the moment of deployment. Each of these functions had a different version number. The third version contained the crucial totalWeight initialization. But when the developers wrote the deployment script, they called only version 4, leaving totalWeight at its default zero value.

After this upgrade, users no longer needed to submit signatures to validators to prove their right to withdraw. They could withdraw “without signature,” since “it met the minimumVoteWeight condition (which was 0 due to uninitialized).”

In an Aug. 7 post to X, Composable Security smart contract auditor Damian Rusinek gave further detail on what allowed the attack to occur. Per Rusinek, the attacker provided a signature from an address ending in B849f. However, this address was “not on the bridge operators list.” It did not need to be on the bridge operators list because “the minimum votes of the operators was 0.” Therefore, “only ONE signature was required and it could [be] ANY valid signature.”

Although it did not go into as much detail as either Verichains or Rusinek, Ronin confirmed in an Aug. 6 X post that the exploit was caused when the upgrade “introduced an issue leading the bridge to misinterpret the required bridge operators vote threshold to withdraw funds.”

Blockchain data shows that this attack transaction was front-run by an MEV bot called “Frontrunner Yoink,” who successfully drained over $10 million worth of cryptocurrency from the bridge. According to Rusinek, the bot most likely “simulated changing address and amount and using their own signature.” It then submitted the transaction once this simulation proved that the exploit would work.

Related: Ronin Network exploited for $9.8M in ETH, white hat hacker suspected

Frontrunner Yoink’s owner returned most of the funds on the same day, and the Ronin team announced that they would be allowed to keep $500,000 worth as a bug bounty.

Ronin users suffered a close call with the Aug. 6 exploit. Luckily, the attack was front-run by an MEV bot whose owner was an honest white hat operator. However, the fact that the attack came so close to succeeding exposes the risky nature of upgradeable cross-chain bridges.

Some networks claim this problem will be eliminated when Ethereum layer 2s reach “stage 2” and all upgrades are delayed for at least seven days after initiation. However, critics claim that the process of reaching this stage is taking too long and may never be completed.

Magazine: Weird ‘null address’ iVest hack, millions of PCs still vulnerable to ‘Sinkclose’ malware: Crypto-Sec