The SpookySwap contract’s randomized pricing mechanism in the trickOrTreat
function can be manipulated, enabling users to mint NFT treats for free or at a reduced cost. The pseudo-random number generation method used is vulnerable to user manipulation, which can result in a loss of funds for the contract and compromise the integrity of the random pricing model.
High
This vulnerability has significant financial implications. Malicious users are able to mint NFTs for free or at a reduced cost, leading to:
Potential Financial Losses: The contract owner could lose substantial revenue due to the exploit, as attackers bypass the intended minting price.
Unfair Advantage: Attackers gain an unfair edge over legitimate users, enabling them to secure NFTs at a lower cost and potentially disrupting the NFT's intended scarcity and market value.
The vulnerability stems from the reliance on predictable variables (block.timestamp
, block.prevrandao
, msg.sender
, and nextTokenId
) to generate a pseudo-random outcome in the trickOrTreat
function. By controlling these inputs, users can influence the outcome of the "trick" or "treat" probabilities, allowing them to:
Receive treats at a reduced cost when the random value favors "treat."
Bypass payment requirements entirely by manipulating the random mechanism to bypass payment conditions.
The following code is from the TrickOrTreat
contract:
An attacker can manipulate the block.timestamp
or repeatedly call the function to find favorable random values.
By doing so, the attacker can repeatedly mint NFTs at a reduced or zero cost by forcing the contract to enter the "treat" condition.
This vulnerability allows malicious users to mint NFTs at no cost or at a significantly reduced rate, resulting in potential financial losses for the contract and unfair advantages for users who can manipulate the random outcome.
Foundry: Used to write and test the contract in a controlled test environment.
Mocking Functions: Mocked block values to simulate manipulation and confirm exploitability.
Use Chainlink VRF or Similar Oracle Solutions: Integrate a secure randomness provider such as Chainlink VRF to ensure unbiased, tamper-proof random outcomes.
Minimize Predictable Variables: Avoid using predictable variables like block.timestamp
or block.prevrandao
directly in pseudo-random logic, as these can be manipulated by users.
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.