原文作者：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）之类的东西。你所要做的就是找到一个有效的交易，用你的地址找到/替换对方的地址，然后重新广播。
