最上位のMEVボット、750万ドルを盗まれる：Approvalこそがチェーン上で最も見落とされがちな致命的リスクなのか？

イーサリアム上で一般トレーダーを長期間狙っていたMEVボットが、逆に750万ドル相当の「カスタムメイド」の罠に自ら落ちました。

6月21日、イーサリアム上の有名なサンドイッチアービトラージボット「Jaredfromsubway.eth」が攻撃を受け、アドレス内のWETHやUSDCなどの資産が送金され、初期推計で750万ドル以上の損失が出ました（ただし、現在公表されている損失の内訳にはまだ差異があります）。

興味深いことに、今回の攻撃は秘密鍵の漏洩でも、従来のスマートコントラクトの脆弱性を利用したものでもなく、攻撃者が事前に大量の偽造トークン、流動性プール、補助コントラクトを展開し、それらをアービトラージの可能性がある取引経路に見せかけ、ボットが自動実行プロセスで悪意あるコントラクトにERC-20の承認を与えるよう誘導し、最終的に「合法的に」MEVボットの資産を送金したというものです。

本稿執筆時点で、Jaredfromsubway.ethはチェーン上のメッセージを通じて攻撃者に公開で呼びかけ、「48時間以内に2150ETHを返却すれば、50%のホワイトハット報奨金を支払う。そうでなければ、可能な限りの法的・執行手段を尽くして責任を追及する」と述べています。

しかし、高度に専門化されたコード駆動型のMEVボットでさえ、承認（Approval）でつまずくとなると、私たちが日常的に使用するこの「承認」という行為に、どれほどの危険が潜んでいるのか、改めて考えさせられます。

1. MEVボットのために仕組まれた逆狩り

今回の攻撃を詳しく分析すると、これは偶然発生した脆弱性ではなく、Jaredfromsubway.ethの取引ロジックに合わせて設計された長期的な狩りであったことがわかります。

Jaredfromsubway.ethは、イーサリアム上で最も有名なサンドイッチアービトラージボットの一つです。サンドイッチ攻撃とは、簡単に言えば、ボットが実行間近のチェーン上の取引を発見し、ユーザーより先に購入して価格を押し上げ、ユーザーが不利な価格で取引を完了した直後に売却して価格差を稼ぐ手法です。

そのため、この戦略ではボットがチェーン上の取引を常時スキャンし、超高速でアービトラージ機会を判断し、様々なトークンやコントラクトを呼び出す取引経路を組織する必要があります。つまり、速度が速く、カバーする資産とプロトコルが多いほど、ボットが捉えられる機会も増えるということです。

しかし、まさにこの点が、今回の事件の突破口となりました。

事後の分析によると、攻撃者はボットの資金コントラクトを直接攻撃したのではなく、数週間かけて、利益を生み出せるように見える取引環境を構築しました。

• 第一段階は、大量の偽造トークンと流動性プールの展開です。これらのトークンは、名称、インターフェース、取引動作においてWETH、USDC、USDTなどの一般的な資産を模倣しており、ボットの自動認識システムが正常な取引経路を発見したと誤認するように仕向けます。
• 第二段階は、徐々にボットの信頼を得ることです。初期テストでは、ボットが付与した承認は取引と共に正常に使用されました。しかし、ボットのシステムが同様の経路を繰り返し実行し始めると、攻撃者はコントラクトロジックを調整し、ボットが生成した承認の一部が実際には消費されず、取引終了後もゼロにリセットされないようにしました。その結果、これらの承認がそのまま残ったのです。
• 最後に、攻撃者はまだ有効な承認枠を集中的に呼び出し、ボットのコントラクト内にある実際のWETH、USDC、USDTを送金しました。

要するに、この攻撃はMEVボットの動作特性、すなわち利益判断ルールに合致する環境をまず作り出し、その後、自動実行される取引経路のメカニズムを利用して、システム自らに資産の呼び出し権限を委ねさせることを完全に狙ったものです。

これが、高度に専門化されたMEVボットでさえも引っかかった理由を説明しています。

