Over $150 million loss, cross-chain bridge protocol Nomad hacking analysis analysis

Original author:Samczsun, Partner at Paradigm

Compilation of the original text: The Way of DeFi

Compilation of the original text: The Way of DeFisamczsunOn August 2, the cross-chain bridge protocol Nomad was attacked, and more than $150 million in user funds were transferred by hackers. Paradigm partner

This security incident was analyzed.

Nomad just lost $150 million in one of the messiest hacks Web3 has ever seen. So how exactly did this happen and what is the root cause? Allow me to take you behind the scenes of this attack.

It all started with a @spreekaway tweet shared by @officer_cia in the ETHSecurity telegram channel, and while I didn't know what was going on at the time, the amount of assets leaving the Nomad cross-chain bridge is clearly not a good sign.

My first thought was that there is some misconfiguration of the token's decimal point. After all, the cross-chain bridge seems to be running a "send 0.01 WBTC, get 100 WBTC back" promotion.

https://moonscan.io/tx/0xcca9299c739a1b538150af007a34aba516b6dade1965e80198be021e3166fe4c

https://etherscan.io/tx/0xa5fe9d044e4f3e5aa5bc4c0709333cd2190cba0f4e7f16bcf73f49f83e4a5460

However, after some painful manual digging on the Moonbeam network, I confirmed that the Moonbeam transaction did cross-chain 0.01 WBTC, but somehow the Ethereum transaction cross-chained 100 WBTC.

Furthermore, WBTC cross-chain transactions do not actually prove anything. It just calls `process` directly, which, arguably, is very bad to be able to process a message without proving it first

At this time, there are two possibilities, either the proof was submitted separately in an earlier block, or there is a serious loophole in the Replica contract. However, there is absolutely no sign that anything has been proven recently.

That leaves only one possibility, there is a fatal loophole in the Replica contract. So what is going on? A quick look shows that the committed message must belong to an acceptable root, otherwise the check on line 185 will fail.

Fortunately, there is an easy way to check this assumption. I know the uncertified message root will be 0x00 because message[_messageHash] will be uninitialized. All I have to do is check if the contract will accept this.

Why……

It turns out that during a routine upgrade, the Nomad team initialized the root of trust to 0x00. To be clear, it is a common practice to use zero as an initialization value. Unfortunately, in this case, it has the small side effect of automatically validating every message.

This is what makes hacking so messy, you don't need to know anything like Solidity or Merkle trees, all you have to do is find a valid transaction, find/replace another person's address with yours, and rebroadcast it.

Overall, a routine upgrade marked the zero hash as a valid root, the effect of which was to allow spoofing of messages on Nomad, attackers abused this feature to copy/paste transactions, and quickly drained dry in a frantic melee Funding for this cross-chain bridge.