RSS Feed
更好更安全的互联网
  • blockwell.ai KYC Casper Token “牛皮癣广告” 事件分析

    2018-09-18
    作者:知道创宇404区块链安全研究团队
    时间:2018/09/13

    一、背景

    2018年9月7日早上1点左右,许多以太坊钱包账户都收到了一种名为blockwell.ai KYC Casper Token代币转进/出账消息:

    令人奇怪的是这些账号均表示之前对这个Token的“一无所知”,当这些收到消息用户并没有真正收到提示的那100个代币,而那些提示有100代币转出的用户在之前也并没有拥有过这种代币,这一切都显得“莫名其妙”!更加让一部分人奇怪和担心的是,这些“转进/出账”的操作,都不需要钱包拥有者的的任何密码私钥输入,于是很多不明真相的用户担心自己的钱包是不是被人恶意攻击 ...

    二、事件跟踪

    首先我们从blockwell.ai KYC Casper Token

    交易页面,看到的交易记录都是转出100代币的记录,没有任何转入记录。

    再看看实际转账到账户的交易信息

    可以看到通过调用这个合约,发起了一笔代币转账,在event logs里可以看到实际的交易

    然后具体的交易地址为

    整笔交易花费了244w的gas,价值2.28美元,有针对的从500个用户转账给了500个用户。

    继续跟踪到转账的from地址:

    正如文章开头提到的那样:所有的来源账户本身都是不持有这种代币的,跟踪一下也可以发现,无论是发起交易者还是接受交易者,都没有发生实际代币的变化。

    但是这些交易记录确实被保存在链上,那么这个事件的核心问题就在于:“这些记录是怎么被产生并记录的?”

    三、事件原理

    我们从合约分析入手

    不出所料,这种事件型的合约代码并不会直接给你开放源代码,通过利用我们404自主研发的智能合约OPCODE逆向工具,反编译后得到如下代码:

    源码如下

    从代码中可以很明显的看到一个特殊的函数x_975ef7df,这是唯一一个涉及到数组操作,且会触发Tranfser事件的函数。

    从代码中可以很清晰的看到, 在对地址列表的循环中,只触发了Transfer事件,没有任何其余的操作。

    我们知道遵守以太坊ERC20标准的合约代币才会被承认为ERC20代币,ERC20代币会直接被交易所承认。而 在ERC20标准中规定,transfer函数必须触发Transfer事件,事件会被记录在event log中,是不是说明平台和交易所在获取ERC20代币交易信息,是通过event log事件获取的呢?我们来测试一下。

    四、事件复现

    首先我们需要编写一个简单的ERC20标准的代币合约

    合约代币需要规定好代币的名称等信息,然后我们定义一个mylog函数。

    这里我们通过remix进行部署(由于需要交易所获得提示信息,所以我们需要部署在公链上)

    测试合约地址

    注:这里需要强调的是:转出/入账的地址都是可以自定义的,这也就是为什么所有的来源账户本身都是不持有这种代币的原因。

    然后直接发起交易

    然后我们的imtoken提示了消息,注意收到的消息了包含了我们的代码里 symbol = "RMB";的值rmb

    回看余额可以发现没有实际转账诞生。

    五、事件目的

    通过上面分析及测试,我们发现整个事件最后只说了一件事情就是伪照了大量的虚假交易记录,并没有其他“实质”性的恶意操作,那么这个事件的目的是什么呢?

    我们回顾下整个事件的流程:

    创建一个token ---> 伪造交易记录 ---> 钱包或交易平台获取交易记录 ---> 推送给用户

    如果能找到自定义的消息,那么这是一条完美的消息推广链!这个事件的始作俑者非常聪明的利用了token名这个自定义输入点:blockwell.ai KYC Casper Token,blockwell.ai这个就是本次事件的主要目的,牛皮癣小广告推广这个网站。

    看你有的人会说如果只是用来做广告推广的话,完全可以使用代币的真实转账记录来推广,而不是利用伪造交易记录。这里需要提醒大家的是“广告费”的问题,这个“广告费”也就是合约操作里的gas消耗,伪造交易记录只需要Transfer操作的gas可以大大节省这个“广告费”,本次事件整个过程的话费的“广告费”约2.28美元的gas,就实现了对1000个用户有针对的推送了精准广告。

    六、总结

    结合以往的各种事件,相比于区块链的各种有限应用场景里,在“恶意”攻击或者利用的层面,攻击者们表现出了惊人的“创意”,本次事件利用了”交易所/平台却盲目信任符合ERC20标准的合约“的特点,使用了以太坊平台本身实现的“bug”,利用了最少的“广告费”实现了精准的用户广告推送。

    另外一个值得我们去关注的点就是被用来做消息推送的点是可以自定义的,那么可能导致的风险是非常值得思考的:比如推送钓鱼网站信息,推送其他非法类型的小广告及言论,会导致钱包等平台应用方的用户的其他不可以预期的风险!我们也提醒各大钱包、交易所等平台警惕此类风险,必要时针对这些可自定义点进行相关识别及过滤。


    智能合约审计服务

    针对目前主流的以太坊应用,知道创宇提供专业权威的智能合约审计服务,规避因合约安全问题导致的财产损失,为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队: https://www.scanv.com/lca/index.html
    联系电话:(086) 136 8133 5016(沈经理,工作日:10:00-18:00)

    欢迎扫码咨询:区块链行业安全解决方案

    黑客通过DDoS攻击、CC攻击、系统漏洞、代码漏洞、业务流程漏洞、API-Key漏洞等进行攻击和入侵,给区块链项目的管理运营团队及用户造成巨大的经济损失。知道创宇十余年安全经验,凭借多重防护+云端大数据技术,为区块链应用提供专属安全解决方案。

    欢迎扫码咨询:


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/700/

    作者:Elfinx | Categories:安全研究技术分享 | Tags:
  • 以太坊合约审计 CheckList 之“以太坊智能合约编码安全问题”影响分析报告

    2018-09-12
    作者:LoRexxar'@知道创宇404区块链安全研究团队
    时间:2018年9月6日
    系列文章:

    一、简介

    在知道创宇404区块链安全研究团队整理输出的《知道创宇以太坊合约审计CheckList》中,把“溢出问题”、“重入漏洞”、“权限控制错误”、“重放攻击”等问题统一归类为“以太坊智能合约编码安全问题”。

    “昊天塔(HaoTian)”是知道创宇404区块链安全研究团队独立开发的用于监控、扫描、分析、审计区块链智能合约安全自动化平台。我们利用该平台针对上述提到的《知道创宇以太坊合约审计CheckList》中“以太坊智能合约编码安全”类问题在全网公开的智能合约代码做了扫描分析。详见下文:

    二、漏洞详情

    1、溢出问题

    以太坊Solidity设计之初就被定位为图灵完备性语言。在solidity的设计中,支持int/uint变长的有符号或无符号整型。变量支持的步长以8递增,支持从uint8到uint256,以及int8到int256。需要注意的是,uint和int默认代表的是uint256和int256。uint8的数值范围与C中的uchar相同,即取值范围是0到2^8-1,uint256支持的取值范围是0到2^256-1。而当对应变量值超出这个范围时,就会溢出至符号位,导致变量值发生巨大的变化。

    (1) 算数溢出

    在Solidity智能合约代码中,在余额的检查中如果直接使用了加减乘除没做额外的判断时,就会存在算术溢出隐患

    在上述代码中,由于没有校验_amount一定会小于balances[msg.sender],所以攻击者可以通过传入超大数字导致溢出绕过判断,这样就可以一口气转走巨额代币。

    2018年4月24日,SMT/BEC合约被恶意攻击者转走了50,659,039,041,325,800,000,000,000,000,000,000,000,000,000,000,000,000,000,000个SMT代币。恶意攻击者就是利用了SMT/BEC合约的整数溢出漏洞导致了这样的结果。

    2018年5月19日,以太坊Hexagon合约代币被公开存在整数溢出漏洞

    (2) 铸币烧币溢出问题

    作为一个合约代币的智能合约来说,除了有其他合约的功能以外,还需要有铸币和烧币功能。而更特殊的是,这两个函数一般都为乘法或者指数交易,很容易造成溢出问题。

    上述代码未对代币总额做限制,会导致指数算数上溢。

    2018年6月21日,Seebug Paper公开了一篇关于整数溢出漏洞的分析文章ERC20 智能合约整数溢出系列漏洞披露,里面提到很多关于指数上溢的漏洞样例。

    2、call注入

    Solidity作为一种用于编写以太坊智能合约的图灵完备的语言,除了常见语言特性以外,还提供了调用/继承其他合约的功能。在calldelegatecallcallcode三个函数来实现合约之间相互调用及交互。正是因为这些灵活各种调用,也导致了这些函数被合约开发者“滥用”,甚至“肆无忌惮”提供任意调用“功能”,导致了各种安全漏洞及风险。

    上述代码就是一个典型的存在call注入问题直接导致重入漏洞的demo。

    2016年7月,The DAO被攻击者使用重入漏洞取走了所有代币,损失超过60亿,直接导致了eth的硬分叉,影响深远。

    2017年7月20日,Parity Multisig电子钱包版本1.5+的漏洞被发现,使得攻击者从三个高安全的多重签名合约中窃取到超过15万ETH ,其事件原因是由于未做限制的 delegatecall 函数调用了合约初始化函数导致合约拥有者被修改。

    2018年6月16日,「隐形人真忙」在先知大会上分享了「智能合约消息调用攻防」的议题,其中提到了一种新的攻击场景——call注⼊,主要介绍了利用对call调用处理不当,配合一定的应用场景的一种攻击手段。接着于 2018年6月20日,ATN代币团队发布「ATN抵御黑客攻击的报告」,报告指出黑客利用call注入攻击漏洞修改合约拥有者,然后给自己发行代币,从而造成 ATN 代币增发。

    2018年6月26日,知道创宇区块链安全研究团队在Seebug Paper上公开了《以太坊 Solidity 合约 call 函数簇滥用导致的安全风险》

    3、权限控制错误

    在智能合约中,合约开发者一般都会设置一些用于合约所有者,但如果开发者疏忽写错了函数权限,就有可能导致所有者转移等严重后果。

    上述代码函数就需要设置onlyOwner。

    4、重放攻击

    2018年,DEFCON26上来自 360 独角兽安全团队(UnicornTeam)的 Zhenzuan Bai, Yuwei Zheng 等分享了议题《Your May Have Paid More than You Imagine:Replay Attacks on Ethereum Smart Contracts》

    在攻击中提出了智能合约中比较特殊的委托概念。

    在资产管理体系中,常有委托管理的情况,委托人将资产给受托人管理,委托人支付一定的费用给受托人。这个业务场景在智能合约中也比较普遍。

    这里举例子为transferProxy函数,该函数用于当user1转token给user3,但没有eth来支付gasprice,所以委托user2代理支付,通过调用transferProxy来完成。

    上述代码nonce值可以被预测,而其他变量不变的情况下,可以通过重放攻击来多次转账。

    三、漏洞影响范围

    使用Haotian平台智能合约审计功能可以准确扫描到该类型问题。

    基于Haotian平台智能合约审计功能规则,我们对全网的公开的共42538个合约代码进行了扫描,其中共1852个合约涉及到这类问题。

    1、溢出问题

    截止2018年9月5日,我们发现了391个存在算数溢出问题的合约代码,其中332个仍处于交易状态,其中交易量最高的10个合约情况如下:

    截止2018年9月5日,我们发现了1636个存在超额铸币销币问题的合约代码,其中1364个仍处于交易状态,其中交易量最高的10个合约情况如下:

    2、call注入

    截止2018年9月5日,我们发现了204个存在call注入问题的合约代码,其中140个仍处于交易状态,其中交易量最高的10个合约情况如下:

    3、重放攻击

    截止2018年9月5日,我们发现了18个存在重放攻击隐患问题的合约代码,其中16个仍处于交易状态,其中交易量最高的10个合约情况如下:

    四、修复方式

    1、溢出问题

    1) 算术溢出问题

    在调用加减乘除时,通常的修复方式都是使用openzeppelin-safeMath,但也可以通过对不同变量的判断来限制,但很难对乘法和指数做什么限制。

    2)铸币烧币溢出问题

    铸币函数中,应对totalSupply设置上限,避免因为算术溢出等漏洞导致恶意铸币增发。

    在铸币烧币加上合理的权限限制可以有效减少该问题危害。

    2、call注入

    call函数调用时,应该做严格的权限控制,或直接写死call调用的函数。避免call函数可以被用户控制。

    在可能存在重入漏洞的代码中,经可能使用transfer函数完成转账,或者限制call执行的gas,都可以有效的减少该问题的危害。

    上述代码是一种用互斥锁来避免递归防护方式。

    3、权限控制错误

    合约中不同函数应设置合理的权限

    检查合约中各函数是否正确使用了public、private等关键词进行可见性修饰,检查合约是否正确定义并使用了modifier对关键函数进行访问限制,避免越权导致的问题。

    4、重放攻击

    合约中如果涉及委托管理的需求,应注意验证的不可复用性,避免重放攻击。

    其中主要的两点在于: 1、避免使用transferProxy函数。采用更靠谱的签名方式签名。 2、nonce机制其自增可预测与这种签名方式违背,导致可以被预测。尽量避免nonce自增。

    五、一些思考

    在完善智能合约审计checklist时,我选取了一部分问题将其归为编码安全问题,这类安全问题往往是开发者疏忽导致合约代码出现漏洞,攻击者利用代码中的漏洞来攻击,往往会导致严重的盗币事件。

    在我们使用HaoTian对全网的公开合约进行扫描和监控时,我们发现文章中提到的几个问题涉及到的合约较少。由于智能合约代码公开透明的特性,加上这类问题比较容易检查出,一旦出现就会导致对合约的毁灭性打击,所以大部分合约开发人员都会注意到这类问题。但在不容易被人们发现的未公开合约中,或许还有大批潜在的问题存在。

    这里我们建议所有的开发者重新审视自己的合约代码,检查是否存在编码安全问题,避免不必要的麻烦或严重的安全问题。


    智能合约审计服务

    针对目前主流的以太坊应用,知道创宇提供专业权威的智能合约审计服务,规避因合约安全问题导致的财产损失,为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队: https://www.scanv.com/lca/index.html
    联系电话:(086) 136 8133 5016(沈经理,工作日:10:00-18:00)

    欢迎扫码咨询:区块链行业安全解决方案

    黑客通过DDoS攻击、CC攻击、系统漏洞、代码漏洞、业务流程漏洞、API-Key漏洞等进行攻击和入侵,给区块链项目的管理运营团队及用户造成巨大的经济损失。知道创宇十余年安全经验,凭借多重防护+云端大数据技术,为区块链应用提供专属安全解决方案。

    欢迎扫码咨询:


    Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/696/

    作者:Elfinx | Categories:技术分享 | Tags:
  • 2018上半年暗网研究报告

    2018-09-12
    作者:知道创宇404实验室
    报告下载:《2018上半年暗网研究报告》

    1 基本概念

    1.1 Deep web/Dark web/Darknet

    讲述暗网之前,需要先了解“深网”(Deep web)、“暗网”(Dark web) 和“黑暗网络”(Darknet) 这三个词。虽然媒体可能经常交替使用它们,但实际上它们代表着截然不同而又相关的互联网区段。

    “深网”(Deep web) 是指服务器上可通过标准的网络浏览器和连接方法访问的页面和服务,但主流搜索引擎不会收录这些页面和服务。搜索引擎之所以不会收录深网,通常是因为网站或服务的配置错误、拒绝爬虫爬取信息、需要付费查看、需要注册查看或其他内容访问限制。

    “暗网”(Dark web) 是深网中相对较小的一部分,与被故意隐藏的 Web 服务和页面有关。仅使用标准浏览器无法直接访问这些服务和页面,必须依靠使用覆盖网络 (Overlay Network);而这种网络需要特定访问权限、代理配置、专用软件或特殊网络协议。

    “黑暗网络”(Darknet) 是在网络层访问受限的框架,例如 Tor 或 I2P。私有 VPN 和网状网络 (Mesh Network) 也属于这个类别。通过这些框架的网络流量会被屏蔽。当进行数据传输时,系统只会显示您连接的黑暗网络以及您传输了多少数据,而不一定会显示您访问的网站或所涉及数据的内容。与之相反的是,直接与明网(Clean Net)或与未加密的表网服务和深网服务交互。在这种情况下,您与所请求资源之间的互联网服务提供商 (ISP) 和网络运营商可以看到您传输的流量内容。

    1.2 暗网 (Dark Web) 的组成

    暗网只能通过Tor (The Onion Routing)和I2P(Invisible Internet Project)等网络访问。

    Tor又名洋葱网络,是用于匿名通信的软件,该名称源自原始软件项目名称“The Onion Router”的首字母缩写词,Tor网络由超过七千个中继节点组成,每个中继节点都是由全球志愿者免费提供,经过层层中继节点的中转,从而达到隐藏用户真实地址、避免网络监控及流量分析的目的。

    I2P网络是由I2P路由器以洋葱路由方式组成的表层网络,创建于其上的应用程序可以安全匿名的相互通信。它可以同时使用UDP及TCP协议,支持UPnP映射。其应用包括匿名上网、聊天、网站搭建和文件传输。

    通过知道创宇“暗网雷达”的实时监测数据表明,Tor 网络大约拥有12万个独立域名(onion address),而I2P网络公开地址薄大约只有8千个地址,体量相对 Tor 网络要小得多。

    2 暗网的现状

    2.1 Tor全球中继节点分布

    截至2018年7月31日,我们统计了全球中继节点的分布状况,全球总计有17635个中继节点,其中正在运行的有6386个,它们的平均带宽为5.33MB/s,最大带宽为99MB/s;相比其他区域而言,北美和欧洲的带宽更大;大部分中继节点分布在北美和欧洲,中国香港只有6个。

    因此可以得出结论,相比表网而言,暗网的规模要小的很多,Tor 网络节点带宽不足以支撑超大的网络流量,网络媒体关于暗网与表网的“冰山比喻”有些夸张了。

    2.2 Tor 网络数据统计

    根据Tor官方项目的统计数据显示,2018年上半年Tor暗网地址(onion addresses (version 2 only))数量峰值为121078个。

    图2.2 暗网地址数量Tor网络来自中国用户数量平均每天1159人,高峰期为2018年5月9日,达到3951人,绝大多数暗网中文用户使用 Meet 类型的流量访问Tor暗网。

    图2.2. 暗网中国用户数量统计针对约12万左右的暗网域名,我们深入进行了研究,得出结论:

    • Onion域名每日存活量约1.2万左右,只占总数的10%;
    • Onion v2 类型的域名有121451个,v3类型的域名只有379个;
    • 每日平均暗网新增数量为30个;

    2.3 Tor暗网的主要类别

    通过知道创宇“暗网雷达”的监测,我们将暗网归为12大类,各类占比如上图所示;通过对各类中独立域名的标题进行整合分析,提取网站标题中关键字出现的频率,生成词云:

    • 商业类占18.98%;其中包括交易市场,自营商店,第三方托管平台(网站担保);交易品种大多是信用卡、枪支、毒品、护照、电子产品、伪钞、欧元票据、亚马逊礼品卡、解密服务、杀手服务、比特币洗钱服务等;大多数网站使用比特币进行交易。
    • 个人类占5.90%;包括个人博客,页面,书籍等。
    • 社会类占4.57%;包括论坛,暗网维基等。
    • 其他语言(非英语)占3.82%;
    • 主机托管类占3.05%;主要为暗网服务托管商的宣传站,介绍其机器性能与架构。
    • 成人类占2.87%;
    • 技术类占2.74%;分享技术/出售黑客技术/售卖0day/漏洞利用
    • 核心网站占1.91%;包括暗网搜索引擎,暗网链接目录等
    • 通讯类占1.79%;包括聊天室,邮件服务,暗网邮箱
    • 政治与宗教类占1.34%;包括暗网的新闻媒体机构,全球维基解密,政党丑闻,激进主义言论,传教等。
    • 赌博类占0.46%;网络赌场等。
    • 其他类(艺术,音乐,需登陆的,无内容,被查封的,视频等)占52.57%;

    可以看到”Freedom Hosting II - hacked”这几个词在各大类中都占据很高的比例。原因是匿名者组织(Anonymous)攻击了当时最大的Tor暗网托管服务提供商Freedom Hosting II,因为它向大量共享儿童色情图片的网站提供主机托管服务。直接导致约20%的Tor网站关闭。

    2.4 Tor暗网Web服务分布

    我们统计了排名前20的Web服务器, 绝大多数暗网网站使用Nginx和Apache作为Web服务器,约1%的暗网使用了Cloudflare作为其 DDoS防护措施。

    2.5 Tor暗网开放端口分布

    http 80端口占69.55%;smtp 25端口占比23.24%;https 443端口占2.88%;ssh 22端口占1.68%。

    2.6 Tor暗网语种分布

    通过机器学习分析网站的标题和内容,我们将暗网进行了语种归类,Tor暗网语种总数有80种,英语依旧是暗网中最流行的语言,占比高达82.02%;接着依次是俄语3.77%、丹麦语2.22%、德语1.73%、拉丁语1.26%、西班牙语1.26%、法语1.13%、葡萄牙语1.00%、汉语0.75%、意大利语0.60%。

    3 暗网的威胁

    由于暗网的匿名特性,暗网中充斥着大量欺诈,非法的交易,没有限制的信息泄露,甚至是危害国家安全的犯罪等, 这些风险一直在威胁着社会,企业和国家的安全。2018年上半年,中国互联网就有大量的疑似数据泄露事件的信息在暗网传播,例如:《某视频网站内网权限及千万条用户数据库暗网售卖事件》

    • 2018年3月8日,黑客在暗网论坛发布某视频网站1500万一手用户数据
    • 2018年6月9日,黑客在暗网论坛发布某视频网站 SHLL+内网权限并公布了300条用户数据
    • 2018年6月13日凌晨,某视频网站官方发布公告称网站遭遇黑客攻击,近千万条用户数据外泄,提醒用户修改密码

    另外还有诸如

    • 某省1000万学籍信息在暗网出售
    • 某快递公司10亿条快递物流数据暗网出售

    等一系列的隐私信息泄露的事件在中国互联网引起广泛传播和关注。

    暗网也成为各种威胁情报信息的重要来源之一。

    从我们监测的数据来看,暗网还在呈现缓慢增长的态势,随着暗网用户的增多,黑市及加密数字货币的发展,更多的黑客在利益的的驱动下开展各种活动,把之前通过表网(互联网)传播的非法交易更多的转移至暗网,通过各种技术手段躲避追踪。对监管和调查造成了一定的困难。

    面对日益增长的暗网威胁, 知道创宇404安全研究团队会持续通过技术手段来测绘暗网,提供威胁情报,追踪和对抗来自暗网的威胁,为了更好更安全的互联网。


    Paper本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/686/

    作者:Elfinx | Categories:安全研究技术分享 | Tags:
  • 以太坊智能合约 OPCODE 逆向之调试器篇

    2018-09-05
    作者:Hcamael@知道创宇404区块链安全研究团队
    时间:2018/09/04
    上一篇《以太坊智能合约 OPCODE 逆向之理论基础篇》,对智能合约的OPCODE的基础数据结构进行了研究分析,本篇将继续深入研究OPCODE,编写一个智能合约的调试器。

    Remix调试器

    Remix带有一个非常强大的Debugger,当我的调试器写到一半的时候,才发现了Remix自带调试器的强大之处,本文首先,对Remix的调试器进行介绍。

    能调试的范围:

    1. 在Remix上进行每一个操作(创建合约/调用合约/获取变量值)时,在执行成功后,都能在下方的控制界面点击DEBUG按钮进行调试

    2. Debugger能对任意交易进行调试,只需要在调试窗口输入对应交易地址

    3. 能对公链,测试链,私链上的任意交易进行调试

    点击Environment可以对区块链环境进行设置,选择Injected Web3,环境取决去浏览器安装的插件

    比如我,使用的浏览器是Chrome,安装的插件是MetaMask

    通过MetaMask插件,我能选择环境为公链或者是测试链,或者是私链

    Environment设置为Web3 Provider可以自行添加以太坊区块链的RPC节点,一般是用于设置环境为私链

    4. 在JavaScript的EVM环境中进行调试

    见3中的图,把Environment设置为JavaScript VM则表示使用本地虚拟环境进行调试测试

    在调试的过程中能做什么?

    Remix的调试器只提供了详细的数据查看功能,没法在特定的指令对STACK/MEM/STORAGE进行操作

    在了解清楚Remix的调试器的功能后,感觉我进行了一半的工作好像是在重复造轮子。

    之后仔细思考了我写调试器的初衷,今天的WCTF有一道以太坊智能合约的题目,因为第一次认真的逆向EVM的OPCODE,不熟练,一个下午还差一个函数没有逆向出来,然后比赛结束了,感觉有点遗憾,如果当时能动态调试,可能逆向的速度能更快。

    Remix的调试器只能对已经发生的行为(交易)进行调试,所以并不能满足我打CTF的需求,所以对于我写的调试器,我转换了一下定位:调试没有源码,只有OPCODE的智能合约的逻辑,或者可以称为离线调试。

    调试器的编写

    智能合约调试器的编写,我认为最核心的部分是实现一个OPCODE解释器,或者说是自己实现一个EVM。

    实现OPCODE解释器又分为两部分,1. 设计和实现数据储存器(把STACK/MEM/STORAGE统称为数据储存器),2. 解析OPCODE指令

    数据储存器

    STACK

    根据OPCODE指令的情况,EVM的栈和计算机的栈数据结构是一个样的,先入先出,都有PUSHPOP操作。不过EVM的栈还多了SWAPDUP操作,栈交换和栈复制,如下所示,是我使用Python实现的EVM栈类:

    和计算机的栈比较,我觉得EVM的栈结构更像Python的List结构

    计算机的栈是一个地址储存一个字节的数据,取值可以精确到一个字节,而EVM的栈是分块储存,每次PUSH占用一块,每次POP取出一块,每块最大能储存32字节的数据,也就是2^256-1,所以上述代码中,对每一个存入栈中的数据进行取余计算,保证栈中的数据小于2^256-1

    MEM

    EVM的内存的数据结构几乎和计算机内存的一样,一个地址储存一字节的数据。在EVM中,因为栈的结构,每块储存的数据最大为256bits,所以当OPCODE指令需要的参数长度可以大于256bits时,将会使用到内存

    如下所示,是我使用Python实现的MEM内存类:

    使用python3中的bytearray类型作为MEM的结构,默认初始化256B的内存空间,因为有一个OPCODE是MSIZE:

    Get the size of active memory in bytes.

    所以每次设置内存值时,都要计算active memory的size

    内存相关设置的指令分为三类

    1. MSTORE, 储存0x20字节长度的数据到内存中
    2. MSTORE8, 储存1字节长度的数据到内存中
    3. CALLDATACOPY(或者其他类似指令),储存指定字节长度的数据到内存中

    所以对应的设置了3个不同的储存数据到内存中的函数。获取内存数据的类似。

    STORAGE

    EVM的STORAGE的数据结构和计算机的磁盘储存结构相差就很大了,STORAGE是用来储存全局变量的,全局变量的数据结构我在上一篇文章中分析过,所以在用Python实现中,我把STORAGE定义为了字典,相关代码如下:

    因为EVM中操作STORAGE的相关指令只有SSTORESLOAD,所以使用python的dict类型作为STORAGE的结构最为合适

    解析OPCODE指令

    对于OPCODE指令的解析难度不是很大,指令只占一个字节,所以EVM的指令最多也就256个指令(0x00-0xff),但是有很多都是处于UNUSE,所以以后智能合约增加新指令后,调试器也要进行更新,因此现在写的代码需要具备可扩展性。虽然解析指令的难度不大,但是仍然是个体力活,下面先来看看OPCODE的分类

    OPCODE分类

    在以太坊官方黄皮书中,对OPCODE进行了相应的分类:

    0s: Stop and Arithmetic Operations (从0x00-0x0f的指令类型是STOP指令加上算术指令)

    10s: Comparison & Bitwise Logic Operations (0x10-0x1f的指令是比较指令和比特位逻辑指令)

    20s: SHA3 (目前0x20-0x2f只有一个SHA3指令)

    30s: Environmental Information (0x30-0x3f是获取环境信息的指令)

    40s: Block Information (0x40-0x4f是获取区块信息的指令)

    50s: Stack, Memory, Storage and Flow Operations (0x40-0x4f是获取栈、内存、储存信息的指令和流指令(跳转指令))

    60s & 70s: Push Operations (0x60-0x7f是32个PUSH指令,PUSH1-PUSH32)

    80s: Duplication Operations (0x80-0x8f属于DUP1-DUP16指令)

    90s: Exchange Operations (0x90-0x9f属于SWAP1-SWAP16指令)

    a0s: Logging Operations (0xa0-0xa4属于LOG0-LOG4指令)

    f0s: System operations (0xf0-0xff属于系统操作指令)

    设计可扩展的解释器

    首先,设计一个字节和指令的映射表:

    然后就是设计一个解释器类:

    • MAX变量用来控制计算的结果在256bits的范围内
    • over变量用来标识程序是否执行结束
    • store用来访问runtime变量: STACK, MEM, STORAGE

    在这种设计模式下,当解释响应的OPCODE,可以直接使用

    特殊指令的处理思路

    在OPCODE中有几类特殊的指令:

    1. 获取区块信息的指令,比如:

    NUMBER: Get the block’s number

    该指令是获取当前交易打包进的区块的区块数(区块高度),解决这个指令有几种方案:

    • 设置默认值
    • 设置一个配置文件,在配置文件中设置该指令的返回值
    • 调试者手动利用调试器设置该值
    • 设置RPC地址,从区块链中获取该值

    文章的开头提过了对我编写的调试器的定位问题,也正是因为遇到该类的指令,才去思考调试器的定位。既然已经打包进了区块,说明是有交易地址的,既然有交易地址,那完全可以使用Remix的调试器进行调试。

    所以对我编写的调试器有了离线调试器的定位,采用上述方法中的前三个方法,优先级由高到低分别是,手动设置>配置文件设置>默认设置

    2. 获取环境信息指令,比如:

    ADDRESS: Get address of currently executing account.

    获取当前合约的地址,解决方案如下:

    • 设置默认值
    • 设置一个配置文件,在配置文件中设置该指令的返回值
    • 调试者手动利用调试器设置该值

    获取环境信息的指令,因为调试的是OPCODE,没有源码,不需要部署,所以是没法通过RPC获取到的,只能由调试者手动设置

    3. 日志指令

    LOG0-LOG4: Append log record with no topics.

    把日志信息添加到交易的回执单中

    上述就是获取一个交易的回执单,其中有一个logs列表,就是用来储存日志信息

    既然是在调试OPCODE,那么记录日志的操作就是没有必要的,因为调试的过程中能看到储存器/参数的情况,所以对于这类指令的操作,完全可以直接输出,或者不做任何处理(直接pass)

    4. 系统操作指令

    这类指令主要是外部调用相关的指令,比如可以创建合约的CREATE, 比如能调用其他合约的CALL, 比如销毁自身,并把余额全部转给别人的SELFDESTRUCT

    这类的指令我认为的解决办法只有: 调试者手动利用调试器设置该指令的返回值

    调用这类函数的时候,我们完全能看到详细的参数值,所以完全可以手动的进行创建合约,调用合约等操作

    总结

    在完成一个OPCODE的解释器后,一个调试器就算完成了3/4, 剩下的工作就是实现自己想实现的调试器功能,比如下断点,查看栈内存储存数据等

    下面放一个接近成品的演示gif图:


    智能合约审计服务

    针对目前主流的以太坊应用,知道创宇提供专业权威的智能合约审计服务,规避因合约安全问题导致的财产损失,为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队: https://www.scanv.com/lca/index.html

    联系电话:(086) 136 8133 5016(沈经理,工作日:10:00-18:00)

    欢迎扫码咨询:

    区块链行业安全解决方案

    黑客通过DDoS攻击、CC攻击、系统漏洞、代码漏洞、业务流程漏洞、API-Key漏洞等进行攻击和入侵,给区块链项目的管理运营团队及用户造成巨大的经济损失。知道创宇十余年安全经验,凭借多重防护+云端大数据技术,为区块链应用提供专属安全解决方案。

    欢迎扫码咨询:


    Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/693/

    作者:Elfinx | Categories:安全研究技术分享 | Tags:
  • 智能合约游戏之殇——类 Fomo3D 攻击分析

    2018-08-29

    作者:LoRexxar'@知道创宇404区块链安全研究团队
    时间:2018年8月23日

    2018年8月22日,以太坊上异常火爆的Fomo3D游戏第一轮正式结束,钱包开始为0xa169的用户最终拿走了这笔约10,469 eth的奖金,换算成人民币约2200万。

    看上去只是一个好运的人买到了那张最大奖的“彩票”,可事实却是,攻击者凭借着对智能合约原理的熟悉,进行了一场精致的“攻击”!

    这次攻击的结果,也直接影响了类Fomo3D的所有游戏,而且无法修复,无法避免,那么为什么会这样呢?

    类Fomo3D

    在分析整个事件之前,我们需要对类Fomo3D游戏的规则有一个基本的认识。

    Fomo3D游戏最最核心的规则就是最后一个购买的玩家获得最大的利益

    其中主要规则有这么几条:

    • 游戏开始有24小时倒计时
    • 每位玩家购买,时间就会延长30s
    • 越早购买的玩家,能获得更多的分红
    • 最后一个购买的玩家获得奖池中48%的eth

    其中还有一些细致的规则:

    • 每位玩家购买的是分红权,买的越多,分红权就会越多
    • 每次玩家购买花费的eth会充入奖金池,而之前买过的玩家会获得分红
    • 随着奖池的变化,key的价格会更高

    换而言之,就是越早买的玩家优势越大。

    最终,资金池里的 ETH 48%分配给获胜者, 2%分配给社区基金会,剩余的 50%按照四种团队模式进行分配。

    游戏规则清楚之后,就很容易明白这个游戏吸引人的地方在哪,只要参与的人数够多,有人存在侥幸心理,就会有源源不断的人投入到游戏中。游戏的核心就在于,庄家要保证游戏规则的权威性,而区块链的可信以及不可篡改性,正是完美的匹配了这种模式。

    简单来说,这是一个基于区块链可信原则而诞生的游戏,也同样是一场巨大的社会实验。

    可,问题是怎么发生的呢?让我们一起来回顾一下事件。

    事件回顾

    2018年8月22日,以太坊上异常火爆的Fomo3D游戏第一轮正式结束,钱包开始为0xa169的用户最终拿走了这笔约10,469 eth的奖金。

    看上去好像没什么问题,但事实真的是这样吗

    在Fomo3D的规则基础上,用户a169在购买到最后一次key之后,游戏的剩余时间延长到了3分钟,在接下来的3分钟内,没有任何交易诞生。这3分钟时间,总共有12个区块被打包。但没有任何一个Fomo3D交易被打包成功。

    除此之外,这部分区块数量也极少,而且伴随着数个合约交易失败的例子

    这里涉及到最多的就是合约0x18e1B664C6a2E88b93C1b71F61Cbf76a726B7801,该合约在开奖的那段时间连续的失败交易,花费了巨量的手续费。

    而且最重要的是,该合约就是上面最后拿到Fomo3D大奖的用户所创建的

    在这期间的每个区块中,都有这个合约发起的巨额eth手续费的请求。

    攻击用户通过这种方式,阻塞了其他游戏者购买的交易,最后成功拿到了大奖。

    那么为什么呢?

    事件原理

    在解释事件发生原理之前,我们需要先了解一下关于区块链底层的知识。

    以太坊约14s左右会被挖出一个区块,一个区块中会打包交易,只有被打包的交易才会在链上永不可篡改。

    所以为了奖励挖出区块的矿工,区块链上的每一笔交易都会消耗gas,这部分钱用于奖励矿工,而矿工会优先挑选gas消耗比较大的交易进行打包以便获得更大的利益,目前,一个区块的gas上限一般为8000000。

    而对于每一笔交易来说,交易发起者也可以定义gas limit,如果交易消耗的gas总值超过gas limit,该交易就会失败,而大部分交易,会在交易失败时回滚

    为了让交易不回滚,攻击者还使用了一个特殊的指令assert(),这是一个类似于require的函数,他和require唯一的区别就是,当条件不满足时,assret会耗光所有的gas。原理是因为在EVM底层的执行过程中,assret对应一个未定义过的操作符0xfe,EVM返回invalid opcode error,并报错结束。

    而攻击者这里所做的事情呢,就是在确定自己是最后一个key的持有者时,发起超大gasprice的交易,如图所示:

    当攻击者不断的发起高手续费的交易时,矿工会优先挑选这些高花费的交易打包,这段时间内,其他交易(包括所有以太坊链上发起的交易、Fomo3D的交易)都很难被矿工打包进入。这样一来,攻击者就有很高的概率成为最后一个持有key的赢家

    整个攻击流程如下:

    1. Fomo3D倒计时剩下3分钟左右
    2. 攻击者购买了最后一个key
    3. 攻击者通过提前准备的合约发起大量消耗巨量gas的垃圾交易
    4. 3分钟内不断判断自己是不是最后一个key持有者
    5. 无人购买,成功获得大奖

    在支付了大量以太币作为手续费之后,攻击者赢得了价值2200万人民币的最终大奖。

    总结

    自智能合约游戏中以类Fomo3D诞生之后,这类游戏就不断成为人们眼中的焦点,精巧的规则设计和社会原理再加上区块链特性,组成了这个看上去前景无限的游戏。Fomo3D自诞生以来就不断成为人们眼中的焦点,类Fomo3D游戏不断丛生。

    随之而来的是,有无数黑客也在盯着这块大蛋糕,除了Fomo3D被盗事件以外, Last Winner等类Fomo3D也被黑产盯上...短短时间内,攻击者从中获利无数。

    而我们仔细回顾事件发生的原因,我们却不难发现,类Fomo3D游戏核心所依赖的可信、不可篡改原则和区块链本身的特性矿工利益最优原则冲突,也就是说,只要矿工优先打包高手续费的交易,那么交易的顺序就是可控的!,那么规则本身就是不可信赖的。

    当你还在寻求棋局中的出路时,却发现棋盘已经不存在了。

    当Fomo3D游戏失去了自己的安全、公平之后,对于试图从中投机的你,还会相信自己会是最后的赢家吗?


    智能合约审计服务

    针对目前主流的以太坊应用,知道创宇提供专业权威的智能合约审计服务,规避因合约安全问题导致的财产损失,为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队: https://www.scanv.com/lca/index.html
    联系电话:(086) 136 8133 5016(沈经理,工作日:10:00-18:00)

    欢迎扫码咨询:

    区块链行业安全解决方案

    黑客通过DDoS攻击、CC攻击、系统漏洞、代码漏洞、业务流程漏洞、API-Key漏洞等进行攻击和入侵,给区块链项目的管理运营团队及用户造成巨大的经济损失。知道创宇十余年安全经验,凭借多重防护+云端大数据技术,为区块链应用提供专属安全解决方案。

    欢迎扫码咨询:

    REF

    [1] Fomo3D https://exitscam.me/play

    [2] 获利交易https://etherscan.io/tx/0xe08a519c03cb0aed0e04b33104112d65fa1d3a48cd3aeab65f047b2abce9d508

    [3] 攻击合约https://etherscan.io/address/0x18e1b664c6a2e88b93c1b71f61cbf76a726b7801

    [4] Fomo3D 千万大奖获得者“特殊攻击技巧”最全揭露https://mp.weixin.qq.com/s/MCuGJepXr_f18xrXZsImBQ

    [5] 「首次深度揭秘」Fomo3D,被黑客拿走的2200万https://mp.weixin.qq.com/s/s_RCF_EDlptQpm3d7mzApA


    Paper本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/681/

    作者:Elfinx | Categories:安全研究技术分享 | Tags:
  • 利用 phar 拓展 php 反序列化漏洞攻击面

    2018-08-29
    作者:seaii@知道创宇404实验室
    时间:2018/08/23

    0x01 前言

    通常我们在利用反序列化漏洞的时候,只能将序列化后的字符串传入unserialize(),随着代码安全性越来越高,利用难度也越来越大。但在不久前的Black Hat上,安全研究员Sam Thomas分享了议题It’s a PHP unserialization vulnerability Jim, but not as we know it,利用phar文件会以序列化的形式存储用户自定义的meta-data这一特性,拓展了php反序列化漏洞的攻击面。该方法在文件系统函数(file_exists()、is_dir()等)参数可控的情况下,配合phar://伪协议,可以不依赖unserialize()直接进行反序列化操作。这让一些看起来“人畜无害”的函数变得“暗藏杀机”,下面我们就来了解一下这种攻击手法。

    0x02 原理分析

    2.1 phar文件结构

    在了解攻击手法之前我们要先看一下phar的文件结构,通过查阅手册可知一个phar文件有四部分构成:

    1. a stub

    可以理解为一个标志,格式为xxx<?php xxx; __HALT_COMPILER();?>,前面内容不限,但必须以__HALT_COMPILER();?>来结尾,否则phar扩展将无法识别这个文件为phar文件。

    2. a manifest describing the contents

    phar文件本质上是一种压缩文件,其中每个被压缩文件的权限、属性等信息都放在这部分。这部分还会以序列化的形式存储用户自定义的meta-data,这是上述攻击手法最核心的地方。

    3. the file contents

    被压缩文件的内容。

    4. [optional] a signature for verifying Phar integrity (phar file format only)

    签名,放在文件末尾,格式如下:

    2.2 demo测试

    根据文件结构我们来自己构建一个phar文件,php内置了一个Phar类来处理相关操作。

    注意:要将php.ini中的phar.readonly选项设置为Off,否则无法生成phar文件。

    phar_gen.php

    可以明显的看到meta-data是以序列化的形式存储的:

    有序列化数据必然会有反序列化操作,php一大部分的文件系统函数在通过phar://伪协议解析phar文件时,都会将meta-data进行反序列化,测试后受影响的函数如下:

    来看一下php底层代码是如何处理的:

    php-src/ext/phar/phar.c

    通过一个小demo来证明一下:

    phar_test1.php

    其他函数当然也是可行的:

    phar_test2.php

    当文件系统函数的参数可控时,我们可以在不调用unserialize()的情况下进行反序列化操作,一些之前看起来“人畜无害”的函数也变得“暗藏杀机”,极大的拓展了攻击面。

    2.3 将phar伪造成其他格式的文件

    在前面分析phar的文件结构时可能会注意到,php识别phar文件是通过其文件头的stub,更确切一点来说是__HALT_COMPILER();?>这段代码,对前面的内容或者后缀名是没有要求的。那么我们就可以通过添加任意的文件头+修改后缀名的方式将phar文件伪装成其他格式的文件。

    采用这种方法可以绕过很大一部分上传检测。

    0x03 实际利用

    3.1 利用条件

    任何漏洞或攻击手法不能实际利用,都是纸上谈兵。在利用之前,先来看一下这种攻击的利用条件。

    1. phar文件要能够上传到服务器端。
    2. 要有可用的魔术方法作为“跳板”。
    3. 文件操作函数的参数可控,且:/phar等特殊字符没有被过滤。

    3.2 wordpress

    wordpress是网络上最广泛使用的cms,这个漏洞在2017年2月份就报告给了官方,但至今仍未修补。之前的任意文件删除漏洞也是出现在这部分代码中,同样没有修补。根据利用条件,我们先要构造phar文件。

    首先寻找能够执行任意代码的类方法:

    wp-includes/Requests/Utility/FilteredIterator.php

    这个类继承了ArrayIterator,每当这个类实例化的对象进入foreach被遍历的时候,current()方法就会被调用。下一步要寻找一个内部使用foreach的析构方法,很遗憾wordpress的核心代码中并没有合适的类,只能从插件入手。这里在WooCommerce插件中找到一个能够利用的类:

    wp-content/plugins/woocommerce/includes/log-handlers/class-wc-log-handler-file.php

    到这里pop链就构造完成了,据此构建phar文件:

    将后缀名改为gif后,可以在后台上传,也可以通过xmlrpc接口上传,都需要author及以上的权限。记下上传后的文件名post_ID

    接下来我们要找到一个参数可控的文件系统函数:

    wp-includes/post.php

    该函数可以通过XMLRPC调用"wp.getMediaItem"这个方法来访问到,变量$thumbfile传入了file_exists(),正是我们需要的函数,现在我们需要回溯一下$thumbfile变量,看其是否可控。

    根据$thumbfile = str_replace(basename($file), $imagedata['thumb'], $file),如果basename($file)$file相同的话,那么$thumbfile的值就是$imagedata['thumb']的值。先来看$file是如何获取到的:

    wp-includes/post.php

    如果$file是类似于windows盘符的路径Z:\Z,正则匹配就会失败,$file就不会拼接其他东西,此时就可以保证basename($file)$file相同。

    可以通过发送如下数据包来调用设置$file的值:

    同样可以通过发送如下数据包来设置$imagedata['thumb']的值:

    _wpnonce可在修改页面中获取。

    最后通过XMLRPC调用"wp.getMediaItem"这个方法来调用wp_get_attachment_thumb_file()函数来触发反序列化。xml调用数据包如下:

    0x04 防御

    1. 在文件系统函数的参数可控时,对参数进行严格的过滤。
    2. 严格检查上传文件的内容,而不是只检查文件头。
    3. 在条件允许的情况下禁用可执行系统命令、代码的危险函数。

    0x05 参考链接

    1. https://i.blackhat.com/us-18/Thu-August-9/us-18-Thomas-Its-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-Know-It-wp.pdf
    2. http://php.net/manual/en/intro.phar.php
    3. http://php.net/manual/en/phar.fileformat.ingredients.php
    4. http://php.net/manual/en/phar.fileformat.signature.php
    5. https://www.owasp.org/images/9/9e/Utilizing-Code-Reuse-Or-Return-Oriented-Programming-In-PHP-Application-Exploits.pdf

    Paper本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/680/

    作者:Elfinx | Categories:技术分享漏洞通告 | Tags:
  • MetInfo 任意文件读取漏洞的修复与绕过

    2018-08-29
    Author: Badcode@知道创宇404实验室
    Date: 2018/08/20

    404实验室内部的WAM(Web应用监控程序,文末有关于WAM的介绍)监控到 MetInfo 版本更新,并且自动diff了文件,从diff上来看,应该是修复了一个任意文件读取漏洞,但是没有修复完全,导致还可以被绕过,本文就是记录这个漏洞的修复与绕过的过程。

    漏洞简介

    MetInfo是一套使用PHP和Mysql开发的内容管理系统。 MetInfo 6.0.0~6.1.0版本中的 old_thumb.class.php文件存在任意文件读取漏洞。攻击者可利用漏洞读取网站上的敏感文件。

    漏洞影响

    • MetInfo 6.0.0
    • MetInfo 6.1.0

    漏洞分析

    看到\MetInfo6\app\system\include\module\old_thumb.class.php

    从代码中可以看到,$dir直接由$_GET['dir']传递进来,并将../置空。目标是进入到第一个 if 里面的readfile($dir);,读取文件。看看 if 语句的条件,里面的是将$dir中包含$_M['url']['site']的部分置空,这里可以不用管。外面是一个strstr函数,判断$dirhttp字符串的首次出现位置,也就是说,要进入到这个 if 语句里面,$dir中包含http字符串即可。

    从上面的分析可以构造出 payload,只要$dir里包含http字符串就可以进入到readfile函数从而读取任意函数,然后可以使用..././来进行目录跳转,因为../会被置空,所以最终payload 如下

    对于这个任意文件读取漏洞,官方一直没补好,导致被绕过了几次。以下几种绕过方式均已提交CNVD,由CNVD通报厂商。

    第一次绕过

    根据WAM的监测记录,官方5月份的时候补了这个漏洞,但是没补完全。

    看下diff

    可以看到,之前的只是把../置空,而补丁是把.././都置空了。但是这里还是可以绕过。可以使用.....///来跳转目录,.....///经过str_replace置空,正好剩下../,可以跳转。所以payload是

    第二次绕过

    在提交第一种绕过方式给CNVD之后,MetInfo没多久就更新了,来看下官方的修复方式。

    diff

    这里加了一个判断,$dir要以http开头,变换一下之前的payload就可以继续绕过了。

    第三次绕过

    再次提交之后,官方知悉该绕过方式,又补了一次了。

    看下diff

    看到补丁,又多加了一个判断条件,使用strpos函数查找./首次出现的位置,也就是说不能有./。没了./,在Windows下还可以用..\来跳转目录。所以payload

    遗憾的是,这个只能在Windows环境下面才可以。

    最终

    目前在官网供下载的最新的6.1.0版本中,old_thumb.class.php这个文件已经被删除。

    总结

    一次次的修补,一次次的绕过,感觉开发者应该是没有理解到漏洞利用的原理,一直以类黑名单的形式在修复,而黑名单的形式总是容易被绕过。除了删除文件外,根据实际功能,可以考虑使用白名单方式修复,例如限定所能读取的文件类型为图片类型。

    关于WAM

    WAM 应用监控:通过监控互联网开源 Web 应用的版本更新,自动化 Diff 审计源代码,发送漏洞告警邮件,第一时间发现漏洞及后门植入。

    功能特性

    • 目前已支持150种 Web 应用的版本源码监控
    • 支持监控 Web 应用历史版本源码包下载
    • 监控 Web 应用版本发布页面自动下载更新
    • 自动 Diff 版本,比较文件更新,高亮显示,自动审计可疑漏洞或后门
    • 自动邮件告警可以漏洞/后门审计结果

    好消息来了,黑哥计划在 2018 KCon 大会上直接将 WAM 开源发布。


    Paper本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/676/

    作者:Elfinx | Categories:技术分享漏洞通告 | Tags:
  • 以太坊 “后偷渡时代” 盗币之 “拾荒攻击”

    2018-08-29

    作者:Sissel@知道创宇404区块链安全研究团队
    时间:2018年8月20日
    英文版:https://paper.seebug.org/687/

    0x00 前言

    2018年08月01日,知道创宇404区块链安全研究团队发布《金钱难寐,大盗独行——以太坊 JSON-RPC 接口多种盗币手法大揭秘》,针对 偷渡漏洞 和 后偷渡时代的盗币方式 进行了介绍,披露了 后偷渡时代 的三种盗币方式:离线攻击、重放攻击和爆破攻击。

    在进一步的研究中,我们又发现了针对这些攻击方式的补充:拾荒攻击。攻击者或求助于矿工,或本身拥有一定算力以获得将交易打包进区块的权利。在偷渡漏洞中,攻击者在被攻击节点构造gasPrice为 0 的交易,等待用户解锁账户签名广播。攻击者同时设置一个恶意节点,用于接收这笔交易。攻击者将符合条件的交易打包,就可以实现 0 手续费完成转账。通过这种攻击,攻击者可以获取到余额不足以支付转账手续费或勉强足够支付手续费节点上的所有以太币,并在一定程度上可以防止其他攻击者的竞争,可谓是 薅羊毛 的典范。

    除此之外,在薅够以太币残羹之后,攻击者又盯上了这些以太币已被盗光,但账户中残留的代币。直到现在,针对许多智能合约发行的代币,一些被攻击账户中的token,仍在小额地被攻击者以拾荒攻击盗走。

    本文将从一笔零手续费交易谈起,模拟复现盗币的实际流程,对拾荒攻击成功的关键点进行分析。

    0x01 从一笔零手续费交易谈起

    在区块链系统中,每一笔交易都应该附带一部分gas以及相应的gasPrice作为手续费,当该交易被打包进区块,这笔手续费将用来奖励完成打包的矿工。

    《金钱难寐,大盗独行——以太坊 JSON-RPC 接口多种盗币手法大揭秘》中,我们提到了一个利用以太坊JSON-RPC接口的攻击者账号0x957cD4Ff9b3894FC78b5134A8DC72b032fFbC464。该攻击者在公网中扫描开放的RPC端口,构造高手续费的交易请求,一旦用户解锁账户,便会将用户余额转至攻击者的账户或攻击者创建的合约账户。

    在分析该账户交易信息的时候,我们发现了一笔不符合常识的交易,先从这笔交易开始谈起。

    交易地址:0xb1050b324f02e9a0112e0ec052b57013c16156301fa7c894ebf2f80ac351ac22

    0x00a329c0648769a73afac7f9381e08fb43dbea72向合约MinereumToken(攻击者的合约)的交易,虽然用户余额很少,但这笔交易使用了该账户所有余额作为value与合约交互,这笔交易使用了正常数量的gas,但它的gasPrice被设定为0。

    前文提到,攻击者会使用较高的手续费来保证自己的交易成功,矿工会按照本节点的txpool中各交易的gasPrice倒序排列,优先将高gasPrice交易打包进之后的区块。在这个世界上每时每刻都在发生着无数笔交易,在最近七日,成交一笔交易的最低gasPrice是3Gwei。这笔零手续费交易究竟是如何发生,又是如何打包进区块的呢。

    0x02 思路分析

    在区块链系统中,任何人都可以加入区块链网络,成为其中一个节点,参与记账、挖矿等操作。保证区块链的可信性和去中心化的核心便是共识机制

    共识机制

    在以太坊中,矿工将上一区块的哈希值、txpool中手续费较高的交易、时间戳等数据打包,不断计算nonce来挖矿,最先得出符合条件的nonce值的矿工将拥有记账权,得到手续费和挖矿奖励。矿工将广播得到的区块,其他节点会校验这一区块,若无错误,则认为新的区块产生,区块链高度增加。这就是各节点生成新区块保持共识的过程。

    将0 gasPrice交易完成需要确认两个问题

    • 矿工是否会接受这个交易,并将其打包
    • 其余节点接收到含此交易的区块,是否会达成共识

    下面我们来对0 gasPrice交易相关的操作进行测试。了解零手续费的交易如何产生,如何被txpool接受,打包了零手续费交易的区块能否被认可,确认上述问题的答案。

    0x03 零手续费交易测试

    a. 单节点测试

    首先,我们来确认此交易是否可以进入节点的txpool中,启用一个测试链。默认rpc端口是8545,使用python的web3包发起一笔0 gasPrice转账。

    节点一发起转账的脚本,转帐前要解锁账户

    交互结果

    节点一发起的零手续费交易成功,并且挖矿后成功将该交易打包进区块中。

    b. 多节点共识测试

    现在加入另一个节点

    节点一仍使用刚才的脚本发起零手续费交易,节点一的txpool中成功添加,但节点二因为gasPrice非法拒绝了此交易。

    在geth的配置中发现了与此相关的参数

    将其启动时改为0,但节点二的txpool中仍未出现这笔交易。

    阅读源码知,此参数确实是控制txpool增加的交易的最低gasPrice,但不能小于1。

    令节点一(txpool中含0 gasPrice)开始挖矿,将该交易打包进区块后,发现节点二认可了此区块,达成共识,两节点高度均增长了。

    得到结论:

    • 零手续费交易,通常情况下只有发起者的txpool可以接收,其余节点无法通过同步此交易。如若需要,必须进行修改geth源码等操作。
    • 虽然这笔交易无法进入其他节点的txpool,但对于含此交易的区块,可以达成共识。

    我们将进行简要的源代码分析,支持我们的结论。

    0x04 源码分析

    (以下的代码分析基于https://github.com/ethereum/go-ethereum的当前最新提交:commit 6d1e292eefa70b5cb76cd03ff61fc6c4550d7c36)

    以太坊目前最流行的节点程序(Geth/Parity)都提供了RPC API,用于对接矿池、钱包等其他第三方程序。首先确认一下节点在打包txs时,代码的实现。

    i. 交易池

    代码路径:./go-ethereum/core/tx_pool.go

    生成一个tx实例时,发现有对gasPrice的最低要求,具体在这个函数中会拒绝接收此交易。

    ii. 移除低于阈值的交易

    代码路径:./go-ethereum/core/tx_list.go 并且在处理txs中,会将低于阈值的交易删除,但本地的交易不会删除。