Web3攻撃対象領域:ペネトレーションテストの概要

このシリーズの最初の3本の記事では、暗号資産機関がなぜブロックチェーンペネトレーションテストを必要とするのか(Part 1)、この分野が何を検証するのか(Part 2)、そして機関向けエンゲージメントをどのように準備し安全に実施できるのか(Part 3)について解説しました。

本記事では、web3機関に対するペネトレーションテストに関連する攻撃対象領域の概要を示し、特に必要とされるカバレッジが従来のペネトレーションテストの対象領域をどのように超えて広がるかに焦点を当てます[1]。具体的には、まずweb3機関に関する4つのコンポーネントからなるモデルを定義し、各コンポーネントの責務、代表例、および主要な攻撃対象領域を示します。このモデルを踏まえたうえで、次に、署名意図、承認および署名ワークフロー、資金ロジック、オンチェーンランタイム挙動におけるweb3固有の検証ポイントと、既存のアプリケーションおよびインフラの露出とを結び付ける5つの攻撃対象領域を検討します。

web3機関を構成するコンポーネント

中央集権型取引所、決済プロバイダー、DeFiプロジェクトを含むweb3機関は、従来型のアプリケーションおよびインフラ環境を、オフチェーンからオンチェーンへの資金取扱チェーンに接続します[2]。これらの機関は従来のペネトレーションテスト対象領域を保持しつつ、トランザクション意図、署名権限、資金会計、オンチェーン実行に関する追加の検証ポイントを導入しています。これらの領域がどのように相互作用し、どの条件が価値へと至る経路を形成しうるかを特定するには、web3セキュリティに特化した専門的な判断が必要です。

この拡張された攻撃対象領域を体系的に検証するため、本セクションではApplication(アプリケーション)、Authorization and Signing(認可と署名)、Blockchain Interaction(ブロックチェーンインタラクション)、**Infrastructure(インフラ)**という4つのコンポーネントからなるモデルを定義します。各コンポーネントについて、その責務を説明し、代表的な実装例を示し、主要な攻撃対象領域を要約します。なお、web3機関によっては、これらのコンポーネントを異なる形で組み合わせたり、外部委託したりする場合があることに留意してください。

コンポーネント1: Application(アプリケーション)

Applicationコンポーネントは、定義されたビジネスロジックおよび認可ロジックのもとで、ユーザーまたは社内オペレーターからのリクエストを処理し、認可された意図を、資産の送金や復旧操作といった意図されたビジネスアクションへと変換します。web3機関における一般的な代表例には、ウェブおよびモバイルアプリケーション、ブラウザ拡張機能、バックエンドAPIが含まれます。

一般的なテストの種類。

• Web Application Penetration Testing(ウェブアプリケーションペネトレーションテスト)

• Mobile Application Penetration Testing(モバイルアプリケーションペネトレーションテスト)

• Browser Extension Penetration Testing(ブラウザ拡張機能ペネトレーションテスト)

• API Penetration Testing(APIペネトレーションテスト)

Applicationコンポーネントは、アイデンティティおよびセッション管理、認可と分離、ビジネスワークフローおよび状態遷移の整合性といった従来型の攻撃対象領域を引き継いでいます。web3機関においては、この段階で準備されたビジネスアクションまたはトランザクション意図は、その後Authorization and Signingコンポーネントによって認可され、Blockchain Interactionコンポーネントを通じて実行される場合があります。したがって、これらの制御における不備は、サービスの中断につながるだけでなく、直接的な資産損失へと波及する可能性があります。

コンポーネント2: Authorization and Signing(認可と署名)

Authorization and Signingコンポーネントは、Applicationコンポーネントによって準備されたトランザクションリクエストを受け取り、オンチェーンへの送信に必要な暗号署名を生成します。実装によっては、署名を生成する前に、署名システム内でポリシーまたは承認のチェックを追加で行う場合もあります。web3機関における一般的な代表例には、ウォレットおよび署名システムまたはサービスが含まれます。

一般的なテストの種類。

• Identity and Privileged Access Testing(アイデンティティおよび特権アクセステスト)

• Signing and Approval Workflow Testing(署名および承認ワークフローテスト)

