ERC-1271署名リプレイ脆弱性

最終更新日: 2024年3月29日1分で読めます

2023年10月27日、Alchemyは多数のスマートコントラクトアカウント(SCA)に影響するERC1271コントラクト署名リプレイの脆弱性を発見し、複数のアプリケーションとのインタラクションにリスクが生じることが分かりました。影響を受けたSCAには当社のLightAccountとOKXのSmartAccountが含まれ、リスクがあると特定したアプリケーションとのインタラクションにはPermit2とCowswapが含まれていました。この問題を影響を受ける各SCAおよびアプリケーションに速やかに報告したところ、独立したセキュリティ研究者であるcuriousappleが1か月前に同じ脆弱性を発見していたことが判明しました。私たちはcuriousapple、Frangio(ERC1271の著者)、ERC4337チーム、および他のSCA技術専門家と協力して修正にあたりました。現時点で資金へのリスクはなく、アプリケーションへの影響もかなり限定的です。関与したすべてのSCAは、リスクを認識するか、修正を出荷済みです。

技術詳細

ERC-1271コントラクト署名

EthereumおよびすべてのEthereum Virtual Machine (EVM) 互換チェーンには、Externally Owned Accounts (EOA) とSmart Contractsという2種類の異なるアカウントがあります。EOAは、関連付けられたECDSA鍵ペアの秘密鍵で署名することでメッセージを認証できます。しかし、スマートコントラクトはコントラクト作成時にあらかじめ決められたアドレスを与えられるため、メッセージに署名するための秘密鍵に容易にアクセスすることができません。

この問題を解決するため、2018年にERC-1271コントラクト署名標準が提案されました。この標準では、スマートコントラクトが有効な署名と見なすための制限/チェックを実装でき、アプリはcontract.isValidSignatureを呼び出すことで、あるアクションがそのスマートコントラクトによって承認されたかどうかを確認できます。

スマートコントラクトアカウント(SCA)の文脈では、ERC-1271はSCAのユーザーがEOAとまったく同じように署名ベースのアプリケーションを利用できるようにするため、非常に便利です。こうしたアプリケーションにはOpenSeaや、大半のDeFi(トークン承認→呼び出しというUXに依存するもの)が含まれます。

ERC1271署名リプレイの脆弱性

大半のSCAは、上記のリファレンス実装を用いてERC-1271を実装しています。エンジニアリング面では軽量な実装であり、EOA向けに使われているのと同じ方法でsignTypedData、signMessage、eth\_signTypedData\_v、personal\_signといったメソッドを再利用できるため、クライアント統合がはるかに容易になります。

しかし、同一アドレスが複数のSCAを所有し、かつアプリケーションがインタラクションの発信元アドレスを含めない場合、同じ署名がそのアプリケーションに対して両方のアカウントで有効になってしまいます。

この脆弱性はSCAとアプリケーションの組み合わせによってのみ成立するため、どの程度深刻になるかは、このインタラクションがどのアプリケーションで機能するかに左右されます。最初に調査したアプリケーションはPermit2で、これはUniswapが構築したパブリックインフラで、業界全体のERC20トークン承認フローのセキュリティとUXを改善するものであり、現在広く使われています。

以下のコードブロックは、Permit2の署名がカバーするstructを示しています。注目すべきは、トークンの引き出し元アドレスであるaddress ownerが署名の対象に含まれておらず、代わりにPermit2への呼び出しで引数として渡される点です。

攻撃者がこの署名リプレイの脆弱性を悪用する流れは、次のようになります。

Bobがn個のSCAを所有するAliceに対して、Xトークンの支払いをPermit2経由で行うよう要求する
Aliceが最初のpermitに署名した後、BobはこのpermitをAliceの全SCAに対してリプレイし、合計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はこの攻撃ベクトルに対して脆弱ではなかった。

この時点で、telegramグループを通じてSCAおよびアプリケーションにこの問題を開示したところ、curiousappleも1か月前に同じ問題を発見しており、Frangioや他のSCA技術専門家と共に修正に取り組んでいたことが分かりました。これまでに判明した、影響を受けたSCAとアプリケーションの組み合わせの全リストは以下の通りです。

ERC-1271署名リプレイ脆弱性の影響を受けるスマートコントラクトアカウントとアプリケーションの一覧 — 影響範囲:アカウントとアプリケーション

注: Argentはモバイルアプリであり、署名者をデバイスごとに生成するため、2つのSCAが同一のEOAによって所有されることはあり得ず、したがって署名リプレイ攻撃はArgentに対して機能しません。ただし、Argentのアーキテクチャ全体をフォークせずにそのコントラクトのみをフォークしたプロジェクトはリスクにさらされる可能性があり、Argentのウォレットアーキテクチャを採用するか、修正を出荷する必要があります。

修正

提案されたSCAの修正は2つあります。SCAビルダーは、上記のリプレイ攻撃を防ぐためにこの2つの解決策のいずれかを実装すべきです。

どちらの解決策もERC-1271署名リプレイ攻撃を防ぐことができます。後者の解決策はより軽量ですが、ウォレットクライアントはユーザーが署名するために不透明なハッシュを表示しなければならなくなります。前者の修正は、署名がユーザーにとって不透明にならないようにする上でより容易な方法であり、そのためLightAccountについては前者の修正を採用しました。他のほとんどのSCAも同じ修正を採用しています。