被害総額約1億460万ドル：EchoProtocol、Verus等の事例 | BlockSecウィークリー

先週（2026/05/18 - 2026/05/24）、BlockSecは複数のブロックチェーンエコシステム全体で複数の攻撃インシデントを確認しました。以下の表は、推定総損失額約1億460万ドルにのぼる5つの注目すべきインシデントをまとめたものです。

詳細な分析のために2つのインシデントを選定しました。

• Verus: 攻撃者は、Verus-Ethereumブリッジが有効なプライマリ・エクスポート（転送）として誤認するような細工を施した「補助的エクスポート（supplemental export output）」を送信することで、タイプバリデーションの失敗を悪用しました。クロスチェーンメッセージのセマンティクス（意味論）が攻撃対象領域の一部となっています。
• RetoSwap: P2P取引フローにおけるプロトコルレベルの認証の欠陥により、攻撃者は偽造したACK（確認応答）メッセージを送ることで仲裁者の役割を乗っ取ることが可能でした。攻撃者はマルチシグウォレットの作成プロセスを完全にオフチェーンで侵害しました。

今週のハイライト：Verus

このインシデントが注目される理由は、攻撃者が特殊なクロスチェーン・エクスポート・タイプを意図的に悪用しており、Verusチェーンの内部設計に対する深い理解を示しているためです。このエクスプロイトは、補足的なデータフィールドやエンコーディング境界を含むクロスチェーンのメッセージ形式も攻撃対象領域の一部であり、暗号学的証明の検証と同等の厳格さが必要とされることを示しています。

2026年5月18日、Verus L1チェーンとEthereumを接続するクロスチェーンブリッジであるVerus-Ethereumブリッジが攻撃を受け、約1,170万ドル相当の ETH、tBTC、USDC が流出しました [1][2]。根本原因はEthereum側のインポートパスにおけるタイプバリデーションの失敗にあります。ブリッジコントラクトが細工された補助的エクスポート出力を受け入れ、それを有効なプライマリ・エクスポートとして誤認したため、攻撃者が一致する転送データを提供して資金を流出させることが可能となりました。5月23日の時点で、盗まれた資金の約75%が返還されました。

背景

Verus-Ethereumブリッジは、公証されたVerusステート下で有効なVerus側のエクスポートが存在することを証明した後、Ethereum上で資産を解放します。EthereumはVerusのトランザクションを直接監視するのではなく、提出された証明データと、信頼されるVerusステートを定義する公証に依存しています。

本インシデントに関連するブリッジオブジェクトは3つあります。Ethereumがインポートして払い出しに使用する「プライマリ・エクスポート」、プライマリ・エクスポートに付随する追加データであり、払い出し目的の独立したアクティブなエクスポートとして扱われるべきではない「補助的エクスポート出力」、そして特定のVerus側オブジェクトが確定したブリッジステートに存在したことをEthereumが証明できるようにする「公証」です。

脆弱性の分析

バグのあるEthereum側のブリッジコントラクトは 0xa045...6fc87f および 0x08f0...d0107d にデプロイされています。

根本原因は、Ethereumインポートパスにおけるタイプバリデーションの失敗でした。ブリッジは実際のVerus側オブジェクトが存在することは証明しましたが、それが資金解放に使用される前に「有効なプライマリ・エクスポート」であるかの確認を行っていませんでした。代わりに、細工された補助的出力を受け入れ、通常の有効なエクスポートであるかのように解析してしまいました。

大まかに言うと、脆弱なフローは以下の通りです。

proveImports(...)
    -> 証明を検証
    -> keccak256(serializedTransfers) == コミットされた転送ハッシュ を検証

processTransactions(...)
    -> Ethereum上で払い出しを実行

このフロー内には FLAG_SUPPLEMENTAL が設定されたオブジェクトを拒否するチェックが存在しません。修正ではこのフラグを明示的にチェックし、証明されたオブジェクトが補助的であればリバートするようにしています。

攻撃の分析

以下の分析は、Ethereumトランザクション 0x6990f0...87eb321 およびVerusトランザクション f899e698...b9f5a733 に基づいています。

