This document is a security audit report performed by RideSolo, where Lottereum Project has been reviewed.
- smart contract github commit hash 8485c34a0364f8aad53ff6e719604d7d7aa32e12.
7 issues were reported including:
-
2 high severity issues.
-
2 medium severity issues.
-
2 low severity issues.
-
2 minor remark.
Two possible scenarios can guarantee or increase the chance of an attacker to win the lottery:
- Malicious miner manipulation of the transactions orderings can allow the attacker to increase his chances of winning.
- using a simple attack contract an attacker can check the value of
amountOfTicketsForEthereumLotteryPurchasedif using the ethereum lottery oramountOfTicketsForTokenLotteryPurchasedwhen using the token lottery. Setting simple condition to guarantee that he wins by checking if the value of the state variables satisfy the condition present inplayLotteryByTokenorplayLotteryByEthereumfunctions.
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L103#L104
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L220#L230
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L232#L241
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L263#L291
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L293#L348
buyTicketForEthereumLottery does not implement any logic to check the msg.value, consequences:
- A user can play without even sending ether to the contract.
- A user can send more ether than the ticket price when calling
buyTicketForEthereumLotterythe extra ether will be lost in the contract.
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L232#L241
Internal call to playLotteryByEthereum and playLotteryByToken is made inside buyTicketForEthereumLottery and buyTicketForTokenLottery, however this two functions are restricted by the onlyAdministrator modifier.
when amountOfTicketsForTokenLotteryPurchased or amountOfTicketsForEthereumLotteryPurchased will reach 1000 the transactions wil fail.
The following description assumes that the devs didn't take into account the high severity issue mentioned in 3.1.
80% of totalFundInTokenLottery is distributed to the lottery winners, however after starting distrubution only 96% of the original 80% is distributed (check the computation bellow).
(1000÷100)×(2÷100+4÷1000+2÷1000)+(1000÷20)×(4÷1000+2÷1000)+(1000÷10)×(2÷1000)+2÷10 = 0.96
Same issue with the 70% of totalFundInEthereumLottery, 96% of the original 70% will be distributed and the other 4% will be lost in the contract.
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L264
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L269#L280
This description assumes that the high severity security issues are solved.
A play and withdrawal pattern should be used instead of playLotteryByEthereum and playLotteryByToken that will consume a highly excessive amount of gas.
The dev should set an opening and closing time where in between players can buy tickets and after closing time players will withdraw their reward by themselves.
participateInEthereumLottery and participateInTokenLotterycontain the exact same code.
one function should handle ether to buy tickets and the other one should handle tokens.
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L197
https://github.com/RideSolo/Lottereum/blob/master/smart%20contract#L209
ticketsForTokenLottery and ticketsForEthereumLottery map players addresses to their ticket number and own address, adding useless extra data.
An opening time is set and checked, but no closing time is set which means that users can play the lottery even after that it closes.
This contract is not safe and cannot be deployed, it contains high severity security issues and high severity operability issues.