一名 Ethereum 用户在攻击者利用 Safe 模块执行路径，将资产重定向至由攻击者控制的 Uniswap v4 流动性池后，损失了约 773 万美元的 rsETH。

受影响的 Safe 地址（0x40e93a52f6af9fcd3b476aedadd7feabd9f7aba8）于 9 月 15 日早些时候遭到攻击。安全监控确认有两笔交易导致了此次损失。现有证据表明，问题源于该钱包的自定义模块及其与恶意 Hook 的交互，而非 Safe 核心智能账户合约存在漏洞。

自定义模块将资产路由至恶意资金池

攻击者利用公开的 keeper multicall，调用了附加在该账户上的自定义 Uni V4 LP Safe 模块。该执行过程将流动性路由至一个由攻击者控制的 Hook 创建的 Uniswap v4 资金池，使恶意路由逻辑能够访问头寸中的资产。

随后，该 Hook 将受害者的 aEthrsETH 头寸转换为可转移的 rsETH。aEthrsETH 代表存入 Aave 的 rsETH，因此攻击者首先需要将该头寸从 Aave 的收据代币形式中转出，之后才能提取底层 rsETH。

Safe 的模块架构允许经过授权的扩展独立于正常的多签流程执行交易。模块可以自动化复杂的 DeFi 操作，但 Safe 警告称，模块属于安全关键组件，因为已启用的恶意或存在漏洞的模块可以代表账户执行任意交易。Safe 关于模块的文档可参见此处。

由于公开的 keeper multicall 可以调用该账户的自定义模块，相关安全边界不仅限于 Safe 的签名者流程，还延伸至模块的授权和交易逻辑。对于类似的 DeFi 账户，仅审查 Safe 合约无法完整说明账户当前的执行面。

此次攻击并未入侵 Safe 的核心多签合约、签名者密钥或 Ethereum 本身。已确认的故障路径涉及该账户的自定义模块和由攻击者控制的 Uniswap v4 Hook。5 月发生的 SquidRouterModule 攻击也出现了类似情况：该漏洞耗尽了 Ethereum 和 Base 上 86 个 Safe 账户的资金，但底层 Safe 合约并未处于已确认的故障路径中。

MEV 机器人截获资金提取

该攻击交易在区块内被一个与某地址相关联的 MEV 操作截获，Etherscan 将该地址标记为 MEV Frontrunner Yoink。

该机器人抢先于原始提取交易执行，并在攻击者无法按提交内容完成操作前，捕获了具有盈利性的交易路径。由于底层恶意执行已经成功，受害者仍然损失了 rsETH；但交易排序改变了最终由哪个外部地址捕获大部分被提取价值。

在交易完成后，该 Safe 仅剩下来自恶意资金池的流动性头寸 NFT，而不再拥有交易前持有的、由 rsETH 支持的头寸。

rsETH 再次成为安全关注焦点

rsETH 是 Kelp DAO 的流动性质押代币，目前仍广泛集成于 Ethereum 的借贷和流动性市场中。该代币在 Aave 中的使用形成了此次钱包被耗尽事件涉及的 aEthrsETH 抵押品。

Kelp 的代币今年早些时候也经历过一次重大安全事件。4 月发生的 Kelp DAO 攻击从跨链基础设施中释放了约 2.92 亿美元的 rsETH，并在 DeFi 借贷市场造成了大规模后续风险敞口。

9 月 15 日的损失是一起独立事件。现有证据集中指向单个 Safe 的模块执行、由攻击者控制的 Uniswap v4 Hook，以及由此导致的钱包 Aave 支持的 rsETH 头寸被转换。尚未确认 Safe、Aave、Kelp DAO 或 rsETH 代币合约遭到更广泛的入侵。

来源：Crypto Adventure。