First Flight #10: One Shot

Summary

In "RapBattle.sol", the "goOnStageOrBattle" function randomly picks a Rap Battle"s winner between the challenger and the defender. However, the function is vulnerable to front-running. The defender can manipulate the battle outcome through a combination of mempool observation and front-running to become both the challenger and defender, guaranteeing a win.

Vulnerability Details

1: Random Number Visibility: The _battle function's random number relies on values visible in the mempool (block.timestamp, block.prevrandao, msg.sender).

2: Defender's Observation: The defender (potentially working with a validator/miner) can monitor the mempool for incoming challenges and predict the random number.

3: Front-Running the Challenger: If the calculated random number is unfavorable for the defender, they can:

4: Front-run the original challenger's transaction by paying a higher gas fee.
They can Immediately challenge themselves as a challenger with any valid tokenId (the protocol also lacks validation to check for the ownership of tokenId) and the same _credBet.

5: Guaranteed Win: By effectively replacing the original challenger with itself using another EOA, the defender now controls both sides of the battle and will win regardless of the random number outcome.

Impact

Severe Compromise of Fairness: This exploit completely breaks the fairness of the battle system.
Financial Gain for Attacker: The defender can manipulate the system to guarantee winnings, essentially avoid loosing any funds to any different person.

Tools Used

Manual Review

Recommendations