检查您的安全钱包模块：一个模块如何在没有签名的情况下转移 770 万美元

2026 年 9 月 15 日，一个以太坊钱包在无需单一所有者签名的情况下损失了约 2,882 rsETH。该钱包是安全多重签名的，这种设计特别安全，因为多个密钥必须一起签名。无论如何，余额都会通过所有者自己启用的模块耗尽。如果您使用智能合约钱包，则此案例之后的任务是小而具体的：查看您的钱包中启用了哪些模块，并删除您不再需要或无法再解释的任何内容。本文解释了模块在技术上允许执行的操作、9 月 15 日的攻击是如何展开的，以及如何在几分钟内自行运行检查。通过该界面无需支付任何费用。只有删除一个模块才是一笔交易，并且需要常规数量的签名。安全模块解释：模块在智能合约钱包中可以做什么安全模块是它自己的智能合约，钱包永久允许代表其执行交易，而无需通常数量的所有者签名。这不是设计的缺陷，而是设计的重点。任何想要运行自动工资单、定期再平衡例程或流动性策略的人都不能让每个步骤都由三个人签字。因此钱包将该部分委托给合约。从技术上讲，这通过函数 execTransactionFromModule 或其具有返回值的变体运行。启用的模块会调用它，钱包会执行模块指示的任何内容。过程中未规避签名阈值；这条路径根本没有提供它。 Safe 文档以异常清晰的方式阐明了结果：模块可以执行任意交易，只应添加经过审核和可信的模块，并且恶意模块可以完全接管钱包。它在智能帐户模块的官方 Safe 文档中进行了阐述。有两个属性使模块对攻击者有吸引力。首先，它们是永久性的：一旦激活，模块就会保持活动状态，直到有人明确将其关闭。其次，它们每天都是看不见的。您在发送时看不到它们，在接收时看不到它们，也不在余额中看到它们。它们只会出现在您寻找它们的地方。 9 月 15 日的攻击：DELEGATECALL 如何释放 2,882 rsETH 流出量于 UTC 时间 04:38:47 到达区块 25980525。它袭击了持有 rsETH 杠杆头寸的单个 Safe 钱包，rsETH 是来自 Kelp DAO 的流动性重新抵押代币。安全公司 Blockaid 和 PeckShield 最先报告了该事件；他们的损失数字略有不同，在 773 至 781 万美元之间。这个数量比美元数字更精确：2,882.37 rsETH。故障发生在钱包用于 Uniswap v4 流动性策略的定制模块中。该模块提供了一个入口点，将调用者提供的数据未经检查地直接传递到钱包函数 execTransactionFromModuleReturnData，其操作标志为 1。标志 1 代表 DELEGATECALL，这是决定性的点。 DELEGATECALL 一句话 DELEGATECALL 在存储中以您自己的合约身份执行外部程序代码，就好像钱包自己编写了该代码一样。谁能触发这个调用，谁就不是针对钱包，而是作为钱包。由于模块的入口点对外部调用者没有访问控制，因此任何地址都可以访问它。由于该模块已在钱包中启用，因此钱包无需进一步检查。所有者列表和签名阈值在此序列中不再发挥任何作用。 Uniswap v4 hook 和 keeper 多重调用：攻击者的逐步路线该链经历了几个阶段，并始终使用设计为便利功能的功能。攻击者首先调用可公开访问的 keeper 多重调用函数。守护者是保持策略运行的服务，例如通过调整仓位；他们的呼叫通常是故意开放的，以便任何人都可以触发它们，并且策略永远不会停止。通过该调用，攻击者将钱包的流动性模块引导至他自己控制的 Uniswap v4 池。 Uniswap v4 允许所谓的挂钩，即与池中的某些事件一起自动运行的自定义代码。这个池子里的钩子属于攻击者。最后一步是打开包装。钱包中持有的不是裸露的 rsETH，而是 aEthrsETH，即借贷市场 Aave 的计息包装内的 rsETH。在这种形式下，它不能被简单地带走。挂钩将持有的资产解压成可自由转让的 rsETH，这样余额就可以移动了。模块保持活动状态，直到有人将其关闭。这正是启用合约列表值得一看的原因。 MEV 机器人而不是攻击者：为什么“yoink”得到了钱攻击者将他的交易发送到公共内存池中，这是任何人都可以检查的未确认交易的等待区域。一个名为“yoink”的 MEV 机器人正在那里阅读，重建相同的序列并首先进入同一块。 2,882.37 rsETH 落在了属于该机器人的地址上，按照执行时的估值，价值约为 780 万美元。对于被抢的钱包来说，这没有任何改变。对你来说，它改变了两件事。首先，这个案例表明，模块中的公开弱点不仅仅与发现它的攻击者有关：一旦序列公开可见，任何足够快的人都可以重建它。其次，它解释了为什么这里的追回前景与典型的盗窃不同。 Kelp DAO 于世界标准时间 06:03 暂停接收地址 24 小时，同时表示其自己的合约未受影响，rsETH 仍得到充分支持。故障发生在单个钱包的定制模块中，而不是在代币中，也不在协议中。