ボットは価格差、ガス代、取引順序を計算する方法を知っていますが、新しく現れたすべてのコントラクトに対して十分な身元確認を行うとは限りません。この観点から言えば、一般ユーザーの問題は「理解せずに確認を押してしまう」ことであり、自動化ボットの問題は「確認せずに自動実行してしまう」ことです。

表面的には両者は全く異なりますが、根底にあるリスクは非常に近いものです。なぜなら、どちらも承認を取引を完了する前の単なる手順の一つと見なし、そこに潜むリスクの高さを明確に認識していないからです。

2. なぜApprovalは常に過小評価されるのか？

周知の通り、イーサリアムおよびEVM互換チェーンのERC-20標準において、Approve（承認）は極めて基本的な設計です。

しかし、ユーザーがウォレットで直接送金する場合、通常はtransferを呼び出し、一般的にApproveは関係しません。DEX、レンディング、ステーキング、流動性追加などのスマートコントラクトを利用する場面で、ユーザーがスマートコントラクトに代わってトークンを呼び出させる必要がある場合にのみ、Approvalが関わってきます。

例えば、UniswapでUSDTをETHに交換したい場合、Uniswapのスマートコントラクトは直接あなたのウォレットからUSDTを奪うことはできません。先にApproveを実行して、「Uniswapが私のウォレットからX個のUSDTを移動することを許可する」とシステムに伝える必要があります。

承認が完了すると、権限を得たコントラクトはtransferFromを通じて、制限された範囲内でユーザーのUSDTを呼び出せるようになり、その後のSwapも正常に完了できます。

つまり、Approval自体は脆弱性ではなく、DeFiが正常に機能するための重要な基盤です。ただし、問題はそれがPayPalや銀行の自動引き落とし権限に少し似ている点にあります。

ユーザーは店舗に口座のパスワードを渡してはいませんが、店舗が合意された範囲内で自動的に引き落とすことを許可しています。承認が有効である限り、その後の引き落としにユーザーが毎回パスワードを入力したり、都度確認したりする必要はなく、これが自然といくつかの問題を引き起こします。

まず、無制限承認の問題です。多くの場合、一回の取引が長期的な権限になってしまいます。 主な理由は、承認を繰り返す手間とガス代を削減するためで、多くのDAppはデフォルトで非常に大きな承認枠、いわゆる「無制限承認」を要求します。

ユーザーは100 USDCで一回の取引を完了したいだけなのに、将来、自分のアドレスにある全てのUSDCを動かす権限をコントラクトに与えてしまう可能性があります。その承認が取り消されなければ、当時のウォレットにごく少量の資産しかなくても、将来新たに送金されたUSDCも影響を受け続ける可能性があります。

次に、承認はDAppから離れても自動的に消えるわけではないという点です。 多くのユーザーは「ウォレット接続の切断」と「承認の取り消し」を混同しています。実際には、接続を切断しても、Webページが現在のウォレットを読み取ったり要求したりできなくなるだけで、ブロックチェーンに書き込まれたApprovalは変更されません。

Webページを閉じたり、DAppを削除したり、ブラウザのキャッシュをクリアしたり、ウォレットアプリを交換したりしても、自動的に無効になることはありません。

最後に、たとえ正常なコントラクトであっても、将来的に危険になる可能性があります。 多くの承認リスクは、最初から悪意のあるフィッシングサイトからのみ生じるわけではありません。今回の狩りのように、ユーザーは当時は正常だったプロトコルに権限を付与したものの、その後、プロトコルのコントラクトが攻撃されたり、管理者キーが漏洩したり、アップグレード可能なロジックが置き換えられたり、呼び出していたルーターコントラクトに問題が発生する可能性があります。

ユーザーにとって、資産は依然として自分のアドレスに残っていますが、権限の観点から見ると、別のコントラクトがこれらの資産を呼び出す能力を常に持っていることになります。したがって、Approvalリスクとは「私が悪者に承認を与えたかどうか」だけでなく、「私が承認した相手が今後問題を起こさないかどうか」も含まれます。

3. Approvalリスクをどう管理すべきか

