6.8097億ドルの警告：DeFi攻撃の大半は監査範囲外

著者：Liam 'Akiba' Wright、cryptoslate

翻訳：Chopper、Foresight News

分散型金融（DeFi）の分野では、「監査済み」という表示がプロジェクト全体の安全性を保証するものと見なされがちだ。しかし実際には、監査は通常、特定の時点、指定されたコード、コンポーネント、バージョンのみを対象とする。その範囲外で追加、削除、操作されたものについては、監査結果がまったく異なる可能性がある。

新たなプレプリント論文が、このギャップを具体的な数字で示した。セキュリティ企業ack3とプラハ・チェコ工科大学の研究者らは、2025年上半期に報告された135件のセキュリティインシデントを分析した。これらのインシデントによる損失は9.3986億ドルに上る。そのうち68件には、攻撃前に公開された監査記録が確認できたという。

この68件のサンプルのうち、研究者らは46件の攻撃経路を、確認可能ないかなる監査の範囲にも完全に含まれないと分類した。20件は少なくとも1つの監査の対象範囲内にあり、残り2件は判定不能だった。監査範囲外のインシデントは総件数の67.6%を占める一方、対応する損失額は報告された損失総額の94.4%に達した。

この驚くべき割合は、監査の有効性を評価するものでも、監査範囲の制限が損失を引き起こした証拠でもない。選択された公開セキュリティインシデントのサンプルにおける損失分布を示すにすぎない。2件の特大インシデントがデータに大きな影響を与えている。Kelp DAOの2.92億ドルの損失とDrift Protocolの2.85億ドルの損失を除外すると、同じ監査済みサンプルにおける監査範囲外の攻撃による損失の割合は72.1%に低下する。

こうした限界はあるものの、この研究は根本的なセキュリティ信頼の問題を浮き彫りにしている。プロジェクトが監査済みだと主張していても、ユーザーは実際に稼働しているシステム、資金の流れ、関連する管理策が精査されたかどうかを知ることができないのだ。

データの真の意味

ack3のこの研究は2025年1月1日から6月29日までを対象とし、確認された攻撃122件、疑わしいインシデント13件を扱っている。全サンプルのうち、35件は監査記録が見つからず、32件は監査履歴が不明で、これらは上記68件の統計には含まれていない。

68件のサンプルでは、監査範囲外のインシデントによる損失は6.8097億ドル、総損失は7.2124億ドルで、94.4%という数字が導き出された。Kelp DAOとDrift Protocolを除外すると、監査範囲外の損失は1.0397億ドル、総損失は1.4424億ドルで、割合は72.1%となる。データセットのJSONファイルで、インシデントの分類数と損失額を再現できる。

「監査範囲内／範囲外」というラベルは、公開された証拠に基づく研究者の判断だ。研究チームはプロジェクトと監査機関のアーカイブを調査し、攻撃前の監査報告書を特定し、最終的な攻撃経路を、監査対象のコード、バージョン、監査の除外事項と照合した。この研究は6ページのプレプリント論文で、データセットの公開元と共同で作成され、著者2名はセキュリティ監査企業ack3に所属している。

この研究には、攻撃を受けていない対照群がなく、各システムのリスク露出期間の統計もない。したがって、監査済みプロトコルが全体的に安全であることを証明できず、インシデント発生確率を推定できず、「監査範囲外」が各損失の直接の原因であると確認することもできない。未公開の監査や非公開のインシデントが欠落している可能性があり、報告された損失データも完全に比較可能とは限らない。

したがって、この研究から導き出せる結論は限定的だ。監査記録と監査の適用範囲は、独立した2つの指標である。監査済みのスマートコントラクトがあるからといって、コントラクトのアップグレード、特権キー、フロントエンド、リレーヤー、オラクル、クラウドサービス、インシデント対応プロセスが同等の安全性を確保できるわけではない。

8月に発生した2件のインシデントは、異なる角度からこの違いを裏付けている。ICON Networkの事例は、監査済みの2つのコードが2つの検証ポイントの境界で故障したことを如実に示している。一方、8月のaelfのセキュリティインシデントは別のケースで、既存の監査証拠では攻撃の実行経路を事前の監査範囲に対応付けることができない。

ICON Network：監査境界における障害のサンプル

8月27日のICON Networkのリプレイ攻撃では、引き出し経路の2つのモジュールが同じメッセージの解釈で食い違った。

ICON Foundationの事後分析報告書によると、移行コントラクトは引き出しメッセージのシーケンス番号の上位ビットでメッセージの一意性を判断していたが、暗号署名はシーケンス番号の下位256ビットのみを対象としていた。攻撃者は署名検証に含まれない上位ビットを改変し、約20分間で、正当な署名付き引き出しメッセージ2件を1,492回繰り返し送信し、そのうち1,490回の呼び出しが成功した。

