Eggstravaganza

Summary

The EggHuntGame contract uses a flawed pseudo-random number generator (PRNG) in the searchForEgg function, which relies on block.timestamp, block.prevrandao, msg.sender, and eggCounter to determine if a player finds an egg. This approach introduces vulnerabilities that allow malicious users to manipulate or predict the outcome, undermining the game's fairness and security.

Vulnerability Details

1. Predictable Pseudo-Random Number Generation

The PRNG formula:

is vulnerable to manipulation and front-running due to:

• block.timestamp: Set by miners and can be manipulated within a small window (±15 seconds). Attackers can time transactions to exploit this.

• msg.sender: The attacker can control this by using multiple addresses to precompute and choose the optimal one.

• eggCounter: A predictable state variable that increments only when an egg is found. Attackers can observe its current value and compute the random number in advance.

2. Front-Running Exploit

An attacker can:

1. Precompute the random number for multiple addresses (using known block.prevrandao, block.timestamp, and eggCounter).

2. Select the address that guarantees a result below the eggFindThreshold (e.g., 20%).

3. Submit a transaction with the chosen address to "win" an egg.

This allows attackers to bypass the 20% chance and reliably find eggs, defeating the game's randomness.

3. No Input Validation

The searchForEgg function lacks checks to ensure users are valid participants (e.g., requiring a minimum stake or NFT ownership). This increases the risk of spam attacks and abuse.

Impact

• Loss of Fairness: Attackers can manipulate the outcome, making the game unfair for legitimate users.

• Gas War Exploits: Malicious users may engage in gas bidding wars to control block timestamps or transaction order, further destabilizing the system.

• Financial Loss: The game’s value diminishes if users lose trust in its fairness.

Tools Used

• Solidity Static Analysis

• Manual Code Review

• Security Patterns for Random Number Generation

Recommendations

1. Use a Cryptographically Secure RNG

Replace the PRNG with a Chainlink VRF (Verifiable Random Function) or a similar oracle service. These provide:

• Unpredictability: Randomness is generated off-chain and verified on-chain.

• Tamper-Proof: Attackers cannot precompute or influence the result.

2. Input Validation

Add checks to ensure users meet criteria (e.g., holding an NFT or paying a fee) before participating.

3. Avoid Block Variables for Randomness

Block variables like block.timestamp, block.prevrandao, and msg.sender should never be used alone for critical randomness.

4. State Variable Management

Avoid using mutable state variables (e.g., eggCounter) in the random number calculation. Instead, use a fixed seed or a secure RNG output.

Proof of Concept (PoC)

1. Attack Steps:

   • Observe eggCounter and block.prevrandao (from the previous block).

   • Precompute the random number for multiple addresses.

   • Choose an address where the random result is below eggFindThreshold.

   • Submit a transaction with that address to guarantee an egg.

2. Mitigation Check:
   Replace the PRNG with Chainlink VRF:

   // Example using Chainlink VRF

   function requestRandomness() internal returns (bytes32 requestId) {

   return requestRandomWords(keyHash, s_subscriptionId, requestConfirmations, callbackGasLimit, numWords);

   }

Conclusion

The current PRNG implementation is insecure and exploitable. Adopting a verifiable random number generator like Chainlink VRF is critical to ensure fairness and prevent manipulation.