Authorization and Signingコンポーネントが引き継ぐ従来型の攻撃対象領域には、特権アイデンティティおよびアクセス管理、API認可と職務分掌、承認、復旧、および管理ワークフローの整合性が含まれます。web3機関においては、有効な署名が不可逆的な状態変更や資産移転を直接的に認可し得るため、このコンポーネントにおける不備は特に深刻な結果を招く可能性があります。オンチェーン送信前における最終的な暗号的認可ステップとして、Authorization and Signingコンポーネントは、それが使用される場面において重要な保証の優先事項として扱われるべきです。

コンポーネント3: Blockchain Interaction(ブロックチェーンインタラクション)

Blockchain Interactionコンポーネントは、ユーザーまたは社内オペレーターによって認可されたトランザクションを送信し、その実行ステータスを確認し、結果として生じるオンチェーン状態を追跡します。web3機関における一般的な代表例には、ノードまたはRPCゲートウェイ、インデクサー、リレーヤーが含まれます。

一般的なテストの種類。

• API and RPC Penetration Testing(APIおよびRPCペネトレーションテスト)

• Transaction-Submission and Relayer Abuse Testing(トランザクション送信およびリレーヤー悪用テスト)

Blockchain Interactionはweb3運用に固有の役割を果たしますが、このコンポーネントのペネトレーションテストは、その引き継がれた攻撃対象領域が敵対的に悪用可能かどうかに主眼を置きます。すなわち、サービス認証情報とエンドポイントのセキュリティ、RPCおよびAPI認可、メッセージおよびイベント処理の整合性――たとえば、RPCやリレーヤーの挙動が悪用され得るか、トランザクション送信が操作され得るか、あるいはチェーンイベントが誤って解釈され得るか――です。カスタマイズされたブロックチェーンノードや自己ホスト型ノードを運用する機関にとって、ノードおよびクラスタの正確性、ならびに大規模なRPCレジリエンス――同期、トランザクション伝播、フェイルオーバー、可用性――は、ペネトレーションテストではなくBlockchain Security Testingが扱う補完的な懸念事項です[2]。

コンポーネント4: Infrastructure(インフラ)

Infrastructureコンポーネントは、他の3つのコンポーネントを支える、あるいはそれらに影響を与える、機関固有のインフラおよび運用システムを対象とします。web3機関における一般的な代表例には、クラウドプラットフォーム、ネットワークインフラ、IAMおよびシークレット管理システム、ソースコード管理およびCI/CDシステム、モニタリングプラットフォームが含まれます。

一般的なテストの種類。

• External and Internal Network Penetration Testing(社外および社内ネットワークペネトレーションテスト)

• Cloud Infrastructure Penetration Testing(クラウドインフラペネトレーションテスト)

• CI/CD and Software Supply Chain Testing(CI/CDおよびソフトウェアサプライチェーンテスト)

Infrastructureは主に従来型の攻撃対象領域を引き継いでおり、これにはネットワークおよびサービスの露出、アイデンティティ、権限、シークレット管理、ソフトウェア配布およびサプライチェーンの整合性が含まれます。Infrastructureは通常、資金取扱アクションを直接実行するわけではありませんが、その障害または侵害は重大な資産損失につながる可能性があります。Part 1で取り上げたBybitおよびTrustWalletのインシデントは、ソフトウェアの配布・流通経路における侵害が、どのように資金取扱チェーンへと波及し得るかを示しています[1]。

web3の攻撃対象領域

4コンポーネントモデルは、web3機関のペネトレーションテストが従来のアプリケーションおよびインフラの攻撃対象領域の多くを保持していることを示しています。その違いは資金取扱という文脈にあります。すなわち、脆弱性はコンポーネント間を伝播し、トランザクション意図、署名、資金状態、あるいはオンチェーン実行に影響を及ぼし得ます。したがって、こうした経路を特定し、適切な検証ポイントを選定するには、web3セキュリティに特化した専門的な判断が必要です。

このカバレッジを体系化するため、本セクションでは、Part 2で紹介された資金取扱チェーンおよびテスト範囲に基づく5つの主要な攻撃対象領域にweb3の攻撃対象を分類します[2]。

• 本番環境および自動化された運用オペレーション

• ウェブおよびdAppのフロントエンド、認可、署名意図

• 署名、承認、出金の認可チェーン

• 資金ビジネスロジック

• オンチェーントランザクションおよびデプロイ済みコントラクト

本番環境および自動化された運用オペレーション

