Mystery Box

Summary

The changeOwner function in the MysteryBox contract was identified as vulnerable to unauthorized ownership transfer, allowing any user to assume control over the contract without restriction. Tests confirmed that, without proper access control, this vulnerability could lead to significant risks, including unauthorized fund withdrawals, reward manipulation, and potential denial-of-service attacks. This report emphasizes the importance of implementing strict access controls on sensitive functions that manage contract ownership.

Vulnerability Details

The changeOwner function lacked appropriate access control, allowing any user to change the contract's owner without being the current owner. This presents a critical security flaw, as a malicious actor could exploit this function to gain full control over the contract, leading to significant losses and contract manipulation.

Details:

• Lack of Access Control: The function did not verify whether the caller was the current owner, making it vulnerable to unauthorized transfers.

• Impact: An attacker could take over the contract, withdraw all funds, modify rewards, and deny legitimate users access to their rewards or boxes.

Code Analysis

Original changeOwner Function:

Key Issues:

• There was no require statement checking if msg.sender was the current owner, allowing anyone to execute this function and change ownership.

• This created a significant vulnerability, as ownership transfer is a critical function that should only be executed by the current owner.

Modified Function with Access Control:

Key Strength:

• The require(msg.sender == owner) statement ensures that only the current owner can transfer ownership, securing the function against unauthorized access.

Impact of Unauthorized Access

If the changeOwner function is exploited, an attacker would gain control over the following:

1. Withdraw All Contract Funds: The attacker could call the withdrawFunds function to transfer all Ether from the contract to their address.

2. Manipulate Rewards: The attacker could add or remove rewards, potentially altering the reward pool's value or preventing users from claiming legitimate rewards.

3. Denial of Service: The attacker could prevent users from buying or opening boxes, effectively rendering the contract unusable.

Proof of Concept (PoC)

1. Before Protection: A test was conducted to simulate an unauthorized ownership transfer using the changeOwner function. The attacker successfully changed the owner to their address without any restriction.

Results:

• Before the Attack: The initial owner of the contract was correctly set to initialOwner.

• During the Attack: The attacker initiated the process using vm.startPrank to simulate actions from their address and successfully executed changeOwner to take control of the contract.

• After the Attack: The test confirmed that the contract ownership was transferred to attackerAddress. This demonstrated that the changeOwner function is vulnerable to unauthorized changes, as it lacked the necessary access controls.

The test conclusively shows that any address can exploit this function and assume ownership of the MysteryBox contract, emphasizing the critical need to implement proper access controls.

1. After Protection: After implementing the require(msg.sender == owner) check, the same test was rerun. This time, the attacker was unable to change ownership, and the test reverted with the error message "Only owner can change ownership."

Results:

• The test failed for the attacker, confirming that the changeOwner function is now secure.

Impact

• Critical Contract Takeover: Without protection, this vulnerability allows complete control over the contract to unauthorized users.

• Effective Mitigation: Implementing the require(msg.sender == owner) check successfully protected the function, ensuring that only the legitimate owner can transfer ownership.

Tools Used

• Manual code analysis

• Foundry for testing unauthorized ownership changes

Recommendations

1. Implement Access Control: Always include access control checks (require(msg.sender == owner)) on functions that handle sensitive operations, such as ownership changes.

2. Utilize OpenZeppelin’s Ownable Contract: Consider inheriting from OpenZeppelin’s Ownable contract, which provides standardized ownership management with built-in access controls.

3. Regular Security Audits: Regularly audit smart contracts, especially those with sensitive functions like changeOwner, to ensure no unauthorized access points exist.

Conclusion

The changeOwner function was highly vulnerable to unauthorized access, posing a significant threat to the MysteryBox contract's integrity and funds. By implementing proper access control checks, we have mitigated this risk, ensuring that only the rightful owner can change the contract's ownership. This serves as a critical reminder of the importance of securing functions that manage sensitive operations in smart contracts.