このリプレイ攻撃により、1.19866億 ICXと531,600 bnUSDが放出された。分析公表時点で、ICONは純損失が約150.2 ETHと31,204 USDCであると確認した。Foundationは、531,600 bnUSDと136.6万 SODAの資産が回収され、ユーザーの預金、口座残高、ポジションに影響はなかったと述べた。

ICONは、この移行コントラクトは外部監査を完了しており、同一モジュール領域の関連修正を含む監査の推奨事項を実施済みだと説明した。対応するリレーロジックも個別に専門的な監査を受けていた。Sodaxの開発ドキュメントの監査リストには、異なるコンポーネントを対象とする8件の報告書が含まれており、その中には2025年11月のSodaxリレー監査報告書も含まれている。

しかし事後分析報告書には、一意性検証ロジックと署名検証値の間のこの正確な不一致は、上記の監査では発見されなかったと明記されている。単純な「監査済み」というプロジェクトラベルでは、引き出し経路の両端で「メッセージの一意性」の判定基準が一致しているかどうかをユーザーが知ることはできない。

対応のタイムラインは、別の種類の境界問題も浮き彫りにしている。ICONの最初の自動アラートはUTC 02:08に発報され、攻撃開始から約7分後だった。スタッフは03:40頃に調査を開始し、03:53に影響を受けたコントラクトを一時停止し、06:18:54にネットワーク全体を停止した。

最初のアラートから完全な緊急対応まで、約90分間の間隔があった。ICONはこれをアラートメカニズムの調整に起因するとしている。このアラートルールは過去のネットワーク接続障害で多数の誤報を発生させたため、高優先度で当直スタッフに通知されなかったのだ。Foundationは、自動シャットダウントリガーの導入、サーキットブレーカー閾値の引き下げ、メッセージの一意性とリプレイ防止に関する特別な再監査を計画している。

このようなリスク管理メカニズムは監査の代わりにはならないが、別の重要な問いに答える。予防策が失敗したとき、システムはリスクを迅速に検出して隔離できるのか、という問いだ。

aelf：セキュリティ保証には継続的な更新が必要

aelfの8月のセキュリティインシデントは、上記の見解を別の角度から裏付けている。公開情報ではランタイムへの侵入と制御された復旧が説明されているが、既存の証拠では攻撃経路が事前の特定の監査範囲内にあったかどうかを判断できない。

プロジェクトの公式発表によると、トランザクションパラメータを利用して、エンコードされた.NETアセンブリと命令をノードの実行経路に注入できる未承認のスマートコントラクトが存在したという。

初期調査報告書は、このインシデントをランタイムリフレクションと動的ロード検証の欠陥、およびコントラクト実行環境と機密ノード、インフラストラクチャリソース間の分離不足に起因するとしている。aelfは合計155件の関連トランザクション、5つの独立したペイロードアセンブリを特定した。ペイロードには、ホストコマンドの実行、外部通信の試行、ノードキーへのアクセス、インフラストラクチャの偵察などの能力があった。

能力があるからといって、すべてのペイロードが正常に実行されたわけでも、攻撃者がすべての標的の認証情報を取得し、機密データが漏洩したわけでもない。aelfは、潜在的な漏洩基準に従って署名キーとインフラストラクチャの認証情報をローテーションしたと述べている。

9月11日時点で、この結論はまだ暫定的な判断だ。aelfの公式ブログには、8月26日以降、このインシデントに関する特別な更新は投稿されていない。8月26日の発表では、今後の更新と最終的な事後分析を約束していた。

aelfの技術セキュリティ文書には、ブロックチェーンとELFトークンコントラクトは複数回の監査を受けており、セキュリティ上の問題は発見されなかったと記載されている。しかし、既存の公開ページでは、8月の攻撃に対応するランタイム経路を、事発生前のいずれかの監査報告書に対応付けることはできない。したがって、このインシデントを監査の見落としまたは監査範囲外の障害と断定するには、十分な証拠がない。

この不確実性自体が参考になる。タイムスタンプ付きの監査報告書は、現在のシステムコード、依存ライブラリ、実際の運用状態から徐々に乖離していく。ユーザーは、この違いを反映するバージョン管理されたセキュリティ記録を必要としている。

このセキュリティ記録には、監査対象のリポジトリとコードのコミットバージョン、デプロイされたコントラクトアドレス、除外されたコンポーネント、特権ロール、依存ライブラリを明記すべきだ。同時に、監査完了後のコントラクトのアップグレード、キーの保管とローテーションメカニズム、ランタイム分離ポリシー、アラートとサーキットブレーカーメカニズム、タイムスタンプ付きの資産回復状況を記録し、確認された損失、凍結された資産、未解決のリスクエクスポージャーを区別する必要がある。

これは監査の価値を否定するものではなく、監査の宣伝と実際の作業内容を一致させ、現在稼働しているシステムに関連付けるためのものだ。

監査バッジ1つでは、監査対象のコンポーネント、デプロイされたシステム、障害対応メカニズムが、依然として同じセキュリティ境界内にあるかどうかは答えられない。