Mystery Box

Summary

The current MysteryBox contract allows any user, including non-trusted users, to deploy the contract and become the owner. This creates a significant security vulnerability, as anyone can deploy the contract, set themselves as the owner, and gain control over key administrative functions such as setting prices, adding rewards, and withdrawing funds. This could lead to potential misuse, abuse of the system, and loss of funds.

Vulnerability Details

1. Non-Trusted Deployment:

   • The contract does not have any mechanism to restrict who can deploy it, meaning any user can deploy the contract and automatically become the owner, as msg.sender is set as the owner in the constructor.

   • Once the contract is deployed by a non-trusted actor, they can control all administrative functions, such as:

     • Setting the box price using setBoxPrice().

     • Adding new rewards using addReward().

     • Withdrawing all funds using withdrawFunds().

2. Risk of Ownership Abuse:

   • A malicious actor who deploys the contract can exploit the ownership privileges to manipulate the reward system, withdraw all funds, or engage in malicious activities, potentially scamming users.

Example Scenario:

1. Initial Setup:

   • A non-trusted or malicious user deploys the MysteryBox contract. Since msg.sender is the deployer, they automatically become the owner.

2. Execution:

   • The non-trusted user sets a high box price, withdraws all the funds from the contract, or adds arbitrary rewards that are not part of the intended system.

3. Outcome:

   • The contract is fully compromised, allowing the non-trusted actor to take advantage of the system. Any users who interact with the contract may be misled or scammed.

Impact

• Control of Administrative Functions: Non-trusted or malicious actors can deploy the contract and immediately become the owner, giving them control over all key contract functions.

• Loss of Funds: Malicious actors can withdraw all the funds in the contract, leading to financial loss for users and the system itself.

• System Manipulation: The ability to set prices and add rewards means that malicious actors could manipulate the reward pool or box prices to mislead users.

Tools Used

Manual review

Recommendations

Factory Contract for Controlled Deployment:

• Factory Contract for Controlled Deployment:

  • Use a factory contract to control the deployment of MysteryBox instances. The factory contract should only allow a trusted entity (e.g., an admin) to deploy new instances. This ensures that only trusted actors can deploy and control the contract.

  Example Factory Contract:

  import "./MysteryBox.sol";

  ​

  contract MysteryBoxFactory {

  address public admin;

  ​

  constructor() {

  admin = msg.sender;

  }

  ​

  modifier onlyAdmin() {

  require(msg.sender == admin, "Only admin can deploy");

  _;

  }

  ​

  function deployMysteryBox(uint256 initialPrice) public onlyAdmin returns (address) {

  MysteryBox newBox = new MysteryBox(initialPrice);

  return address(newBox);

  }

  ​

  function changeAdmin(address newAdmin) public onlyAdmin {

  admin = newAdmin;

  }

  }

• Hardcode Trusted Owner (Single Trusted Deployer):

  • You can hardcode the trusted owner’s address in the constructor so that only a specific, pre-defined address can be the owner of the contract. This prevents non-trusted users from deploying and controlling the contract.

• Example:

  constructor(address _trustedOwner, uint256 initialPrice) {

  require(_trustedOwner != address(0), "Invalid owner address");

  boxPrice = initialPrice;

  transferOwnership(_trustedOwner); // Set ownership to a trusted address

  }