ERC-1271 签名重放漏洞

最后更新：2024年3月29日2 分钟阅读

2023年10月27日，Alchemy 发现了一个 ERC1271 合约签名重放漏洞，该漏洞影响了大量智能合约账户(SCA)，并导致与若干应用程序交互时存在风险。受影响的 SCA 包括我们的 LightAccount 和 OKX 的 SmartAccount，我们识别出存在风险的应用交互包括 Permit2 和 Cowswap。我们及时将此问题告知了各受影响的 SCA 和应用方，并发现独立安全研究员 curiousapple 在一个月前就已发现了同样的漏洞。我们与 curiousapple、Frangio(ERC1271 作者)、ERC4337 团队以及其他 SCA 技术专家合作制定了修复方案。截至目前，没有资金处于风险之中，对应用的影响也相当有限。所有涉及的 SCA 要么已确认该风险，要么已发布修复。

技术细节

ERC-1271 合约签名

在 Ethereum 及所有基于 Ethereum Virtual Machine (EVM) 的链上，存在两种不同类型的账户——外部拥有账户(EOA)和智能合约。EOA 能够使用其关联的 ECDSA 密钥对中的私钥对消息进行签名以完成认证。然而，由于智能合约在创建时会获得一个预先确定的地址，它并没有可直接用来对消息签名的私钥。

为了解决这个问题，ERC-1271 合约签名标准于 2018 年被提出。按照该标准，智能合约可以实现关于何为有效签名的限制/检查逻辑，应用可以调用 contract.isValidSignature 来验证某项操作是否经过该智能合约授权。

在智能合约账户(SCA)的场景下，ERC-1271 非常实用，它使得 SCA 用户可以像 EOA 用户一样使用基于签名的应用。这些应用包括 OpenSea，以及大多数依赖代币授权(token approval)→调用这一使用方式的 DeFi 应用。

ERC1271 签名重放漏洞

大多数 SCA 都是使用上文所示的参考实现来实现 ERC-1271 的。从工程角度看，这是一种轻量级实现，它使得客户端集成更加简便，因为我们可以像对待 EOA 一样复用 signTypedData、signMessage、eth\_signTypedData\_v 和 personal\_sign 等方法。

然而，如果同一地址拥有多个 SCA，且应用没有将交互的来源地址纳入签名范围，那么同一个签名在该应用中对这两个账户都是有效的。

由于该漏洞只有在 SCA 与应用组合的情况下才会出现，其严重程度取决于该交互能与哪些应用配合使用。我们首先研究的应用是 Permit2，它是由 Uniswap 构建的公共基础设施，用于提升整个行业中 ERC20 代币授权流程的安全性和用户体验，因此目前被广泛使用。

下方代码块展示了 Permit2 签名所覆盖的结构体。值得注意的是，address owner（即代币被转出的地址）并未被签名覆盖，而是作为参数在调用 Permit2 时传入。

攻击者利用该签名重放漏洞的过程大致如下：

Bob 向拥有 n 个 SCA 的 Alice 请求支付 X 个代币，并要求通过 Permit2 完成。
在 Alice 签署第一个 permit 后，Bob 可以在 Alice 的所有 SCA 上重放该 permit，从而共获得 n X 个代币。

在此过程中，我们制作了一个概念验证(proof-of-concept)来确认该漏洞。相关代码可在此处找到：replay-sig-poc

影响

在调查过程中，我们发现：

多个 SCA 存在风险。
除了我们的 LightAccount 外，受影响的 SCA 还包括 Zerodev 的 Kernel、Biconomy、Soul Wallet、eth-infinitism 针对 Gnosis Safe 的 EIP4337Fallback、AmbireAccount、OKX 的 SmartAccount、Argent 的 BaseWallet，以及 Fuse Wallet。
多个应用存在风险：
Permit2——基于签名的转账可被重放。但 Permit2 的大多数用途是转发给 Universal Router，要利用这一点还需要 Universal Router 本身存在一个独立的严重漏洞。
Cowswap——使用 ERC-1271 路径的交易可被重放。由于签名覆盖了 address recipient，因此这里的风险最多是价格过时和/或一定的 MEV 损失。
Gnosis Safe 不受此攻击向量影响。