(Pseudo) Random Number Generator can be gamed, allowing a user to target desirable NFT traits

[code423n4]

Lines of code

https://github.com/code-423n4/2023-03-canto-identity/blob/077372297fc419ea7688ab62cc3fd4e8f4e24e66/canto-namespace-protocol/src/Tray.sol#L163

Vulnerability details

Impact

Detailed description of the impact of this finding. The iteratePRNG() function in the Utils.sol library is used in Tray.sol:_drawing(), which is used to determine the tile data that a user gets when they purchase an NFT in Tray.sol:buy(). An attacker can exploit this to guarantee that they receive a rare/desirable mint.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

iteratePrng does not actually generate randomness, instead using the previous number to compute each new pseudo-random number. This allows an attacker to precompute any data that relies on this function.

Because the 'randomness' for the tile data in Tray.sol:buy() relies on iteratePRNG() (indirectly via _drawing()), An attacker can either 1) precompute the tile data and wait for a desirable lastHash before they buy, or 2) call buy() -> check the tile data -> revert if it's not desirable/rare. Both options guarantee that they receive an NFT with data/traits that they want.

This scenario is similar to the Wolf Game Exploit.

Tools Used

Manual review

Recommended Mitigation Steps

1. Employ a source of secure randomness, such as chainlink VRF (or PREVRANDAO - not sure if there is something like this on Canto)
2. Commit-reveal (or other two-step solution), where the initial seed isn't made public until all users have minted

[c4-judge]

0xleastwood marked the issue as duplicate of #121

[c4-judge]

0xleastwood marked the issue as satisfactory

[c4-judge]

0xleastwood marked the issue as duplicate of #121

[c4-judge]

0xleastwood marked the issue as duplicate of #130

[c4-judge]

0xleastwood marked the issue as partial-50