7702 フィッシング攻撃の原理を深く解説：ウォレットやユーザーはどのように防げばよいのか？
TechFlow厳選深潮セレクト
7702 フィッシング攻撃の原理を深く解説：ウォレットやユーザーはどのように防げばよいのか？
どのウォレットを使用して署名する場合でも、署名内容をよく確認し、ブラインド署名や誤った署名を避けてください。
Web3業界の深掘り報道に専念し潮流を洞察EIP-7702はアドレスにスマートコントラクトに類似した機能性と柔軟性を付与します。現在、ますます多くのEIP-7702アプリケーションが開発されており、これはより多くの人々をWeb3へと導き、ユーザーエクスペリエンスを向上させる上で極めて重要です。
しかし、7702の柔軟性と、大多数のユーザーがまだ7702について十分に理解していない現状が、詐欺グループによって悪用されています。最近、MetaMaskの7702一括実行機能により、本来十数回の承認が必要な操作が、釣りサイトグループ「#InfernoDrainer」によって1件のトランザクションにまとめられ、資産が盗まれる事例が確認されています。
注記：MetaMask自体にセキュリティ上の問題はありません。MetaMaskは7702関連機能を提供する際に、ユーザーの安全を最優先としており、多くのセキュリティ対策を講じています。ユーザー自身が7702の機能と関連リスクについてさらに理解を深めることで、このようなセキュリティインシデントを防ぐ必要があります。
一、MetaMask 7702 Delegator署名承認の原理とセキュリティ設計
1. 技術分析
-
ユーザーが既にデプロイ済みのDelegatorコントラクトを承認し、ユーザーのアカウントcodeフィールドをそのコントラクトを指すように設定します。現在のMetaMask公式Delegatorコントラクトアドレス：0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
-
承認構造：
(chainId, delegatorAddress, nonce, signature)をauthorization_listに書き込み -
署名方式：MetaMaskの基盤では、EIP-7702関連の承認トランザクションに統一された署名ロジック
signEIP7702Authorizationを使用しており、承認データdigest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce))に対してECDSA署名を行い、(v, r, s)の署名構造を生成して、その後続するType-4トランザクションに追加することで、アカウントの承認およびアップグレードを実現しています。詳細な実装は以下をご参照ください：https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts -
検証方式：コンセンサス層は
ecrecover(digest7702, sig) == tx.fromにより検証を行います。 -
セキュリティ設計：ウェブページ側は任意のDelegatorへの承認をユーザーに誘導できません。なぜなら
signEIP7702AuthorizationメソッドはMetaMaskウォレット内部でのみ実装されており、window.ethereumを通じてウェブページから呼び出せないためです。ウェブページから利用可能な署名メソッド（例えばeth_signTypedData_v4）はEIP-7702承認署名には適用できません。その署名ダイジェスト形式は以下の通りです：
一方、EIP-7702仕様で要求される署名形式は以下の通りです：
eth_signTypedData_v4は固定で0x1901のプレフィックスを含んでおり、ダイジェスト計算プロセスも7702とは完全に異なるため、巧妙にdomainSeparator、primaryType、messageを構成しても、digest712 == digest7702となることは事実上不可能です。
したがって、ウェブページ側で正当な7702承認署名を偽造することはできません。また、MetaMaskはDelegatorアドレスに対してホワイトリスト方式を採用しており、デフォルトかつ唯一許可されるのは公式Delegator（0x63c0...32B）のみで、DAppが独自にアドレスを注入することを禁止し、ユーザーが悪意あるDelegator承認データに誘導されて署名してしまうことをさらに防止しています。
2. 使用方法
現在MetaMaskにおいて、既存のEOAを7702スマートアカウント（Smart Account）にアップグレードする方法は主に二つあります：能動的アップグレードと受動的アップグレードです。
能動的アップグレードとは、ユーザーがウォレット画面で直接「切り替え」ボタンをクリックし、特定のDelegatorコントラクトを承認する方法です。
受動的アップグレードは、ユーザーが7702対応のDAppとインタラクトする際、MetaMaskが関連操作を検知して自動的にポップアップ表示し、ユーザーにアップグレードを提案する場合です。
2.1 能動的アップグレード：
-
トランザクション内容：アカウントのアップグレード動作のみ、つまり特定のDelegatorコントラクトの承認。
-
アップグレード手順：ウォレットのアカウント詳細画面に入り、「切り替え」ボタンをクリックすると、Ethereumメインネット上のユーザーをスマートアカウントにアップグレードできます。「切り替え」をクリック後、ユーザーに現在のアップグレードトランザクションの署名ウィンドウが表示されます：
-
承認記録：承認後、トランザクションがブロックチェーンに記録されるのを待ちます。記録成功後、ユーザーはスマートアカウントにアップグレードされたことになり、etherscan上の現在のウォレットアドレスページ内の**
Authorizations (EIP-7702)**から具体的な承認トランザクション情報を確認できます。
2.2 受動的アップグレード
-
トランザクション内容：アカウントのアップグレード動作と、チェーン上のコントラクトとのインタラクションを一括で実行。
-
アップグレード手順：ユーザーがチェーン上の特定DAppとインタラクトする際、MetaMaskはユーザーに現在のトランザクションをスマートアカウントにアップグレードすることで一括送信できる旨を自動的に通知します。たとえばUniswapで特定トークンのSwapを行う場合、「Use smart account」ボタンをクリックし、スマートアカウントにアップグレードすることで、トークンの承認とSwapが1件のトランザクションで一括完了します。
2.3 普通EOAに戻す
能動的アップグレードでも受動的アップグレードでも、現在のアカウントをスマートアカウントに変換すると、バインドされたDelegatorコントラクトアドレスは永久にブロックチェーン上に保存され、アカウントの現在の実行ロジックとして保持されます。
ユーザーがアカウントを通常のEOAに戻したい場合は、「EOAに戻す」操作を手動で実行する必要があります。この操作の本質は、EIP-7702承認を通じて、address(0)を新しいDelegatorコントラクトアドレスとして提出することです。このトランザクションがブロックチェーンに記録されると、アカウントのcodeフィールドがクリアされ、実行ロジックはデフォルトの空コードに戻り、アカウントは通常のEOA状態に復帰します。
ウォレットのアカウント詳細画面に入り、「切り替え」ボタンをクリックすることで、Ethereumメインネット上のユーザーを通常のEOAアカウントに切り戻せます。
確認をクリック後、トランザクションがブロックチェーンに記録されるのを待ちます。記録成功後、ユーザーはスマートアカウントから通常のEOAアカウントに切り戻したことになります。具体的なトランザクション情報は、etherscan上の現在のウォレットアドレスページで同様に確認できます。
二、7702 魚取り攻撃の実例
5月24日、#InfernoDrainer魚取りグループはMetaMask 7702-Delegatorコントラクトの一括実行機能を利用して、ユーザー（0xc6D2…06DC）の複数のトークン承認を一括で騙し取り、魚取り攻撃を実行しました。被害額は$HashAI、$HUMANS、$ParallelAI、$NeuralAI、$DSync、$Zero1、$NodeAI、$Sensay、$Virtualなど合計14.6万ドル以上にのぼります。
-
詐欺アドレス
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
-
魚取りトランザクションの例
https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba
-
魚取り被害の原因
ユーザー（0xc6D2…06DC）が悪意のある一括承認トランザクションを実行したことが原因です：
Ethereum Transaction Hash: 0x1ddc8cecbc... | Etherscan
Call 0xe9ae5c53 Method By 0xc6D289d5...0d2E606DC on 0xc6D289d5...0d2E606DC | Success | May-23-2025 02:31:35 PM (UTC)
-
#InfernoDrainerおよび#PinkDrainerは、より巧妙かつ影響範囲の広いEIP-7702を利用した魚取りブラックビジネスモデルの研究を進めています。
調査によれば、現在、釣りサイトグループ #InfernoDrainer および #PinkDrainer は、より巧妙かつ影響の大きいEIP-7702を利用した釣りビジネスモデルの研究・実験を進めています。関連アドレスは以下の通りです。今後、さらに詳しい報告を公開する予定です：
Inferno Drainer：
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer：
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
三、セキュリティに関する推奨事項
ウォレット提供者：
-
MetaMaskの7702 Delegatorの実装およびセキュリティ管理を参考にし、ユーザーが任意のDelegatorを承認できないようにし、アプリ内操作のみを許可してください。ウェブページ経由でユーザーに署名承認を促すすべての行為は魚取り攻撃であるとユーザーに周知してください。
-
チェーンが現在のネットワークと一致しているか確認し、chainIDが0での署名にはリプレイリスクがあることをユーザーに警告してください。
-
ユーザーが承認署名を行う際にはターゲットコントラクトを明示し、Delegatorによる一括実行時には具体的な関数呼び出し内容を表示することで、魚取り攻撃のリスクを低減してください。
ユーザー：
-
秘密鍵の保護が常に最も重要です。Not your keys, not your coins.
-
独立したウェブページからのDelegator承認を行わないでください。安全な承認は通常、MetaMaskのようにアプリ内でのみ行われます。
-
いかなるウォレットでも署名を行う際は、署名内容をよく確認し、ブラインド署名や誤署名を避けてください。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
GoPlus Security