Approvalリスクに対して、最も簡単なアドバイスは「無制限承認をしないこと」です。

しかし、実際のDeFi利用環境では、承認を完全に拒否するのは非現実的です。前述の通り、承認自体は脆弱性ではなく、チェーン上のアプリケーションが資産を呼び出すための基本的な方法だからです。

本当に必要なのは、Approvalを一回限りの確認動作から、継続的な権限管理メカニズムへと変えることです。

では、一般ユーザーにとって、まずはいくつかの基本的な習慣を身につける必要があります。

• 第一に、「最小権限」の原則に従うこと。ウォレットに承認プロンプトが表示されたら、今回のインタラクションの実際のニーズに基づいて枠を設定するようにします。例えば、100 USDTだけを使用する予定なら、無制限の権限を開放するのではなく、可能な限り100 USDTに近い枠だけを承認します。
• 第二に、保管用ウォレットと操作用ウォレットを区別すること。高額な資産を長期保管するアドレスは、頻繁に未知のDAppに接続しないようにします。エアドロップ、Mint、新規プロジェクト、高リスクのDeFiインタラクションに参加する際は、別のアドレスを使用し、潜在的な損失を小さな範囲に限定します。
• 第三に、定期的に不要な承認を確認し、取り消すこと。ユーザーはRevoke.cashなどのツールを使用するか、imToken内で該当のトークンページに移動し、左下の「トークン機能」をクリックして「承認管理」を選択することで、そのアドレスの承認対象、トークン、枠を確認し、使用しなくなったものや出所不明の権限を取り消すことができます（参考記事「Revoke.cashを使った承認管理を手取り足取り教えます」）。

もちろん、いくら言っても、防ぎきれない承認攻撃に対しては、ユーザーのセキュリティ意識や定期的な確認だけでは不十分です。なぜなら、ほとんどのユーザーは、一連のコントラクトアドレスが誰のものかを識別したり、特定の承認枠が妥当かどうかを判断したりすることが難しいからです。

そこで、ユーザーがWeb3に入るための最初の防御線として、ウォレットは製品機能において積極的な防御を提供する必要があります。

例えばimTokenでは、識別されたリスクのあるトークン、アドレス、DAppにマークを付けたり、ブロックしたりします。ユーザーが一般の外部アカウントにトークン権限を付与したり、コントラクトアドレスに直接送金したりする際にも、対象に応じたリスク警告を提供します。これらの警告はユーザーの判断を代替するものではありませんが、実際に署名する前に、必要な安全のための緩衝材を追加することができます。

これに加えて、imTokenはDAppへのログイン、送金、トークン交換、承認などの重要な場面で、署名内容を構造的に解析し、読みやすく表示することで、ユーザーが確認する前に自分が何に同意しているのかを理解できるよう最大限に支援し、ユーザーが署名する内容が、目に見える動作と一致することを保証し、識別が難しいハッシュデータに圧縮されないようにします。

ERC-7730などのClear Signing標準がさらに推進されるにつれて、このような「What You See Is What You Sign（見たものがそのまま署名内容）」の可読性の高い表示は、単一のウォレットの製品能力から、ウォレット、DApp、スマートコントラクト間で共有される業界標準へと徐々に発展していくことが期待されます。

全体として、秘密鍵は誰がアカウントを所有するかを決定し、Approvalは誰がアカウント内の資産を呼び出せるかを決定します。この二つは同じものではありませんが、同様に重要です。

これはつまり、ウォレットのセキュリティは「秘密鍵が漏洩したかどうか」だけにとどまらず、ユーザーからウォレットに至るまで、皆の共同努力が必要であることを意味します。ユーザーにとっては、承認前に相手と枠を確認し、インタラクション終了後は不要な権限を速やかにクリーンアップする必要があります。ウォレットにとっては、これらの元々コントラクト内に隠されていた権限を、より可視化し、理解しやすくし、制限や取り消しを容易にする必要があります。

何しろ、本当に危険なのは、今まさに行われた送金ではなく、とっくに忘れ去られていながら、まだ有効なままの承認かもしれないのですから。