Users need to completely trust the owner since he will have complete control over who wins the lottery.
This will disincentivize users from participating in the lotteries because their money might get stolen.
This will certainly disincentivize users from buying tickets for the lotteries that will happen in the far future.
In the Wenwin website is mentioned:
The Wenwin Lottery is a fun, fully decentralized Web3 lottery with no third-party getting in the way of you winning.
This problem is certainly not aligned with this statement.
Proof of Concept
This attack is mainly possible because the owner has partial control over the oracle and also has complete control in changing the oracle after a certain number of fail attempts to call it.
Imagine this scenario:
Owner launches a lottery
Owner pays the oracle to answer the lottery contract requests
Lottery grows in popularity and people start buying tickets for future lotteries
Owner stops paying the oracle
Oracle stops answering the calls from the contract
Owner calls the executeDraw more than maxFailedAttempts times
Owner changes the oracle to a malicious one
Owner calls executeDraw as many times as he wants so the malicious oracle will answer the lottery contract requests
Owner wins all the future lotteries
Owner steals all the money from the lottery contract
Tools Used
Manual Review
Recommended Mitigation Steps
Two ways to mitigate this problem can be as follows.
If swapSource is called, all the nonFinalized lotteries will be automatically refunded to the users. Basically each lottery is linked to the oracle that was set for the contract, if that oracle is gone, the lottery is gone.
If swapSource is called, no one should be able to call executeDraw for a certain amount of time. And there should be a refund functionality for users. This will give users enough time to get a refund if they don't want to trust the new oracle.
Lines of code
https://github.com/code-423n4/2023-03-wenwin/blob/main/src/RNSourceController.sol#L89-L104
Vulnerability details
Impact
In the Wenwin website is mentioned:
Proof of Concept
This attack is mainly possible because the owner has partial control over the oracle and also has complete control in changing the oracle after a certain number of fail attempts to call it. Imagine this scenario:
maxFailedAttempts
timesTools Used
Manual Review
Recommended Mitigation Steps
Two ways to mitigate this problem can be as follows.
swapSource
is called, all the nonFinalized lotteries will be automatically refunded to the users. Basically each lottery is linked to the oracle that was set for the contract, if that oracle is gone, the lottery is gone.swapSource
is called, no one should be able to callexecuteDraw
for a certain amount of time. And there should be a refund functionality for users. This will give users enough time to get a refund if they don't want to trust the new oracle.