【ITニュース解説】I built a red team that attacks our contracts on a throwaway fork — the live chain never feels it

システムエンジニアを目指す皆さんにとって、ソフトウェア開発における「テスト」の重要性は周知の事実だろう。特に、ブロックチェーン上で動作する「スマートコントラクト」のように、一度デプロイされると修正が困難で、かつ巨額の資産が動く可能性のあるシステムでは、そのセキュリティは極めて重要になる。少しの脆弱性が、取り返しのつかない損失につながることもあるからだ。

今回紹介する「DOLOS（ドロス）」は、このスマートコントラクトのセキュリティテストに特化した新しいツールだ。既存のセキュリティ監査やテスト手法だけでは発見が難しかった、あるいはリスクが高すぎて試せなかった種類の脆弱性を、安全かつ効果的に見つけ出すことを目的としている。これまでのセキュリティテストでは、コードの構造を静的に解析して問題箇所を指摘する手法や、システム全体の連携部分を探索する手法が中心だった。しかし、これらの手法だけでは、実際にデプロイされたスマートコントラクトが、具体的な「攻撃」に対してどのように振る舞うのかを完全に予測することは難しいという課題があった。コード上では問題なさそうに見えても、実際に悪意のある操作をされた場合に、思わぬ脆弱性が露呈する可能性があるからだ。

DOLOSが解決しようとした具体的な問題の一つは、テスト環境の共有だ。通常の開発やテストでは、共有された「Anvil」という仮想環境を使うことがある。これは開発者やテスターが同じブロックチェーン環境にアクセスして作業を進めるためのものだ。しかし、この共有環境で攻撃シミュレーションを行い、その結果を「evm_revert」という機能で元に戻そうとすると、同じ環境を使っている他の開発者の活動まで巻き戻してしまうという問題が発生する。これにより、他のテストや実際の運用に支障をきたし、リアルタイムで進行している活動が失われてしまうリスクがあった。DOLOSは、この「共有環境を汚染することなく、本番環境のスマートコントラクトに限りなく近い状態で攻撃を試したい」という強いニーズから生まれた。

DOLOSの最も画期的な点は、「スローアウェイ・フォーク（使い捨ての複製）」という技術を使うことだ。これは、文字通り本番環境（ライブチェーン）の現在の状態をそっくりそのままコピーした「クローン」を一時的に作成し、そのクローンに対して攻撃を仕掛けるというものだ。このクローンは、本番環境のスマートコントラクト、ウォレットの残高、保存されているデータなど、あらゆる情報を完全に複製している。しかし、それはあくまで一時的な「コピー」であり、本番環境とは完全に切り離されている。攻撃が終われば、このクローン環境は破棄されるため、本番環境には何の痕跡も残らない。これは「Attack anything. Risk nothing.（何でも攻撃せよ。何もリスクを負うな。）」というDOLOSの基本的な思想を体現している。

具体的には、DOLOSは「anvil --fork-url」コマンドを使ってライブチェーンのフォークを作成する。このフォークは、攻撃の標的となる環境として機能する。この使い捨てフォークの中では、「evm_snapshot」と「evm_revert」といった機能を自由に使って、攻撃の途中で状態を保存したり、以前の状態に戻したりできる。これにより、様々な攻撃パターンを試したり、特定の攻撃後の影響を詳細に分析したりすることが可能になる。さらに、「anvil_impersonateAccount」という機能を使えば、秘密鍵を持たずに特定のユーザーになりすましてトランザクションを実行できるため、管理者権限を悪用する攻撃や、特定のユーザーのウォレットを狙う攻撃も安全にシミュレートできる。「anvil_setBalance」を使えば、テスト用の偽のEtherを任意のアドレスに付与して、ガス代の心配なく複雑な攻撃を試すこともできる。これらの操作はすべて使い捨てのフォーク内で完結するため、本番環境に影響を与えることは一切ない。

