First Flight #2: Puppy Raffle

Summary

Malicious actors can watch any selectWinner transaction and front-run it with a transaction that calls refund to avoid participating in the raffle if he/she is not the winner or even to steal the owner fess utilizing the current calculation of the totalAmountCollected variable in the selectWinner function.

Vulnerability Details

The PuppyRaffle smart contract is vulnerable to potential front-running attacks in both the selectWinner and refund functions. Malicious actors can monitor transactions involving the selectWinner function and front-run them by submitting a transaction calling the refund function just before or after the selectWinner transaction. This malicious behavior can be leveraged to exploit the raffle in various ways. Specifically, attackers can:

1. Attempt to Avoid Participation: If the attacker is not the intended winner, they can call the refund function before the legitimate winner is selected. This refunds the attacker's entrance fee, allowing them to avoid participating in the raffle and effectively nullifying their loss.

2. Steal Owner Fees: Exploiting the current calculation of the totalAmountCollected variable in the selectWinner function, attackers can execute a front-running transaction, manipulating the prize pool to favor themselves. This can result in the attacker claiming more funds than intended, potentially stealing the owner's fees (totalFees).

Impact

• Medium: The potential front-running attack might lead to undesirable outcomes, including avoiding participation in the raffle and stealing the owner's fees (totalFees). These actions can result in significant financial losses and unfair manipulation of the contract.

Tools Used

• Manual review of the smart contract code.

Recommendations

To mitigate the potential front-running attacks and enhance the security of the PuppyRaffle contract, consider the following recommendations:

• Implement Transaction ordering dependence (TOD) to prevent front-running attacks. This can be achieved by applying time locks in which participants can only call the refund function after a certain period of time has passed since the selectWinner function was called. This would prevent attackers from front-running the selectWinner function and calling the refund function before the legitimate winner is selected.