Lucky Strike v2 security audit report

ETH_LuckyStrikeV2_report.md

Lucky Strike v2 security audit report

Summary

This is the report from a security audit performed on Lucky Strike v2 by gorbunovperm.

Standard ERC20 token functions. Token burn. Whitelisting transfer while ICO is on specific address. Unpausing the transfer function by anyone who have token in their wallet. Setting crowdsale address.

In scope

1. LuckyStrike_v2.sol
2. LuckyStrikeTokens_v2.sol

Findings

In total, 5 issues were reported including:

• 2 high severity issue.

• 1 medium severity issues.

• 2 low severity issues.

• 0 minor observations.

Security issues

1. Known vulnerabilities of ERC-20 token

Severity: low

Description

• It is possible to double withdrawal attack. More details here

• Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here

Recommendation

Add into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

2. Checking incoming addresses for empty values

Severity: low

Code snippet

• owner initialization

Description

As a parameter of init function can be an empty value and the owner will be 0x0-address.

Recommendation

Use condition: require(luckyStrikeContractAddress != address(0)).

3. The owner can change funds allocation in his favor

Severity: medium

Code snippet

• adjustAllocation

Description

The contract has adjustAllocation which allows the owner to change the percentage of profit. Now the owner's profit is 5%, but can be significantly changed.

4. It is possible to manipulate the results of the draw

Severity: high

Code snippet

• random calculation

Description

Formula of the random calculation is:

    ticketsInTheInstantGame = kingOfTheHillTicketsNumber.add(lastInstantGameTicketsNumber[player]);
    randomNumber = uint256(bytes32(keccak256(block.blockhash(lastInstantGameBlockNumber[player])))) % ticketsInTheInstantGame;

The player can affect to lastInstantGameBlockNumber and ticketsInTheInstantGame. The attacker can choose the necessary values of this variables to win with absolute probability.

Recommendation

Use another mechanism of random number calculation.

5. Front-Running attack

Severity: high

Code snippet

• __callback

Description

The calculation of the jackpot winner in this contract is done with the help of oraclize. Calling the requestRandomFromOraclize function gives a random value. A random value is returned as an argument of __callback function. But the transaction stack can be intercepted and a random value can be obtained by the attacker before the block will be mined. The definition of the winner is as follows:

    // _result -- argument of __callback function

    bytes32 hashOfTheRandomString = keccak256(_result);
    uint256 randomNumberSeed = uint256(hashOfTheRandomString);
    uint256 randomNumber = randomNumberSeed % ticketsTotal;

    address winner = theLotteryTicket[randomNumber];

Thus knowing the random number, and changing the Total tickets through the purchase of new tickets and substituting its transaction above the transaction with __callback function the attacker can manipulate the result of jackpot.

Recommendation

Form the list of participants of the jackpot in startJackpotPlay function rather than in __callback function.

Conclusion

There is some vulnerabilities that should be fixed.