区块链安全—一则蜜罐DAPP欺骗手段分析

2019-10-30 本文已影响0人 CPinging

一、前言叙述

最近，我通过一些相关文章的阅读发现了几个有趣的DAPP。而深入研究后我准备将分析过程记录下来，并分享给读者。本文包括两则DAPP，第一个通过代码审计发现了其中存在的一处溢出漏洞；第二个为一则答题类游戏，然而深入分析后发现，这款游戏不仅仅只简单的问答接口，然而对于了解以太坊的人是一个陷阱。所以我对其进行了复现、分析操作，并记录下来引以为戒。

二、合约分析与测试

1 蜜罐合约漏洞

我们首先根据代码来对合约进行分析。

//Question and answer honeypot.

pragma solidity ^0.4.20;

contract QUESTION
{
    function Play(string _response)
    external
    payable
    {
        require(msg.sender == tx.origin);
        if(responseHash == keccak256(_response) && msg.value>1 ether)
        {
            msg.sender.transfer(this.balance);
        }
    }
    
    string public question;
 
    address questionSender;
  
    bytes32 responseHash;
 
    function StartGame(string _question,string _response)
    public
    payable
    {
        if(responseHash==0x0)
        {
            responseHash = keccak256(_response);
            question = _question;
            questionSender = msg.sender;
        }
    }
    
    function StopGame()
    public
    payable
    {
       require(msg.sender==questionSender);
       msg.sender.transfer(this.balance);
    }
    
    function NewQuestion(string _question, bytes32 _responseHash)
    public
    payable
    {
        require(msg.sender==questionSender);
        question = _question;
        responseHash = _responseHash;
    }
    
    function() public payable{}
}

根据代码内容，我们对游戏分析：

合约只拥有四个函数。首先是play函数。此函数需要msg.sender == tx.origin。这句话的意思就是说我函数的调用方不能是由合约进行中间调用的，而是需要我直接调用。关于msg.sender与tx.origin的区别，我在前面的文章中讲述过，这里就不再继续详细讲述了。

之后，合约对传入的答案进行判断，并且需要要求传入的value大于1 ether。responseHash == keccak256(_response) && msg.value>1 ether。如果传入的内容判定成功，也就是说回答问题正确。那么我们就可以提取出合约中的所有余额。而这函数也是人人可以参与的。

之后我们看StartGame函数。此函数为游戏开始函数，仅能够调用一次。如何进行调用呢？我们来看看代码。首先代码先对传入的参数进行判断：if(responseHash==0x0)。这里的含义是什么呢？由于默认情况下，该参数如果不进行赋值操作那么它就等于0x0 。然而倘若问题与答案进行过更新后，那么responseHash==0x0就变得很低了，几乎没有可能。所以只有第一次调用的时候能够满足这个条件。

进入函数后，合约对三个变量进行赋值。包括问题、答案以及问题发出者。

之后是游戏终止函数：StopGame ()。

在此函数中，合约判断需要问题调用者为问题提出者。当满足条件时，该合约中的余额将被转到提出问题的人账户中。

最后是更新问题NewQuestion()。

此函数也需要满足调用者为问题发起者，满足条件后将更新问题与答案。这些函数分析起来并不复杂。我们总结下过程。

游戏规则如下：

合约创建者会设置一个问题;
任何玩家都可以通过向合约打入不低于 1ETH 的手续费参与作答;
若猜中答案，将得到合约里所有的 ETH 作为奖励;
若猜不中，无任何奖励，且事先支付的 ETH 会转入该合约

然而同学们有没有发现，由于以太坊的特性，所以如果合约创建者调用了play函数那么由于传入的参数是string，所以在以太坊中可以完美的寻找到其痕迹。但是聪明的蜜罐合约创建者才不会就让用户轻松的取走余额。下面我们来对相关蜜罐进行复现测试。

这里我是以蜜罐合约部署者的身份进行测试

首先将合约版本调整为4.20，并部署合约。

之后，我们在rop上部署合约。

image.png

得到合约地址0xb4769ece1229d32cb6e94ec69b8018e42b043640。

image.png

然而，我们并不需要直接进行使用创建者账户直接进行调用play来创建合约问题。我们通过中间合约来进行跳板进行调用。

中间合约如下：

contract middle{
    address addr = 0xb4769ece1229d32cb6e94ec69b8018e42b043640;
    
    QUESTION target =  QUESTION(addr);
    
    function process() public{
        target.StartGame("Who am i?","Pinging");
        target.NewQuestion("Who am i?","balbalbalbabal");
    }
}