• ステップ1: 5月17日、攻撃者はTornado Cashを経由して1 ETH を自身のEthereumアドレス 0x5aBb...9D5777 に送金しました。5月18日、攻撃者はVerusフォーセットからアドレス RW9vEW...B3g6zd 用に0.02 VRSC を入手しました。

• ステップ2: 攻撃者は、細工された補助的エクスポート出力を含む、Ethereum向けの4つのエクスポートトランザクションをVerus上で送信しました。これらの補助的出力はエラーなく解析できるようにエンコードされており、攻撃者が後で実行する不正な払い出しと一致する hashReserveTransfers コミットメントが含まれていました。

• ステップ3: Ethereum上でクロスチェーン公証が十分に進行した後、攻撃者はEthereum上で偽造されたインポートトランザクションを送信しました。証明されたVerus側オブジェクトは、上記のVerusトランザクションからの補助的出力でした。

• ステップ4: Ethereumブリッジは証明を受け入れましたが、補助的データとしてのオブジェクトを拒否しませんでした。代わりに、細工された出力を有効なアクティブ・エクスポートかのように解析しました。攻撃者はコミットされた hashReserveTransfers 値とハッシュが一致する serializedTransfers を提供していたため、ブリッジはインポートフローを進めました。

• ステップ5: 補助的出力が有効なエクスポートとして誤解されたことで、不正な転送はEthereum側のチェックを通過しました。攻撃者は約1,170万ドル相当の ETH、tBTC、USDC を流出させました。

• ステップ6: 不正なインポートが成功した直後、Verusノードが不正なエクスポートスレッドと実際のエクスポートスレッドの共存によって引き起こされる不正ステートのアサーションを検出し、以降のブリッジの進行を停止させたため、さらなる被害拡大は限定的でした。

結論

本インシデントはVerus-Ethereumブリッジにおけるタイプバリデーションの失敗によって引き起こされました。Ethereumコントラクトは正当な暗号学的証明を受け入れましたが、証明されたオブジェクトは払い出しのための有効なプライマリ・エクスポートではなく、補助的エクスポート出力でした。

クロスチェーンのメッセージ形式は攻撃対象領域の一部です。補助的なデータ、オプションのフィールド、コンパクトなエンコーディング、パーサーのオフセットなどは、署名やマークル証明の検証と同等の厳格さで扱う必要があります。オブジェクトが実行しようとしているアクションに対して期待されるタイプと一致しない場合、ブリッジはそれを解析しようとするのではなく、直ちに拒否すべきです。

参考文献

• [1] BlockSec Phalcon Alert
• [2] Verus公式事後報告

今週のその他のインシデント

RetoSwap

2026年5月20日、Haveno ProtocolからフォークされたMonero上の分散型P2P取引所であるRetoSwapが攻撃を受け、約270万ドル（7,000 XMR）相当が流出しました [1]。根源的な原因はプロトコルレベルの認証の欠陥にあります。クライアントが偽造された順序不正のACKメッセージを受け入れ、送信者が仲裁者の知られている公開鍵と一致するかを検証することなく、仲裁者の保存済みTorアドレスを攻撃者が管理するものに上書きしてしまいました。これにより、攻撃者はマルチシグウォレットの作成を乗っ取り、資金が預けられた瞬間にそれを盗み出すことが可能となりました。

背景

RetoSwapはHaveno ProtocolをフォークしたMonero上の分散型P2P取引所です。その取引プロトコルは、取引を保護するために2-of-3の仲裁者マルチシグモデルに依存しており、Tor経由でオフチェーンで取引を調整します。

通常の取引は3つのフェーズで進行します。まず買い手、売り手、仲裁者がオフチェーンでメッセージ交換を行いマルチシグウォレットを作成し、次に完全に作成された後にのみマルチシグウォレットに資金がロックされ、最後に買い手と売り手が合意して払い出しトランザクションを共同署名して完了するか、または紛争解決のために仲裁者が介入します。すべての通信はTor経由で行われ、各ノードは .onion アドレスによってのみ識別されます。

脆弱性の分析

