欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

分析一个有趣的蜜罐合约

来源:本站整理 作者:佚名 时间:2018-07-30 TAG: 我要投稿

前言
前段时间看了有关智能合约里蜜罐合约的一些资料,感觉还是非常有意思的,这些蜜罐合约的利用点大都很巧妙,目的都是为了诱惑你往合约里送钱,而且目标人群也不是什么小白,恰恰是相关的技术人员反而容易着了他们的道。这里我也想起了早前见到的某个合约,现在再看确实也是个蜜罐合约,下面我们来看看它的利用点。
 
开端
说起来这份合约当时也是某位师傅分享给我,因为乍看起来问题很大,当时还在开玩笑要不要拿下它把钱转出来合约的代码很简单,如下
pragma solidity ^0.4.20;
contract GUESS_IT
{
    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 game需要给出正确的response,经过sha3加密后与responseHash进行比较即可成功提取所有的eth,同时我们又发现在StartGame函数中response直接作为参数传送进来了,我们知道链上的交易都是公开透明的,所以合约的创建者执行这一函数时我们是可以看到他传递的值的,所以我们直接去查看到response的值就可以成功play game了,当时这个合约里还存入了一个eth,相当于发送一个eth过去可以拿到两个eth,想想还是挺刺激的,不过也只能是想想,真的发了你就得哭了
这个合约看起来其实看起来跟一个叫新年礼物的蜜罐合约有点像,404的团队的文章里也有提到以太坊蜜罐智能合约分析,不过实际上利用点还是有些区别。
初看完这个合约,你可能会觉得这个作者是不是个小白,一点都不了解以太坊运行的机制就随便在主链上创建了合约,而且还存入了一个以太币,更是把源码都发布上来让你参观,其实这时候你应该有点感觉到不对劲了,这天上难道还真能掉馅饼么,当时一个以太币也不是个小数目了,不过怎么看也找不到问题所在,不管了,先动手试试再说。
 
尝试
第一步我们当然要先确定response的值,前面也提到这个可以在调用startgame函数时查看,我们在etherscan上查看该合约的交易记录

第一步创建了合约,那么下一步应该就是startgame了,我们查看该交易的内容

在这里我们可以直接选择将交易的内容解码,这样就可以看到里面包含的这部分信息,所以respose的值就是A snowflakE了,看到这个是不是有点激动,说实话我当时也有点激动,不过现在还是得冷静,后面一个交易是创建者往里面冲了一个ether,再下面竟然是一个老哥发了一个交易把eth给提出来了,不过我看的时候比较早,那时候还没有这笔交易,其实这是合约主人把币给提出来而已,现在看来应该是别人部署来测试的,再看这笔交易的内容

竟然真的是用的前面的response进行提币的,难道这个合约真的可以利用么?其实这里就是创建者的恶趣味了,我们接着往下看。
 
深入
前面我们已经在交易里看到了response的值,我相信很多人可能已经蠢蠢欲动了,不过为了以防万一我们还是多做点验证工作
我们知道合约里使用storage存储的变量都是可以在链上查到的,所以此处的responseHash是可以读取的,那么我们可以用它来进行验证,按照变量定义的顺序,存储位slot 0存放的是string变量question的长度,slot 1存放的是questionsender地址,slot 2存放的是responseHash,所以我们读取slot 2里的值,然后与前面的response的sha3进行比较

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载