6.8 億ドルの警告：ほとんどのDeFi攻撃は監査範囲外で発生

作者：Liam 'Akiba' Wright、cryptoslate

翻訳：Chopper、Foresight News

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

新しいプレプリント論文が、このギャップの具体的な数字を示しています。セキュリティ企業 ack3 とプラハ・チェコ工科大学の関連研究者らは、2026年上半期に報告された135件のセキュリティインシデントを分析しました。これらのインシデントによる損失は9億3986万ドルに上ります。そのうち68件のインシデントには、特定可能な公開事前監査記録があったことが判明しました。

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

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

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

データの真の意味

ack3 のこの研究は、2026年1月1日から6月29日までをカバーし、合計122件の確認された攻撃インシデントと13件の疑わしいインシデントを対象としています。全サンプルのうち、35件のインシデントは監査記録が見つからず、32件は監査履歴が不明であり、これらの2つのカテゴリは上記の68件のインシデントの統計範囲には含まれていません。

68件のインシデントサンプルにおいて、監査範囲外のインシデントによる損失は6億8097万ドル、総損失は7億2124万ドルであり、これにより94.4%というデータが導き出されました。Kelp DAOとDrift Protocolを除外すると、監査範囲外の損失は1億397万ドル、総損失は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財団の事後報告書によると、移行コントラクトは、出金メッセージのシーケンス番号の上位ビットを使用してメッセージが一意であるかどうかを判断していました。しかし、暗号署名はシーケンス番号の下位256ビットのみをカバーしていました。攻撃者は、署名検証の対象外である上位ビットを変更することで、約20分間の間に、正当な署名を持つ2つの出金メッセージを1492回繰り返し送信し、そのうち1490回の呼び出しが実行に成功しました。

このリプレイアタックにより、1.19866億 ICXと531,600 bnUSDが解放されました。報告書公開時点で、ICONは純損失が約150.2 ETHと31,204 USDCであることを確認しました。財団は、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はこれをアラートメカニズムの調整に起因するとしています。このアラートルールは、過去のネットワーク接続障害において多くの誤報を発生させていたため、優先度を高くして当直者に通知していませんでした。財団は、自動停止トリガーメカニズムの導入、サーキットブレーカーの閾値の引き下げ、およびメッセージの一意性とリプレイ防御に関する特別な再審査を計画しています。

このようなリスク管理メカニズムは監査の代わりにはなりませんが、別の重要な質問に答えるものです。すなわち、予防措置が失敗した場合、システムはリスクを迅速に検出し隔離できるかどうかです。

ユーザーが依然として明確な回答を必要とするセキュリティ上の質問

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

aelf の8月のセキュリティインシデントは、別の角度から上記の見解を裏付けています。公開資料には、ランタイム侵入と制御可能な復旧が発生したと記載されていますが、現在の証拠では、攻撃経路が事前の特定の監査範囲内にあったと判断するには不十分です。

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

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

機能を持っていることは、すべてのペイロードの実行が成功したこと、または攻撃者がすべての対象資格情報を取得したり、機密データが外部に漏洩したことを確認するものではありません。aelf は、潜在的な漏洩基準に従って、署名鍵とインフラストラクチャ資格情報をローテーションしたと述べています。

9月11日時点で、この結論は依然として暫定的な判断です。aelf の公式ブログでは、8月26日以降、今回のインシデントに関する特別なアップデートは公開されていません。8月26日の発表では、今後のアップデートと最終的な報告書を公開することを約束していました。

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

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

このセキュリティ記録には、以下の事項が明記されるべきです。審査されたリポジトリとコードのコミットバージョン、デプロイされたコントラクトアドレス、除外されたコンポーネント、特権ロール、依存ライブラリ。同時に、監査完了後のコントラクトアップグレード、鍵管理とローテーションメカニズム、実行時分離戦略、アラートおよびサーキットブレーカーメカニズム、そしてタイムスタンプ付きの資産回収状況（確定損失、凍結資産、未解決のリスクエクスポージャーを区別）も記録されるべきです。

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

1つの監査バッジでは、次の質問に答えることはできません。審査されたコンポーネント、デプロイされたシステム、および障害に対処するメカニズムが、依然として同じセキュリティ境界内にあるかどうか。