这不是第一个案例：2026 年 5 月 25 日的 SquidRouterModule 漏洞 任何将 9 月事件视为一次性事件的人都低估了这一模式。 2026 年 5 月 25 日，名为 SquidRouterModule 的模块遭到攻击。据报道，以太坊和 Base 上至少 86 个 Safe 钱包受到影响；根据分析，损失估计为 320 万美元，换句话说，300 笔交易造成的损失接近 400 万美元。整个过程持续了大约两个小时。攻击的路线不同，结果却是一样的。攻击者没有使用 DELEGATECALL 条目，而是使用函数executeSameChainActions() 并将自己冒充为授权代表。由于该模块已经在受影响的钱包中拥有深远的权利，因此钱包合约将伪造的指令视为真实指令。提供商Squid公开表示，被利用的合约只是与自己的产品架构共用一个名称，与其没有任何联系，其自己的用户和集成商没有受到影响。从这两个案例中可以得出同样的教训。如今多重签名的最弱点很少是签名阈值。它存在于钱包在某个时候允许绕过该阈值的合约中。在选择托管解决方案时，这一标准几乎不会出现在任何产品描述中；我们的硬件钱包比较根据您对签名的控制程度对设备进行排名。检查安全模块：如何在五分钟内查看启用的内容 检查本身并不引人注目，这正是它经常被撤消的原因。有两条路线，它们回答相同的问题。通过界面：设置和模块列表 在安全界面中打开钱包，然后转到设置中的模块条目。它列出了该钱包启用的合约地址。对于绝大多数私人钱包来说，那里什么都没有，这是一个很好的例子。如果列出了某些内容，请一次浏览每个地址并回答三个问题：您还记得启用此模块的目的吗？您现在还在使用相关应用程序吗？您能否找到该地址的可追踪提供商并附上审计报告？如果其中任何一个问题仍然存在，则该模块属于要删除的列表。这里的举证责任在于保留方。一个你无法再说出其用途的模块无论如何都会继续工作。通过合约： getModules 和 isModuleEnabled 任何想要独立于接口了解的人都可以直接询问钱包合约。读取函数 getModules 返回所有启用模块的地址，isModuleEnabled 对于单个地址是否启用回答“是”或“否”。这两个调用都是纯读取调用：它们免费，不需要签名，并且可以通过任何区块浏览器或 SDK 运行。合同路线具有实际优势。它向您显示链的状态，而不是应用程序的呈现。如果界面由于某种原因无法显示模块，它仍会列在此处。四项保障措施中的三项成立：对于模块，一个开放点就足够了，因为每个开放点都可以单独行动。删除模块：为什么disableModule需要您的签名阈值关闭通过钱包函数disableModule运行。与观看不同，这是真实的交易。它需要支付网络费用，并且需要所有者的定期签名。在安全界面中，您可以在刚刚阅读的同一模块列表中启动该进程；然后业主会像对待任何其他交易一样进行确认。有一个奇怪的地方值得了解：模块以链表的形式存储在合约中，因此关闭也需要前一个条目的地址。接口和 SDK 自行插入此值。任何手动构建交易的人都必须确定它，否则调用就会失败。安排在网络费用较低时进行删除，并在一个会话中完成多个模块。这不适用于普通检查：它不需要花费任何费用并且可以立即进行。