本番環境は、資金取扱チェーンのあらゆる段階を支えています。従来型のインフラ、アイデンティティ、あるいはソフトウェア配布における足がかりは、資金を直接動かすものではないかもしれませんが、Applicationの挙動を変化させたり、Authorization and Signingに到達したり、Blockchain Interactionに影響を与えたりする可能性があります。したがって、ブロックチェーンペネトレーションテストでは、インフラに関する発見事項を孤立したエンドポイントとして扱うのではなく、その足がかりが資金取扱チェーンに及ぼしうる到達可能な影響を評価します[2]。

テストの焦点。 テスターは、アクセス、デプロイ、シークレット、あるいは運用制御が、資金取扱アクションへと連鎖し得るかどうかを検証します。シナリオは、露出したサービス、侵害されたアイデンティティ、ワークロード認証情報、ビルドトークン、依存関係、あるいはベンダー統合から始まることがあり、その後、IAM、セグメンテーション、シークレット管理、変更管理、サービス認可がさらなる到達を防いでいるかどうかを評価します。得られる証跡は、運用上の足がかりを、それが影響を及ぼしうるコンポーネントおよび価値移転アクションと結び付けるものであるべきです。

詳細な分析[3]では、本番環境の侵害がデプロイおよび運用制御を通じて資金取扱コンポーネントへとどのように波及しうるかを検証します。

ウェブおよびdAppのフロントエンド、認可、署名意図

ウェブおよびdAppのフロントエンドは、ユーザーおよびオペレーターが資金取扱アクションを開始・確認し、そのアクションが承認される認可・署名フローに参加する主要なインタラクション層です。この位置づけにより、これらはフィッシングおよびフロントエンドの乗っ取りにとって魅力的な標的となります。インターフェースを掌握することで、トランザクションリクエストがウォレットや署名システムに到達する前に、その文脈や内容を操作できるためです[1]。

テストの焦点。 テスターは、ユーザーまたはオペレーターに提示されたトランザクションが、最終的に認可されるアクションと乖離しうるかどうかを検証します。この評価は、アプリケーションの認証・認可から、トランザクションの構築、ウォレットへの提示、署名、送信に至るまでリクエストを追跡し、セッション状態、ウォレットの権限、シミュレーション、チェーンコンテキスト、コントラクトコンテキスト、あるいは表示ロジックが意味を変化させうるかどうかを検討します。証跡には、提示されたアクション、実際のペイロード、生成された署名、送信された挙動を保持する必要があります。

詳細な分析[4]では、アプリケーションでの提示からウォレットでの認可を経て、署名済みまたは送信済みの結果に至るまでトランザクション意図を追跡し、アクションの意味が乖離しうる箇所に焦点を当てます。

署名、承認、出金の認可チェーン

署名はしばしば資金を動かすアクションですが、暗号学的な有効性だけでは、正しいビジネス上の権限が確立されているとは言えません。セキュリティ上の結果は、誰がリクエストを開始したか、どのポリシーが適用されたか、承認者が何を確認したか、そしてペイロードが変更されないまま維持されたかどうかにも依存します。この制御チェーンにおける弱点は、正当な署名者が意図しないアクションを認可してしまう原因となり得ます[2]。

テストの焦点。 テスターは、アイデンティティ、ロール、ポリシーチェック、あるいは承認ステップが回避されたり組み合わされたりしうるかどうかを検証します。シナリオでは、1つのアイデンティティがアクションの開始と承認の両方を行えるかどうか、送金先や上限の変更が独立したレビューなしに有効になるかどうか、ポリシーが署名者側で強制されているのか、あるいはインターフェース側だけで強制されているのか、あるいは承認後にペイロードが変更されうるかどうかを評価する場合があります。証跡には、テストされたシーケンス、突破された制御、可能となった不正なアクションを文書化する必要があります。

詳細な分析[5]では、機関の承認および署名ワークフローが、トランザクションの開始から署名、出金の実行に至るまでビジネス上の権限を維持しているかどうかを検証します。

資金ビジネスロジック

カストディ型機関は、残高、債務、そして価値をリリースしてよいかどうかを判断するためにオフチェーン状態に依存しています。したがって、意図しないクレジットや状態遷移は、署名鍵やスマートコントラクトが侵害されていない場合であっても、直接的な財務損失となり得ます。テストでは、個々のAPIが実装通りに動作するかどうかだけでなく、経済的な不変条件および照合経路も考慮する必要があります[2]。

