Description: Hashing msg.sender
,block.timestamp
, and block.prevrandao
together creates a predictable final number which in not a god random number.Malicious users can manipulate these values to get the treat for half of its price.
Impact: Since the randomness can be manipulated, attackers might exploit the system to secure favorable outcomes (e.g., paying half price more often or avoiding the double-price scenario). This reduces revenue for the contract owner and can skew the intended distribution of outcomes, giving some users unfair advantages over others.
Proof of Concept:
There are a few attack vectors here:
A miner could manipulate the timestamp to increase the probability of generating a specific random number (like 1 or 2), potentially allowing them to guarantee either a half-price or double-price outcome.
Although it is harder to control than block.timestamp, a miner with significant resources could attempt to adjust prevrandao by mining blocks to increase their chance of hitting the desired range in specific scenarios.
3.An attacker could create multiple addresses and repeatedly call the trickOrTreat function, hoping to hit the favorable random outcome (e.g., half-price or double-price) by brute-forcing the desired random value.
Tools Used: Slither and Aderyn.
Recommended Mitigation: Consider using an oracle for your randomness such as Chainlink VRF.
It's written in the README: "We're aware of the pseudorandom nature of the current implementation. This will be replaced with Chainlink VRF in later builds." This is a known issue.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.