スマートコントラクトのセキュリティテストには、DOLOS以外にもいくつかの層が存在する。例えば、「BASANOS」はコードのコミット時点での静的な健全性を検証する。これは、コードの記述ミスや一般的な脆弱性パターンを早期に発見する役割を担う。「MOMUS」は、ライブチェーン上の外部システム連携（フェデレーション）に関する脆弱性を探る。DOLOSはこれらの中間に位置し、BASANOSが指摘するような「このコードは脆弱性があるかもしれない」という「フラグ」に対して、実際にそのフラグが本当に攻撃可能な脆弱性なのか、それとも誤検知なのかを、使い捨てフォーク上で実際に攻撃を試すことで検証する。例えば、BASANOSが「任意の呼び出し元が特定のチャンネルを書き換えられる可能性がある」とフラグを立てた場合、DOLOSはその「ハイジャック」を実際に試みて、コントラクトがそれを拒否するかどうかを確認する。記事にあるように、ライブのUNIコントラクトでは、DOLOSが攻撃を試みた結果、防御が機能し、脆弱性ではないことが証明されたケースもある。

DOLOSにおける「攻撃」とは、単にコントラクトの関数を呼び出して挙動を見るだけのものではない。それは「コントラクトが本来守るべきだと主張する『不変条件』（Invariant）を、一連のトランザクション操作によって破ることができるかどうか」を試すことだ。例えば、「トークンの総供給量は、承認された発行者によってのみ増加するべき」という不変条件があるとする。DOLOSは、承認されていないアドレスがトークンを発行しようとする攻撃シナリオを実行し、この不変条件が破られるかどうかを確認する。攻撃の結果は明確に3つのクラスに分類される。「held（防御成功）」は、コントラクトが攻撃を拒否し、不変条件を守ったことを示す。「exploited（攻撃成功）」は、不変条件が破られ、脆弱性が確認されたことを示す。「inconclusive（実行不能）」は、何らかの理由で攻撃シナリオが実行できなかったことを示す。ここで重要なのは、「inconclusive」が決して「安全」を意味しない点だ。テストが実行できなかっただけで、脆弱性がないと断定することはできない。

DOLOSは、発見された脆弱性に対する修正プロセスも支援する。使い捨てのサンドボックスフォーク（chainId 31337）上で脆弱性が確認された場合、開発者はそのフォーク内で「攻撃→パッチ適用→テスト→再デプロイ→再攻撃」という修正ループを安全に回すことができる。パッチを適用した後、脆弱性が修正されたかを確認し、さらに元の正しい動作を検証するテスト（正当な挙動スイート）が壊れていないかも確認する。もし修正が正しくない場合や、既存の機能に悪影響を与える場合は、その修正は拒否される。これは、ライブのイミュータブルな（一度デプロイされると変更できない）コントラクトに対しては、発見された脆弱性を「ADVISORY（勧告）」として報告するに留まり、自動的な修正は行わないという方針とは対照的だ。なぜなら、イミュータブルなコントラクトに対して自動修正を試みることは、それ自体が新たな致命的なバグにつながるリスクがあるからだ。DOLOSは、使い捨ての環境だからこそ、このような自由で安全な修正サイクルを実現できる。

最後に、DOLOSが「何ではないか」を理解することも重要だ。DOLOSは、メインネット（本番のブロックチェーン）を攻撃するためのツールではない。静的解析ツールや、外部連携の脆弱性を探るツールとも異なる。また、セキュリティインシデントに対する保険ではないし、AIが勝手に攻撃を生成したり、検証結果を書き換えたりする「AIレッドチーム劇場」でもない。DOLOSは、カタログ化された具体的な攻撃シナリオと、本番環境の正確な複製であるフォーク環境に基づいて、純粋にデプロイされたコントラクトの耐性を評価するツールなのだ。セキュリティ監査、脆弱性スキャン、レッドチーム、保険といった異なる概念を混同してしまうと、見過ごされた脆弱性によって大きな問題が発生する可能性がある。DOLOSは、ライブチェーンに影響を与えずに、実際の攻撃を試すことができる、まさに「失われた中間層」として機能し、スマートコントラクトのセキュリティを高める上で不可欠なツールと言えるだろう。システムエンジニアを目指す皆さんにとって、このようなテスト自動化や、本番環境に影響を与えない安全な検証環境の構築は、非常に重要なスキルセットとなる。DOLOSのコンセプトは、ブロックチェーン以外の分野でも応用可能な、一般的なテスト戦略のヒントを与えてくれるはずだ。