【実務・中級編】外部コントラクト呼び出しにおける低レベルコール(call/delegatecall)の危険性 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

現場で泣きを見る前に：低レベルコール call / delegatecall が引き起こす「暗黒の契約」

やあ。今日は少しシビアな話をしよう。

SCADAやIoTの制御システム、あるいはWeb3のスマートコントラクトに関わるエンジニアなら、「外部呼び出し」がどれほど危険な火種か、一度は痛感したことがあるはずだ。特にSolidityにおける call や delegatecall は、強力な武器であると同時に、扱いを間違えればシステム全体を乗っ取られる「諸刃の剣」だ。

教科書には「戻り値をチェックしろ」としか書いていないだろうが、現場ではその「チェック」の甘さが致命的なインシデントを生む。今日は、攻撃者がどのように足元をすくい、我々はどう防ぐべきか、泥臭い実戦の視点で解説する。

—

1. なぜ call が悪夢の入り口なのか

スマートコントラクトにおける低レベルコールは、対象のインターフェースを知らなくても実行できてしまう。これが最大の問題だ。

攻撃シナリオ：存在しない関数への呼び出し

攻撃者は、あなたが「成功するはずだ」と信じ込んでいる外部呼び出しに対し、存在しない関数や悪意のあるコントラクトをターゲットに設定する。

もし戻り値をチェックしていなければ、Solidityの call は「実行結果が失敗しても、トランザクション全体をRevert（ロールバック）せず、単に false を返して処理を続行する」。

この「処理の続行」こそが、ハッカーの狙い目だ。本来止まるべき処理がそのまま進み、悪意のあるステート書き換えを許してしまう。

—

2. 破壊的な delegatecall の悪用

delegatecall はさらに凶悪だ。これは「外部コントラクトのコードを、呼び出し元のコンテキスト（自分のストレージ）で実行する」というものだ。

もし、呼び出し先のアドレスを攻撃者が操作できる状態（例えば、未初期化のプロキシコントラクトなど）にあれば、攻撃者はあなたのコントラクトのストレージを完全に書き換え、管理者権限を奪取するだろう。

—

3. 実践：セキュアな実装パターン

「戻り値をチェックする」だけでは足りない。「呼び出し先のホワイトリスト管理」と「Revertの強制」が防御の鉄則だ。

以下に、実務でそのまま使える堅牢な呼び出しパターンの実装例を示す。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SecureCallHandler {
    // 信頼できるコントラクトアドレスのみを保持するホワイトリスト
    mapping(address => bool) public allowedContracts;

    error UnauthorizedContract();
    error CallFailed();

    // ホワイトリストの登録（適切にアクセス制限をかけること）
    function addContract(address _target) external {
        // ここにOwnable等のアクセス修飾子を付けるのを忘れるな
        allowedContracts[_target] = true;
    }

    // セキュアな外部呼び出し実行関数
    function safeExecute(address _target, bytes memory _data) external {
        // 1. ホワイトリストによる厳格なフィルタリング
        if (!allowedContracts[_target]) {
            revert UnauthorizedContract();
        }

        // 2. 低レベルコール実行
        (bool success, ) = _target.call(_data);

        // 3. 戻り値の確認と明示的なRevert
        // 成功しなかった場合は即座にトランザクションを終了させる
        if (!success) {
            revert CallFailed();
        }
    }
}

このコードのポイント

ホワイトリスト化: 呼び出し対象をハードコーディングまたは管理可能なリストに限定する。
例外処理（Custom Errors）: require よりもガス代が安く、明確なエラーを発生させる revert を使用する。
成功フラグの確認: (bool success, ) = ... の直後に、if (!success) revert() を書く。これを忘れることは死を意味する。

—

4. インフラ層での防御（WAF / Nginxの設定）

Web3特化の話だけでなく、IoTデバイスのAPIサーバー側でも、外部からのリクエストを同様にガードする必要がある。特に call のような動的な呼び出しをトリガーするAPIエンドポイントには、Nginx側でレート制限とIP制限を噛ませるのが定石だ。

/etc/nginx/conf.d/api.conf の設定例：

# 特定のAPIエンドポイントに対するリクエスト制限
location /api/v1/execute-external {
    # 攻撃者による総当たりを防ぐためのレート制限
    limit_req zone=api_limit burst=5 nodelay;

    # 許可された内部ネットワークまたはプロキシからのアクセスのみ許可
    allow 10.0.0.0/24;
    deny all;

    proxy_pass http://backend_cluster;
}

—

最後に：エンジニアへの提言

脆弱性というものは、コードのミスよりも「仕様の誤解」から生まれることが多い。低レベルコールを使う際は、「この呼び出し先は、本当に自分が意図した場所か？」「失敗した瞬間にシステムを停止させる勇気はあるか？」と自分に問いかけてほしい。

セキュリティは「ツールを入れたら終わり」ではない。常に疑い、境界を定義し、異常を即座に遮断する設計思想こそが、インシデントを防ぐ唯一の盾となる。

君たちのコードが、明日も堅牢であることを願っている。健闘を祈る。