TwentyOne

First Flight #29
Beginner FriendlyGameFiFoundrySolidity
100 EXP
View results
Submission Details
Severity: low
Invalid

The use of Poor method for generating Random number `TwentyOne::call()` to Select a Trashold for the dealer can be manuplated and predicted by miner

Description:

  1. Predictable Inputs

  • block.timestamp: The block timestamp can be influenced to a small degree by miners (within ~15 seconds of variability), allowing them to manipulate the randomness outcome.

  • msg.sender: The address of the caller is deterministic and fully controlled by the user executing the transaction.

  • block.prevrandao: Although this is sourced from the randomness beacon introduced in Ethereum's PoS consensus, it may still be insufficiently random when combined with the other weak factors.

  1. Miner Manipulation

    Miners have control over both block.timestamp and block.prevrandao to some extent. By strategically adjusting these values, they can bias the randomness to favor a particular outcome.

uint256 standThreshold = (uint256(
@> keccak256(
abi.encodePacked(block.timestamp, msg.sender, block.prevrandao)
)
) % 5) + 17;

Impact:

An attacker can manipulate the contract to select a threshold value in their favor based on the cards they hold. By exploiting the predictable random number generation or controllable variables within the contract, the attacker can influence the outcome of the threshold determination process. This allows them to adjust the game logic or decision-making mechanisms in a way that maximizes their chances of winning or minimizes their losses.

Such manipulation undermines the fairness of the game and creates an unfair advantage, potentially enabling consistent exploitation to drain funds, disrupt gameplay, or deceive other participants. It highlights a critical issue in the reliance on weak or manipulable randomness within smart contracts.

Proof of Concept:

Recommended Mitigation:

  1. Use Chainlink VRF:
    Integrate Chainlink's Verifiable Random Function (VRF) to generate cryptographically secure random numbers that are unpredictable and tamper-proof.

uint256 randomIndex = VRFConsumer.getRandomNumber() % 5 + 17;
  1. Avoid On-Chain Only Randomness:
    Avoid relying solely on on-chain inputs like block.timestamp and block.prevrandao.
    Combine with off-chain randomness for stronger entropy.

Updates

Lead Judging Commences

inallhonesty Lead Judge 11 months ago
Submission Judgement Published
Invalidated
Reason: Known issue
Assigned finding tags:

[INVALID] Known - Randomness

Randomness Manipulation: The randomness mechanism relies on block.timestamp, msg.sender, and block.prevrandao, which may be predictable in certain scenarios. Consider using Chainlink VRF or another oracle for more secure randomness.

Support

FAQs

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