Mystery Box

First Flight #25
Beginner FriendlyFoundry
100 EXP
View results
Submission Details
Severity: medium
Valid

Weak Source of Randomness in `openBox` Function.

Vulnerability Details

The openBox function is supposed to generate a random number using a combination of block.timestamp and msg.sender as entropy for the keccak256 hash function:

function openBox() public {
require(boxesOwned[msg.sender] > 0, "No boxes to open");
@> uint256 randomValue = uint256(keccak256(abi.encodePacked(block.timestamp, msg.sender))) % 100;
.........
.........

This approach to generating randomness is problematic due to its reliance on two factors:

  1. block.timestamp: This value can be influenced by validators, especially within a small range. By slightly adjusting the block's timestamp, a validator could potentially influence the outcome of the randomValue.

  2. msg.sender: Since the user’s address is static and known, it doesn’t contribute much randomness in the broader context of entropy.

These weaknesses result in poor randomness, making it possible for an attacker to predict or manipulate the outcome of the function, potentially yielding more valuable rewards from the mystery box (like Silver or Gold Coins). The vulnerability arises because the reward distribution heavily relies on the value of randomValue, which dictates whether a user receives a common or rare reward.

Impact

The weak source of randomness could allow validators to manipulate the block's timestamp to influence the reward distribution. By exploiting this weakness, a malicious actor/validator could significantly increase their chances of receiving high-value rewards, such as Silver Coins or Gold Coins, instead of lower-value items like Coal or Bronze Coins. This manipulation could lead to the draining of the contract’s reward pool, causing financial loss to the contract's owner and other users.
For example, if a malicious validator can influence the block's timestamp to push the randomValue into the range that grants Silver or Gold rewards more frequently, they could systematically exploit this to drain the contract.

Tools Used

Manual review, Visual Studio Code (VSCode)

Recommendations

To mitigate this vulnerability, it's recommended to use a more secure source of randomness that cannot be manipulated by validators or malicious users. One common approach is to leverage Chainlink VRF, which provides provably fair and tamper-resistant randomness.

Updates

Appeal created

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

Weak Randomness

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!