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，以及大多數依賴代幣授權 → 呼叫這種使用者流程的 DeFi 應用程式。

ERC1271 簽章重放漏洞

大多數 SCA 都採用上述參考實作來實作 ERC-1271。從工程角度來看，這是一種輕量的實作方式，也讓客戶端整合更加容易，因為我們可以沿用 signTypedData、signMessage、eth\_signTypedData\_v 及 personal\_sign 等方法，就像用在 EOA 上一樣。

然而，若同一個地址擁有多個 SCA，且應用程式沒有納入該次互動的來源地址，那麼同一個簽章便會對該應用程式的兩個帳戶都有效。

由於此漏洞只有在 SCA 與應用程式組合的情況下才會發生，此漏洞的嚴重程度取決於該互動適用於哪些應用程式。我們首先調查的應用程式是 Permit2，這是 Uniswap 建構的公共基礎設施，能改善整個產業中 ERC20 代幣授權流程的安全性與使用者體驗，因此目前被廣泛使用。

下方的程式碼區塊顯示了 Permit2 簽章所涵蓋的結構。值得注意的是，address owner（即代幣被提取的地址）並未被簽章涵蓋，而是在呼叫 Permit2 時作為參數傳入。

攻擊者可能利用此簽章重放漏洞的方式大致如下：

Bob 向擁有 n 個 SCA 的 Alice 請求支付 X 個代幣，並要求透過 Permit2 完成
Alice 簽署第一個 permit 後，Bob 便可在 Alice 的所有 SCA 上重放此 permit，總共收到 n X 個代幣。

在此過程中，我們製作了一個概念驗證來確認此漏洞，可於此處找到：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 不受此攻擊向量影響。