原文作者：Samczsun
原文編譯：TechFlow intern
在一次升級中合約將0x00 標記為有效的根，這就導致了Nomad 充滿了虛假信息。攻擊者利用這一點來複製/粘貼有效的交易地址，在混亂中，跨鏈橋的資產被迅速耗盡了。
剛剛發生的Nomad事件是我在Web3中見過的最混亂的黑客攻擊之一，截至目前被榨乾了超過1.5 億美元。這究竟是如何發生的，根本原因是什麼？請允許我帶你了解幕後情況。
這一切都始於CIA Officer在ETHSecurity Telegram 頻道分享Spreek的推文，雖然我當時不知道發生了什麼，但大量的資產離開跨鏈橋顯然是一個不好的跡象。
我的第一個想法是，Token 小數點的配置有誤。畢竟，從我的視角看來，似乎跨鏈橋正在運行一個「發送0.01 WBTC，返還100 WBTC」的促銷活動。
開始還不相信，然而，在Moonbeam 網絡上進行了一些人工挖掘後，我確認，事實的確是此，從Moonbeam 只轉出了0.01 WBTC，但以太坊上卻不知為什麼收到了100 WBTC。
此外，WBTC 這次橋接交易實際上並沒有Prove 這一步驟，它只是直接調用了`Process`。只能說，在沒有證明的情況下就能處理一個消息是非常不好的。
在這種情況有兩種可能，要么證明是在較早的區塊中單獨提交的，要么就是Replica 合約出了極大的問題。然而，完全沒有跡象表明最近有什麼信息被單獨證明了。
所以，就只剩下一種可能——Replica 合約中存在致命的缺陷，但怎麼會呢？通過快速瀏覽信息發現了，提交的消息必須屬於可接受的根，否則，第185 行的檢查會失敗。
幸運的是，有一種簡單的方法可以檢查這個假設。我知道一個未被證明消息的根是0x00，因為messages[_messageHash] 顯示未初始化，我所要做的就是檢查合約是否會接受這個根。
合約接受了......
事實證明，在升級期間，Nomad 團隊將可信根初始化為0x00。說白了，使用0 值作為初始化值是一種常見的做法。不幸的是，在這種情況下，它有一個很小的副作用，即會自動驗證每一條消息。
這就是此次事件如此混亂的原因——你不需要知道Solidity 或默克爾樹（Merkle Trees）之類的東西。你所要做的就是找到一個有效的交易，用你的地址找到/替換對方的地址，然後重新廣播。
APP 