5月20日、Havenoプロジェクトは「core: マルチシグ作成前にノードアドレスの更新を拒否する」というタイトルのプルリクエストを開きました [2]。その時点で、RetoSwapはすでに攻撃を受けていました。

このパッチにより TradeProtocol.java:onAckMessageAux(...) における脆弱性が明らかになりました。クライアントは、送信者が期待される仲裁者の公開鍵と一致することを暗号学的に検証することなく、メッセージで提供された senderNodeAddress を使用してピアを識別していました。攻撃者は攻撃者が管理する .onion アドレスを記載した偽造ACKメッセージを送ることで、クライアントに保存されている仲裁者のアドレスを上書きさせることができました。

これはフェーズ1（マルチシグウォレット作成前）の間に発生したため、攻撃者のアドレスが実際の仲裁者のアドレスと入れ替わりました。結果として、攻撃者はマルチシグウォレットのトレーダーの鍵と仲裁者の鍵の両方を保持することになり、資金が預けられた時点で全額を窃取することが可能となりました。

修正は2つの方法で行われました。ピアの既知の公開鍵に対して送信者を検証し、検証されていないピアからのメッセージを拒否すること、そしてアドレス更新を trade.isDepositRequested() によって制限し、マルチシグウォレット作成前の上書きを防止することです。

攻撃の分析

このインシデントに関するオンチェーンの攻撃トランザクションは特定されていません。RetoSwapはTor経由で完全にオフチェーンのメッセージ処理を行っているため、重要なアクションはすべてパブリックレジャーの外側で発生しています。以下の再構築は、公開されているパッチと公式発表に基づいています。

• ステップ1: 攻撃者は買い手または売り手として既存の取引に参加しました。

• ステップ2: 攻撃者は、仲裁者からのものであるかのように見せかけた偽造された順序不正のACKメッセージを送信しました。これには、senderNodeAddress として攻撃者が管理する .onion アドレスが含まれていました。

• ステップ3: 被害者のクライアントはそのメッセージを受け入れ、仲裁者の既知の公開鍵に対して送信者を検証することなく、保存されていた仲裁者のアドレスを上書きしました。

• ステップ4: マルチシグウォレットの作成を含む、仲裁者宛ての以降のすべての通信が攻撃者にルーティングされ、攻撃者は3つ目のマルチシグ鍵を入手しました。

• ステップ5: 買い手と売り手が侵害されたマルチシグウォレットに資金を入金すると、攻撃者はウォレットの全残高を盗み出しました。総利益は約7,000 XMR （約270万ドル）にのぼりました。

結論

本インシデントは暗号学的な失敗ではなく、プロトコルレベルの認証の欠陥でした。メッセージはよく構成されているものとして検証されましたが、アドレス更新が適用される前に、送信者が既知の公開鍵と暗号学的に結び付けられていませんでした。その結果、クライアントは偽造ACKメッセージからの未検証の senderNodeAddress を、マルチシグウォレット作成前の仲裁者の新しい接続先として扱い、攻撃者に仲裁者の役割を乗っ取らせることを許してしまいました。

重要な教訓は以下の通りです。(1) ピアのIDを更新するメッセージは、更新が適用される前に必ずそのピアの既知の公開鍵に対して暗号学的に検証しなければならない。(2) セキュリティに敏感なフェーズ（マルチシグウォレット作成など）が開始された後は、相手方アドレスのようなIDに関わるステートは不変であるべきである。

参考文献

• [1] RetoSwap インシデント後の声明
• [2] Haveno 修正プルリクエスト

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。当社は、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃阻止、インシデント分析、不正資金の追跡、AML/CFT義務の遵守を支援する製品とサービスを提供しており、プロトコルおよびプラットフォームのライフサイクル全体をサポートします。

BlockSecは、権威ある会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのいくつかのゼロデイ攻撃を報告し、2,000万ドル以上の被害を阻止し、数十億ドル規模の暗号資産を保護してきました。

• 公式ウェブサイト: https://blocksec.com/

• 公式Twitterアカウント: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 監査サービス : 依頼を送信

• 🔗 Phalcon Security アプリ: デモを予約

• 🔗 Phalcon コンプライアンス