这就是让协议团队夜不能寐的那种漏洞。 在ZKSwap上发生了500万美元的漏洞,原因是一个语句放错了地方。 以下是对事件发生经过的深入分析,以及链上监控如何能够阻止它的探讨。 🧵
1/ 在7月9日,GMX被黑客攻击,损失了4200万美元。 但那天发生了其他事情,几乎没有人注意到:ZKSwap的桥接被悄悄抽走了500万美元。 有趣的是?没有涉及任何复杂的利用。只是一个关键功能什么也没做。
2/ ZKSwap 是一个基于以太坊的 zk-rollup。 像许多 rollup 一样,它使用桥接在 L1 和 L2 之间移动资产。 作为一种保护措施,桥接包括一个“出埃及模式”,用户可以在不需要操作员的情况下找回资金。 理论上,这是个好主意。在实践中…
3/ Exodus模式允许用户手动证明他们在最后验证的L2状态中拥有代币。 这是一种后备机制:无信任、自我保管、非交互式。 但ZKSwap的实现有一个致命的缺陷:负责验证证明的功能没有验证任何内容。 字面意思。
4/ 这是本该阻止攻击的代码 👇 乍一看,它看起来像一个真正的 zk-proof 验证器。 但仔细看看第一行:return true; 就这样。没有其他代码运行。
5/ 结果是什么?每个提款“证明”(无论多么虚假)都通过了验证。 合同接受了关于代币余额的任意声明……并将其记入账目,就好像它们是真实的。 它将一个无信任的后备机制变成了一个无防备的水龙头。
6/ 攻击者不需要复杂的漏洞利用——只需对 exit() 进行重复调用,使用虚构的数据。 他们绕过了余额检查,跨多个代币进行提款,并利用弱的无效化逻辑来避免被检测。 这一切都在合约声明的同时进行:✅
7/ 这并不是某个晦涩的边缘案例。 这是资产恢复的核心逻辑,完全开放。 而且由于 Exodus 模式很少被触发,这条破损的路径几个月来都未被注意到…
8/ 这里是应该引发警报的事项: • 在长时间不活动后触发的 Exodus 模式 • 同时发生的数十个提款请求 • 提款余额突然激增 所有这些都是可见的,并且可以通过实时链上监控来阻止。
9/ 那么教训是什么? • 紧急代码仍然是生产代码 • 如果备用路径不起作用,那就没有帮助 • 实时监控不是可选的,而是生存关键
查看原文
3.78万
422
本页面内容由第三方提供。除非另有说明,欧易不是所引用文章的作者,也不对此类材料主张任何版权。该内容仅供参考,并不代表欧易观点,不作为任何形式的认可,也不应被视为投资建议或购买或出售数字资产的招揽。在使用生成式人工智能提供摘要或其他信息的情况下,此类人工智能生成的内容可能不准确或不一致。请阅读链接文章,了解更多详情和信息。欧易不对第三方网站上的内容负责。包含稳定币、NFTs 等在内的数字资产涉及较高程度的风险,其价值可能会产生较大波动。请根据自身财务状况,仔细考虑交易或持有数字资产是否适合您。