Mystery Box

Description

The changeOwner function in the MysteryBox contract allows anyone to change the ownership of the contract without any access control restrictions. The function is declared as public and lacks any modifiers (or a require stat) or checks to ensure that only the current owner can invoke it. As a result, any user can call the changeOwner function and set themselves or any other address as the new owner of the contract.

Impact

Allowing unrestricted access to the changeOwner function can lead to severe consequences:

1. Complete Control Hijacking:

• Financial Theft: A malicious actor can transfer ownership to themselves and subsequently call privileged functions like withdrawFunds to drain all Ether from the contract.

• Manipulation of Contract Parameters: The new owner can alter critical parameters such as boxPrice, add malicious rewards, or disrupt the reward distribution mechanism, undermining the contract’s functionality.

2. Loss of User Funds:

• Users who have purchased boxes and are expecting rewards may find their funds or rewards inaccessible if the contract’s Ether balance is drained by the new owner.

3. Erosion of Trust:

• Users may lose confidence in the contract’s security and reliability, leading to decreased participation and adoption.

• Negative reputation can deter potential users and investors, impacting the project’s overall success.

4. Legal and Regulatory Risks:

• Unauthorized control over funds can lead to legal liabilities, especially if users suffer financial losses due to the vulnerability.

5. Contract’s Functional Integrity:

• The ability to unilaterally change ownership compromises the contract’s intended operations, making it unpredictable and unreliable.

PoC

1. Deployment:

• Deploy the MysteryBox contract with an initial owner, say Alice.

2. Unauthorized Ownership Transfer:

• Any user, including Bob, calls the changeOwner function to set themselves as the new owner.

3. Exploitation by New Owner:

• Bob, now the owner, calls the withdrawFunds function to transfer all Ether from the contract to his address.

4. Outcome:

• The contract’s Ether balance is drained by Bob.

• Users attempting to claim rewards will find the contract unable to fulfill their claims due to insufficient funds.

• The contract’s ownership has been maliciously transferred, undermining its integrity and functionality.

Tools Used

• **Manual Code Review: **Analyzing the smart contract’s source code to identify the lack of access control in the changeOwner function.

Recommendations

• Implement Access Control Modifiers: Restrict the changeOwner function to be callable only by the current owner using an onlyOwner modifier.

• Adopt Established Ownership Patterns: Utilize OpenZeppelin’s Ownable contract, which provides secure and standardized ownership management.