テストの焦点。 テスターは、残高、上限、照合、出金ルール、あるいは状態遷移が意図しない条件を受け入れてしまうかどうかを検証します。シナリオでは、期待される金額なしに入金がクレジットされるかどうか、1つのイベントが複数のクレジットを生み出すかどうか、精度や並行処理によって残高が変化するかどうか、あるいは無効な状態が出金可能になるかどうかを検討する場合があります。証跡には、単なる技術的な不具合だけでなく、結果として生じる状態遷移と再現可能なビジネス影響経路を記録する必要があります。

詳細な分析[6]では、意図しないオフチェーン資金状態が、機関のワークフーク全体を通じて、どのように生成、伝播され、出金可能な価値へと転換されうるかを検証します。

オンチェーントランザクションおよびデプロイ済みコントラクト

オンチェーンへの受け渡しは、オフチェーンでの意図が公開されたランタイム挙動へと変わる地点です。トランザクションは不可逆的である場合があり、デプロイされたコントラクトは公開的に呼び出し可能であり、機関の直接的な管理下にないシステムとも組み合わせ可能です。したがって、この評価では、意図されたアクション、送信されたトランザクション、観測された実行、そして機関が解釈した状態との間の関係を維持する必要があります[2]。

テストの焦点。 テスターは、機関のオンチェーンでのインタラクションが敵対的なランタイム条件下でどのように振る舞うかを検証します。シナリオでは、トランザクションのフィールドが構築、署名、送信の各段階を通じて変化しうるかどうかを検討する場合があります。また、RPCやリレーヤーの挙動がアクションに影響を及ぼすかどうか、チェーンイベントが正しく解釈されているかどうか、そしてデプロイされた権限、アップグレード、あるいはプロトコルの組み合わせが期待される結果を変化させるかどうかについても評価する場合があります。証跡には、送信されたトランザクション、関連するチェーンコンテキスト、観測されたランタイムの結果を保持する必要があります。

この領域については、ペネトレーションテストは引き続き、敵対的なランタイムインタラクションおよびトランザクションレベルの証跡に重点を置きます。コードレベルでのコントラクトの保証はCode Auditの範囲内に留まり、ノードやクラスタの正確性、および大規模なRPCレジリエンスはBlockchain Security Testingの範囲内に留まります[2]。

結論

ブロックチェーンペネトレーションテストは、従来の評価で検証される従来型のアプリケーションおよびインフラの攻撃対象領域を保持しています。それを際立たせているのは、リクエスト処理、認可、ソフトウェア配布、あるいはインフラにおける不備が、暗号署名、資金状態、あるいはオンチェーン実行に影響を及ぼし得る機関の資金取扱チェーンを通じて、それらの侵入口を超えて脆弱性を追跡する必要性です。

これらの関係性を明確にするため、本記事では4コンポーネントモデルを用いています。Applicationはビジネスアクションを準備し、Authorization and Signingは署名を生成し、Blockchain Interactionはトランザクションを送信し結果を解釈し、Infrastructureは他のコンポーネントを支える、あるいはそれらに影響を与えます。さらに、5つの攻撃対象領域は、特にトランザクション意図、署名権限、資金ロジック、オンチェーンランタイム挙動の境界において、web3セキュリティに特化した専門的な判断が最も重要となる箇所を特定します。

続く4本のガイドでは、この概要をさらに掘り下げ、アプリケーションの認可・署名意図、クラウドおよびCI/CDセキュリティ、トレジャリー管理、取引所の台帳ロジックに関する専門的な分析を展開します。オンチェーントランザクションおよびデプロイ済みコントラクトについては、引き続き本概要でカバーされます。

BlockSecは、コンポーネント、所有者、資金フロー、信頼境界をマッピングし、攻撃者の視点を選定し、安全な証跡を定義し、重要となりうる潜在的な経路を検証することで、4コンポーネントモデルと5つの攻撃対象領域を、テスト可能なスコープへと落とし込むお手伝いをします。次のエンゲージメントに向けて攻撃対象領域をスコープ設定するには、スコープ設定に関する相談を依頼してください。詳細情報はご要望に応じて提供いたします。

同シリーズでは、以下も近日公開予定です。

• Part 5: Authorization and Signing Security: Web, dApps, and
• Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

Blockchain Penetration Testingのピラーページでは、エンゲージメントレベルの全体像を提供しています。

参考文献

初出順に番号を付与。

1. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
2. BlockSec, What Is Blockchain Penetration Testing? Definitions and Boundaries.
3. BlockSec, 近日公開予定。
4. BlockSec, 近日公開予定。
5. BlockSec, 近日公開予定。
6. BlockSec, 近日公開予定。