分散型金融(DeFi)のヴォールトから、プロトコルが送金先を事前承認されたアドレスに限定するセキュリティ統制であるアドレスホワイトリストを運用していたにもかかわらず、攻撃者によって600万ドルが流出しました。バグ報奨金・セキュリティプラットフォームのImmunefiが本件を公開し、600万ドルの損失を確認しています。この侵入は、ヴォールト契約におけるホワイトリストベースの認可の実装および監査の重大な欠陥を露呈させています。ヴォールト契約は単一の契約権限の背後に多数のユーザーの預け入れ資産を集中させるため、一つの認可チェックの失敗が預け入れ側にとって大きな即時損失につながり得ます。

具体的なプロトコル、ブロックチェーンネットワーク、トランザクションハッシュ、攻撃ベクトルは執筆時点で公表されておらず、これらの事実以外の詳細は未確認のままです。

アドレスホワイトリストが防げなかったもの

アドレスホワイトリストは、ヴォールトからの引き出しや資産転送が事前承認された固定のアドレス群にのみ送られることを強制することを目的としています。理論上、自身のアドレスをリストに追加できない攻撃者は資金を持ち出せません。しかし実際には、この統の強度は、リスト更新を管理するロジック、それを管理する管理者機能へのアクセス制御、そして権限のあるヴォールトメソッドを呼び出し得る相互作用する契約に依存します。

一般的な失敗ポイントには、流出前に悪意あるアドレスを追加することを許す管理者キーの侵害、ホワイトリストチェックを完全に回避するリエントランシーやコールバック経路、プロキシインターフェースと同一の制限を実施しない設定不備のプロキシ契約が含まれます。確定した事後検証がないため、預け入れ側は今回攻撃者がどの経路を利用したかをまだ特定できていません。

ホワイトリスト単独ではヴォールトセキュリティとして不十分な理由

ホワイトリストは境界統制であり、多層防御の仕組みではありません。業界慣行では、ホワイトリスト型の引き出し制御は通常、許可制または機関投資家向けのヴォールトフローと関連付けられており、より厳格な運用管理の代償として管理者キーの集中リスクが伴います。今回注目されているのはまさにこの依存関係です。ヴォールトセキュリティはまた、契約に機能する一時停止(ポーズ)メカニズムがあるか、緊急引き出しがタイムロックによって制限されているか、ホワイトリスト更新機能がマルチシグ承認やガバナンス遅延を必要とするかにも依存します。これらの層のいずれかが欠けていたり設定不備であったりすれば、単一の侵害されたキーやロジックのバグによってホワイトリストは無意味になり得ます。

ホワイトリスト付きヴォールトを評価する預け入れ側は、ホワイトリストを更新できる管理者キーを誰が管理しているか、ホワイトリスト追加のタイムロック遅延がどの程度か、ヴォールト契約がアップレード可能なプロキシの背後に配置されているか、独立した監査が認可経路を特に検証したかを確認すべきです。こうした情報開示なしに「ホワイトリスト対応」と謳われるヴォールトは、そのラベルが示すよりも弱い保証しか提供しません。このパターンは、クリア済みのバグが悪用可能な状態を再び持ち込んだマルチチェーンプロトコルのインシデントで見られた認可経路の問題と類似しています。

預け入れ側と運営者のための即時確認事項

アドレスホワイトリストを使用するヴォールトに資金を預けている預け入れ側は、Immunefiの公開以降、プロトコルが一時停止や緊急の発表を行ったかどうかを確認すべきです。影響を受けたプロトコルが公表されていない場合、即時の対応としてはImmunefiの公開フィードおよび当該プロトコルの公式ガバナンスフォーラムを注視することが挙げられます。状況を明確にしうる展開としては、影響を受けたプロトコルとチェーンを特定する修正された公開情報、攻撃ベクトルを特定する事後検証レポートの公表、流出資金のオンチェーンでの目に見える移動があります。

ヴォールト運営者は本件を、認可経路全体を監査する契機と捉えるべきです。ホワイトリストが存在するかどうかだけでなく、ヴォールトロジックへのすべてのエントリーポイントが同一のチェックを実施しているか、管理者機能がマルチシグで保護されているか、ホワイトリスト更新トランザクションで監視アラートが発火するかを検証する必要があります。異常な転送から数分以内に発動できない一時停止機能は、実質的な保護を提供しません。ヴォールトパラメータを管理するガバナンス体制も、ヴォールトのアーキテクチャ決定が預け入れ側を管理者キー集中リスクに晒していないかを再確認すべきです。

600万ドルの損失は、アドレス承認ポリシーが必要不可欠でありながら不十分な統制であることを改めて示しています。ヴォールトセキュリティには多層的な執行が必要です。すなわち、管理者機能へのアクセス制御、状態変更操作へのタイムロック、リアルタイム監視、そして検証可能な一時停止を含む、テスト済みのインシデント対応経路です。