被盜1.9億美元，史上最混亂的ENS實名群毆

TL;DR

在一次升級中合約將 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）之類的東西。你所要做的就是找到一個有效的交易，用你的地址找到/替換對方的地址，然後重新廣播。

原文連結