$190 million stolen, the most chaotic ENS brawl in history
The original author is Samczsun
The TechFlow Intern
TL; DR
The contract marks 0x00 as a valid root in an upgrade, which causes the Nomad to be filled with misinformation. Attackers take advantage of this to copy/paste valid transaction addresses, and in the chaos, assets across the chain bridge are quickly depleted.
Nomad is one of the messiest hacks I've seen on Web3, draining over $150 million so far. How exactly did this happen, and what are the root causes? Allow me to take you behind the scenes.
It all started.CIA OfficerShare on ETHSecurity Telegram channel.Spreek While I didn't know what was going on at the time, a large number of assets leaving the chain bridge was clearly a bad sign.
我的第一个想法是，Token 小数点的配置有误。毕竟，从我的视角看来，似乎跨链桥正在运行一个 「发送 0.01 WBTC，返还 100 WBTC」的促销活动。
I didn't believe it at first, however, after some manual mining on the Moonbeam network, I was able to confirm that this was indeed the case. Only 0.01 WBTC was transferred from Moonbeam, but for some reason 100 WBTC was received from Ethereum.
In addition, the bridge transaction of WBTC does not actually have the step of Prove. It simply calls Process directly. Suffice it to say, being able to process a message without proof is a bad idea.
In this case, there are two possibilities: either it turns out that the Replica contract was submitted separately in an earlier block, or there is a major problem with the Replica contract. However, there is absolutely no indication that any information has been individually proven recently.
So that leaves only one possibility -- that there are fatal flaws in the Replica contract. But why? A quick look at the information reveals that the submitted message must belong to an acceptable root, otherwise the check on line 185 will fail.
Fortunately, there is an easy way to check this hypothesis. I know that the root of an unproven message is 0x00 because messages[_messageHash] shows uninitialized, and all I have to do is check to see if the contract will accept the root.
The contract was accepted......
It turns out that during the upgrade, the Nomad team initialized the trusted root to 0x00. To put it bluntly, it is common practice to use a value of 0 as an initialization value. Unfortunately, in this case, it has the minor side effect of automatically validating every message.
That's why this event is such a mess -- you don't need to know Solidity or Merkle Trees or anything like that. All you have to do is find a valid deal, find/replace the other party's address with your address, and re-broadcast.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
