2025年3月5日、1inchのFusion V1プロトコルに統合されたサードパーティのレゾルバーコントラクトが、連携されたエクスプロイトの被害に遭い、総額500万ドル以上の損失が発生しました。根本原因は、決済フローにおける安全でないcalldata再構築にあり、攻撃者が制御したインタラクション長が、サフィックス組み立て中のポインタアンダーフローを引き起こし、偽造された決済データの挿入を可能にしました。このエクスプロイトは、さらに配置ミスされた信頼境界によって可能になりました。レゾルバーコントラクトは、 settlementコントラクトから転送されたすべてのcalldataをmsg.senderのみに基づいて暗黙的に信頼しており、攻撃者が制御したデータがすべてのアクセス制御チェックを通過しても、決済レベルの権限を継承しました。
このインシデントは、新しい金融プリミティブによるものではなく、低レベルのABIおよびメモリレイアウトの仮定を悪用した、2025年の最も洗練されたDeFiエクスプロイトの1つとして際立っています。これは、スマートコントラクトの脆弱性と古典的なバイナリ exploitationテクニックとの境界を曖昧にしています。
背景
1inchのFusion V1プロトコル
1inchは、複数のDEXにわたる流動性を調達し、ユーザーに最適化されたスワップ実行を提供する分散型取引所（DEX）アグリゲーターです。アグリゲーターのリミットオーダーインフラストラクチャ上に構築された1inch Fusionは、ダッチオークションベースのオーダーマッチングモデルを導入し、ユーザーが価格範囲やスワップ時間ウィンドウなどの柔軟な実行パラメータを指定できるようにします。
Fusionモデルでは、ユーザーオーダーはプロトコル自体によって直接処理されません。代わりに、レゾルバーとして知られる専門の参加者によって実行されます。レゾルバーは、特権的でホワイトリストに登録された参加者と見なすことができます。対象となるには、十分なUnicorn Powerを取得するためにトークンをステーキングする必要があります。これは、経済的なゲートキーピングメカニズムとして機能します。
運用上、レゾルバーは独自のオフチェーンインフラストラクチャを実行し、1inchのバックエンドAPIとインターフェイスして、ユーザーオーダーを発見し、それらをいつ処理するかを決定します。レゾルバーがオーダーを実行することを決定すると、Settlementコントラクトに専用アカウントを介してオンチェーントランザクションを送信します。Settlementコントラクトが実際のスワップを実行します。（Fusionにはレゾルバー間の競争的なダッチオークションが含まれますが、このメカニズムは攻撃の理解には不可欠ではないため、ここでは省略します。単純化のため、レゾルバーはユーザーのオーダー条件を直接満たすことができると仮定します。）
スワップを実行する際、レゾルバーは、ユーザーの最小要件よりも優れた実行を提供するために外部市場から流動性を調達するか、または自身の資産を使用して直接取引を決済することができます。このプロセスで生成された余剰価値は、レゾルバーに利益として蓄積されます。このブログで説明されている攻撃は、そのようなレゾルバーコントラクトを対象としています。具体的には、オンチェーンマーケットメイキングに使用され、資産を保有し、Settlementコントラクトに承認を与えていたコントラクトであり、最終的にそれらの資産の損失につながりました。
オーダー処理と実行
1inch Fusionでのオーダー実行は、Settlementコントラクトによって調整され、線形実行フローではなく、インタラクションデータによって駆動される再帰的な決済モデルに従います。
プロセスは、レゾルバーがsettleOrders()関数を呼び出し、最初のオーダーとインタラクションペイロードをエンコードしたcalldataを渡すことから始まります。Settlementは、すべてのオーダーを一度に決済しようとするのではなく、内部の_settleOrder()関数を繰り返し呼び出すことで、段階的に処理します。
各オーダーについて、_settleOrder()関数はメモリ内でLimit Order Protocol（AggregationRouterV5.fillOrderTo()）への呼び出しを再構築します。この再構築中、Settlementは、レゾルバーIDや累積手数料などの実行メタデータを運ぶ動的なサフィックスの形式で、レゾルバー関連のコンテキストを追加します。このサフィックスは、Limit Order Protocolによって不透明なものとして扱われます。それは変更されずに転送され、後でSettlement自体がインタラクションコールバック中にデコードします。
オーダーが処理された後、制御はfillOrderInteraction()関数を介してSettlementに戻ります。インタラクションデータに基づいて、Settlementは、残りのインタラクションペイロードで_settleOrder()関数を再帰的に呼び出して決済を継続するか、最終段階に移行します。最終段階では、Settlementは、累積された実行コンテキストを渡しながら、レゾルバーコントラクトのresolveOrders()関数を呼び出すことで、制御をレゾルバーに転送します。
この設計により、プロトコルレベルの実行ステップがすべて完了するまでレゾルバー固有のロジックを遅延させながら、単一のトランザクション内で複数のオーダーを順次決済できます。
脆弱性分析
脆弱性は、内部の_settleOrder()関数における安全でないcalldata再構築ロジック、特にインタラクションデータに追加される動的なサフィックスの配置中に発生します。
レゾルバーコントラクトは明示的なアクセス制御によって保護されています。それらは、呼び出しがSettlementコントラクトから発信されていること、および解決中に提供されるレゾルバーアドレスがレゾルバーコントラクト自体と一致することを要求します。これらのチェックは、決済プロセスを通じて伝播されるレゾルバーIDが正しく構築され、そのまま維持されていることを前提としています。この前提は、レゾルバー関連データがどのようにエンコードされ、calldata再構築中にどのように追加されるかの正しさに依存しています。
決済中、_settleOrder()はメモリ内でcalldataを再構築し、レゾルバー固有の実行コンテキストを運ぶ動的なサフィックスを追加します。このサフィックスには、レゾルバーアドレスだけでなく、レゾルバーが決済を正当なものとして解釈するために依存するオーダー関連情報も含まれます。サフィックスは、ptr + interactionOffset + interactionLengthとして計算されたメモリ位置に書き込まれます。ここで、interactionLengthは、完全な32バイト値としてcalldataから直接読み取られます。
このオフセット計算は境界チェックなしで行われるため、攻撃者はinteractionLengthを制御して算術オーバーフローを誘発し、サフィックスがメモリに書き込まれる場所を操作できます。これにより、攻撃者は意図されたサフィックスを偽造されたものに置き換えることができ、任意のレゾルバーアドレスと攻撃者が制御したオーダーコンテキストを提供できます。
結果として、決済フローが後でサフィックスをデコードする際に、オーダーデータが正当であるという仮定は満たされず、実行が正当なレゾルバーから発信され、有効なオーダーデータが含まれていると解釈する可能性があります。攻撃者は、数weiを数百万に交換するために、オーダーサフィックスの独自のバージョンを効果的に注入できます。
攻撃分析
トランザクション++0x74bc++を例に取ります。攻撃は、わずかな量のトークン（数wei）を不均衡に大きな出力量でスワップする5つの有効なオーダーの作成から始まります。これらのオーダーは構文的に有効であり、プロトコルレベルのチェックを通過します。
次に、攻撃者はオーダーcalldataを大きなヌルバイト領域でパディングします。このパディングは、後で不正確なサフィックス配置により上書きされる制御されたメモリ領域として機能します。
決定的なのは、攻撃者が最後のオーダーに対して無効なinteractionLength値を指定することです。値は0xffff…fe00として選択され、符号付き整数として解釈すると-512に対応します。interactionLengthは符号なし256ビット値として扱われ、ポインタ演算に直接使用されるため、サフィックス書き込みオフセットを計算する際に算術オーバーフローが発生します。
以下の悪意のあるインタラクション構造がサフィックスとして扱われます。
まとめ
このインシデントは、1inchの非推奨のFusion V1プロトコルに統合されたサードパーティのレゾルバーコントラクトを標的とし、多大な損失につながりました。これは、いくつかの重要な教訓を浮き彫りにしています。
- 安全でないデータ仮定: 動的に構築された入力データに依存するシステムは、一部がユーザーによって影響される場合、長さ、オフセット、または構造の整合性を仮定すべきではありません。
- 暗黙的な信頼チェーン: セキュリティチェックは、各境界で検証するのではなく、上流コンポーネントに重要なコンテキストの維持を依存する場合、損なわれる可能性があります。
- レガシーサーフェイス: 古いコンポーネントをサポートすると、攻撃サーフェイスが増加し、プロトコルは新しい exploitationテクニックに対して脆弱になります。
- クロスドメインエクスプロイトパターン: 低レベルのメモリまたはデータレイアウトロジックが関与する場合、従来のソフトウェアで一般的な脆弱性がオンチェーンで再出現する可能性があります。
参考文献
- https://blog.decurity.io/yul-calldata-corruption-1inch-postmortem-a7ea7a53bfd9
- https://paragraph.com/@cookies-research/1inch-fusion-cost-efficient-mev-resistant-swaps
- https://blog-zh.1inch.com/fusion-swap-resolving-onchain-component/#steps-5-6
BlockSecについて
BlockSecは、フルスタックのブロックチェーンセキュリティおよびクリプトコンプライアンスプロバイダーです。私たちは、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金の追跡、およびAML/CFT義務の遵守を、プロトコルおよびプラットフォームのライフサイクル全体にわたって実行するのに役立つ製品とサービスを構築しています。
BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの数件のゼロデイ攻撃を報告し、複数のハッキングを阻止して2,000万ドル以上を救済し、数十億ドルの暗号通貨を確保しています。
- 公式ウェブサイト: https://blocksec.com/
- 公式Twitterアカウント: https://twitter.com/BlockSecTeam
- 🔗 BlockSec Auditing Service: リクエストを送信
- 🔗 Phalcon Security APP: デモを予約
- 🔗 Phalcon Compliance
