【実務・中級編】コントラクトの初期化不備(Uninitialized Proxy)による乗っ取り – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

プロキシコントラクトの「初期化忘れ」が招く、スマートコントラクト乗っ取りの悪夢

現場のエンジニア諸君、お疲れ様。今日は、Web3のデプロイメントにおいて「最も初歩的かつ致命的」なミスの一つ、Uninitialized Proxy（初期化不備）について話そう。

パブリックブロックチェーン上で、一度デプロイしたコントラクトのコードを修正できる「アップグレード可能（Upgradeable）」な設計は、一見便利だ。しかし、この仕組みを支えるプロキシパターンが、セキュリティ上の最大の「盲点」になっていることを理解しているか？

今回の記事では、攻撃者がどうやってこの「空き家」を特定し、権限を奪い取るのか。そして、それを防ぐために明日から現場で導入すべき防御策を解説する。

—

1. なぜ「初期化不備」が致命的なのか

まず前提として、アップグレード可能なコントラクト（Transparent Proxy等）では、通常のコンストラクタではなく、initialize() といった関数を使って初期状態を設定する。

この関数の最大の問題点は、「誰でも一度だけ呼び出せる」という仕様だ。もし、デプロイ直後にコントラクトがこの関数を呼び出し忘れていたり、呼び出しを想定していない状態で放置されていたりするとどうなるか？

攻撃者は、誰よりも早くそのコントラクトに対して initialize() をコールする。すると、攻撃者が「コントラクトの所有者（Owner）」として登録され、そこから先はやりたい放題だ。悪意のある実装へのアップグレード、資金の引き出し、あるいはコントラクトの破壊に至るまで、全てが正当な「所有者権限」として実行される。

2. 攻撃者が狙うPoCの正体

攻撃者が利用するのは、Etherscan等の公開ツールと、シンプルなスクリプトだ。彼らはデプロイ直後のトランザクションを監視し、initialize 関数が呼ばれていないコントラクトをスキャンしている。

以下は、脆弱な状態のプロキシに対して、攻撃者が所有権を強奪する際に用いるJS（ethers.js）の簡易的なイメージだ。

// 攻撃者の視点：初期化されていないコントラクトを乗っ取るPoC
async function hijackContract(proxyAddress) {
    const abi = ["function initialize(address _owner) external"];
    const contract = new ethers.Contract(proxyAddress, abi, attackerWallet);

    // 自分のアドレスをオーナーとして登録！
    // これにより、攻撃者が実質的な管理権限を握る
    const tx = await contract.initialize(attackerWallet.address);
    await tx.wait();
    
    console.log("コントラクトを乗っ取りました。");
}

たったこれだけで、開発者が何ヶ月もかけて設計したロジックが、一瞬で「攻撃者のもの」になる。

—

3. 完全防御：Initializable の活用とデプロイ時の鉄則

この脆弱性を封じるための解は、Solidityの標準ライブラリである OpenZeppelin の Initializable コントラクトを継承することだ。

以下のコードを実装のベースラインとして徹底してほしい。

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

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract SecureVault is Initializable, OwnableUpgradeable {
    
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        // コンストラクタで _disableInitializers() を呼ぶことで、
        // 実装コントラクト自体が初期化されることを防ぐ（必須）
        _disableInitializers();
    }

    function initialize(address initialOwner) public initializer {
        // initializer 修飾子により、この関数は一度しか実行できない
        __Ownable_init(initialOwner);
    }
}

現場で守るべき「デプロイの鉄則」

1. コンストラクタで _disableInitializers() を呼ぶ: これを忘れると、実装コントラクトそのものが乗っ取られる危険がある。
2. デプロイと初期化をアトミックに行う: Hardhat 等のデプロイ環境では、デプロイ用のスクリプト内で、コントラクトの生成と同時に initialize を呼び出すようパイプラインを組むこと。
3. テストで初期化チェックを網羅する: テストコード内で「デプロイ直後の関数呼び出し」が失敗すること、または「二回目の initialize 呼び出し」が確実に revert されることをアサーション（検証）に含める。

—

4. 最後に：セキュリティは「仕様」の一部だ

「後で初期化すればいいや」という油断が、数億円規模の被害を生む。Web3における開発は、Web2のWebアプリ開発とは比べ物にならないほど「後戻りが効かない」世界だ。

もし君がチームのリーダーなら、デプロイ手順書に以下のチェックリストを追記してほしい。

[ ] 実装コントラクトで _disableInitializers() を呼んでいるか？
[ ] デプロイ用スクリプトが、コントラクトの生成直後に initialize() を実行しているか？
[ ] CI/CD環境で、初期化後のステータスを自動検知するテストが走っているか？

コードは嘘をつかないが、甘い実装は裏切る。技術的な負債を抱える前に、この「初期化の呪縛」を断ち切る実装を今日から標準化してほしい。

何かあれば、いつでも相談してくれ。堅牢なシステムを作るのは、いつだって「慎重すぎるくらいの準備」から始まるんだ。