Eggstravaganza

First Flight #37
Beginner FriendlySolidity
100 EXP
View results
Submission Details
Severity: high
Valid

PRNG in searchForEgg() Allows Attackers to Manipulate NFT Rewards

Summary

The randomness implementation within the EggHuntGame smart contract relies on insecure and predictable blockchain parameters (block.timestamp, block.prevrandao, and msg.sender) on EggHuntGame::searchForEgg , allowing an attacker to manipulate outcomes by choosing when to send their transaction.


Vulnerability Details

The affected code appears in the EggHuntGame::searchForEgg() function that implement random number generation logic:

function searchForEgg() external {
...
// This is the issue
uint256 random = uint256(
keccak256(abi.encodePacked(block.timestamp, block.prevrandao, msg.sender, eggCounter))
) % 100;
if (random < eggFindThreshold) {
...
}
}

This pseudo-random number generator (PRNG) combines publicly accessible and manipulatable parameters:

  • block.timestamp: Attackers and miners can partially control this value or somewhat predict it.

  • block.prevrandao: Publicly accessible before transaction execution within the current block.

  • msg.sender and eggCounter: Known values by attackers.

Because all inputs to this randomness function are publicly known or manipulatable before the transaction executes, attackers can compute exact outcomes and strategically submit transactions to guarantee desired outcomes.


Impact

An attacker exploiting this vulnerability could reliably predict and manipulate the outcome of EggHuntGame::searchForEgg(). This means an attacker could:

  • Consistently win the NFT assets.

  • Gain an unfair advantages over other participants.

  • Can cause NFT drain from the protocol due to predictable asset distribution.


Tools Used

  • Foundry (Forge & Cast): Used for simulation, testing, and fuzzing smart contract transactions.

  • Manual code inspection: To identify predictable randomness and its exploitability.


Recommended Mitigation

Replace the existing insecure randomness implementation with a more secure solution, such as:

  • Chainlink VRF (Verifiable Random Function): Recommended as it provides secure, provably fair, and unpredictable randomness.

  • Commit-reveal schemes: Users commit to random values first, then reveal them later, significantly reducing predictability.

  • Future block-hash dependency: Uses unpredictable hashes from future blocks, preventing attackers from guessing outcomes.

Updates

Lead Judging Commences

m3dython Lead Judge 2 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Insecure Randomness

Insecure methods to generate pseudo-random numbers

Support

FAQs

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