区块网站源码

OWASP中国2019年7月——区块链安全TOP10——www.
owasp.
org.
cn1/39关于OWASP中国"开源Web应用安全项目"(OpenWebApplicationSecurityProject,简称"OWASP")是一个开放的社区,致力于帮助各企业组织开发、购买和维护可信任的应用程序.
OWASP中国是OWASP安全组织在中国的分部,是全球近250个区域分部之一.
在OWASP中国,您可以找到以下免费和开源的信息:应用安全工具和参考标准;关于应用安全测试、安全代码开发和安全代码审查方面的完整书籍;演示文稿和视频;关于常见风险的CheatSheets;标准的安全控制和安全库;全国20个区域性分会;尖端技术研究;专业的全球会议;邮件列表.
更多中文信息,请访问:http://www.
owasp.
org.
cn;更多全球信息,请访问:https://www.
owasp.
org.
所有的OWASP工具、文档、论坛和全球各地分会都是开放的,并对所有致力于改进应用程序安全的人士开放.
我们主张将应用程序安全问题看作是人、过程和技术的问题,因为提供应用程序安全最有效的方法是在这些方面提升.
——区块链安全TOP10——www.
owasp.
org.
cn2/39OWASP全球和OWASP中国没有商业压力,使得我们能够提供无偏见、实用、低成本的应用安全信息.
尽管OWASP全球和OWASP中国支持合理使用商业安全技术,但OWASP不隶属于任何技术公司.
和许多开源软件项目一样,OWASP以一种协作、开放的方式制作了许多不同种类的材料.
几乎每一个与OWASP中国相关的人都是一名志愿者,这包括了OWASP中国的主席、副主席、各区域分部负责人、项目负责人和项目成员.
我们期待您的加入!
——区块链安全TOP10——www.
owasp.
org.
cn3/39前言近几年,区块链技术的发展非常迅猛,安全形势也越来越严峻,仅安全事件导致的直接经济损失就高达35亿美元,很多公司甚至因此倒闭,给行业带来了巨额的经济损失和惨痛的教训.
基于此,OWASP中国成立专门研究小组,收集、整理和分析了2011年至2019年间共160个典型区块链安全事件,并在本文档中给出了排列和描述,希望能帮助到广大的区块链从业者和关注区块链安全的人们.
在参考了类似CVSS(CommonVulnerabilityScoringSystem)等安全威胁评估方法之后,本文以每类威胁历史安全事件所导致的直接经济损失总额为依据,通过客观数据评估威胁大小.
直接经济损失总额包含了威胁评估的两个重要因素,一是威胁发生的数量,即,威胁发生的次数;二是威胁发生导致的影响,即,直接经济损失.
所以,直接经济损失足以表示威胁的大小,且数据相对客观,避免了主观数据导致评估结果误差较大问题,同时,该评估方式更具有良好的解释性.
阅读本文档时需注意以下三点:(1)安全事件导致的经济损失以案件发生时的虚拟币价格计算;(2)统计分析过程中只计算了直接经济损失,未计算间接经济损失;(3)24.
3%的安全事件(39个)未公布经济损失,因而未计入损失统计.
致谢感谢以下为本文档编写做成贡献的个人项目组长:付山阳项目组成员:KevinGu、候欣杰、蒋旭宪、宋飞、王颉、张迅迪(排名不分先后,按姓氏拼音排列)——区块链安全TOP10——www.
owasp.
org.
cn4/39目录关于OWASP中国.
1前言3致谢3一、高级可持续威胁.
81.
风险描述82.
危害描述83.
实际案例8案例1-1:8案例1-2:94.
修复方案9二、失控的币值通胀.
101.
风险描述102.
危害描述103.
实际案例10案例2-1:104.
修复方案11三、失效的权限控制.
14——区块链安全TOP10——www.
owasp.
org.
cn5/391.
风险描述142.
危害描述143.
实际案例14案例3-1:144.
修复方案17四、不安全的共识协议.
181.
风险描述182.
危害描述183.
实际案例18案例4-1:184.
修复方案19五、考虑不充分的程序逻辑201.
风险描述202.
危害描述203.
实际案例20案例5-1:204.
修复方案23六、不严谨的业务策略.
24——区块链安全TOP10——www.
owasp.
org.
cn6/391.
风险描述242.
危害描述243.
实际案例24案例6-1:244.
修复方案25七、校验不严格的交易逻辑261.
风险描述262.
危害描述263.
实际案例26案例7-1:26案例7-2:27案例7-3:284.
修复方案29八、脆弱的随机数机制301.
风险描述302.
危害描述303.
实际案例30案例8-1:30——区块链安全TOP10——www.
owasp.
org.
cn7/394.
修复方案32九、存在缺陷的激励机制331.
风险描述332.
危害描述333.
实际案例33案例9-1:334.
修复方案34十、日志记录和监控不足.
351.
风险描述352.
危害描述353.
实际案例354.
修复方案35后序37参考文献.
38——区块链安全TOP10——www.
owasp.
org.
cn8/39一、高级可持续威胁1.
风险描述高级可持续威胁类问题往往出现在区块链领域的中心化团队上,比如:交易所、钱包、矿池等.
由于这些区块链团队在基础设施安全建设和安全运营上的欠缺,导致基础设施存在安全漏洞,从而被攻击者利用,实施数字货币的盗窃或者破坏.
2.
危害描述高级可持续威胁会导致区块链系统被入侵,权限被控制,最终导致资金被盗取,敏感数据被泄露等系列严重问题.
在2008-2018年间,就共有37起高级可持续威胁类安全事件,导致的直接经济损失高达16亿美元,是区块链领域的第一大威胁.
3.
实际案例案例1-1:Mt.
Gox是区块链领域最著名的入侵事件之一.
早在2011年6月,Mt.
Gox交易所就遭到黑客攻击.
据称,该公司的一名审计人员的电脑受到了攻击,黑客利用这台电脑访问比特币交易所的内网,人为的将比特币的名义价值修改为1美分,然后从该交易所的客户账户转移了大约2000枚比特币.
2014年,Mt.
Gox遭受了更严重的黑客攻击,近85万的比特币被盗窃,攻击手法并没有被披露,但据Mt.
Gox内部人员透露,其存在内部组织不一致、程序安全性不佳、网站源代码泄露等严重的问题.
甚至有黑客怀疑他们是监守自盗,事后又渗透进去,可见安全性很差.
这次的事件导致它们近4.
6亿美元的损失,并最终走向破产,CEO也被判刑.
——区块链安全TOP10——www.
owasp.
org.
cn9/39案例1-2:Coincheck是另一起著名的区块链领域入侵事件.
Coincheck将钱存入热钱包,而且不实行多重签名系统,最终导致了黑客有机可乘,该平台全部5.
26亿NEM币(新经币)被非法转移.
根据估算,这批丢失的新经币价值高达5.
23亿美金,这是目前历史上最大规模的数字货币盗窃案.
4.
修复方案不管是交易所、钱包,还是矿池等团队,都需要高度重视产品安全、办公安全和内部风险管理等安全方面的建设.
产品安全可以参考OWASPS-SDLC项目提出的最佳安全实践;而办公安全侧重入侵检测和数据防泄漏,市场上Top5的安全供应商都可以给出较好的方案;另外,内部的风险管理也都要尽快的建立和完善.
——区块链安全TOP10——www.
owasp.
org.
cn10/39二、失控的币值通胀1.
风险描述比特币及其他区块链虚拟货币吸引大家的一个主要原因是其限定了铸币总数,从而避免了法币通胀和持币者长期承受经济损失.
但若铸币总数限制部分的程序设计和实现有漏洞,则可能导致铸币总数失控,甚至超出设定发币总数多倍,致使币值失控通胀.
2.
危害描述自区块链技术诞生以来,币值通胀类威胁导致了10亿多美元的直接经济损失,占整个区块链安全事件经济损失的29.
55%,而其中智能合约层案件最为突出,单BEC的币值通胀事件就损失了近10亿美元,直接导致了其价值归零.
3.
实际案例案例2-1:币值通胀类最典型的案例就是BEC安全事件.
BEC主要由于币值控制部分的代码出现了整数溢出漏洞,导致出现无限铸币的情况.
出现问题的代码如下图所示,红色框中的_fee与_value参数分别代表转账费用和转账金额,这两个参数都可以由攻击者控制.
作者的本意是希望通过这行代码检查账户的余额是否足够支付转账金额和转账费用,如果不够支付则退出函数不进行支付操作.
但当_value的值足够大(比如_value=2^256-1),以至于_value+_fee会产生上溢,_value+_fee的值等于0,这样绕过了代码的检查,仍然会实施支付操作.
而实际转账的Transfer函数不再检查余——区块链安全TOP10——www.
owasp.
org.
cn11/39额是否足够,以至于value=2^256-1时,Transfer(_from,_to,_value)也可以转账成功,攻击者凭空获得大量的数字货币.
4.
修复方案对整数溢出漏洞导致的币值通胀问题,建议使用安全的算术函数做加减乘除处理.
对币值控制的代码应该谨慎安全的处理.
https://ethereumdev.
io/safemath-protect-overflows//***@titleSafeMath*@devMathoperationswithsafetychecksthatthrowonerror*/librarySafeMath{functionmul(uint256a,uint256b)internalconstantreturns(uint256){uint256c=a*b;——区块链安全TOP10——www.
owasp.
org.
cn12/39assert(a==0||c/a==b);returnc;}functiondiv(uint256a,uint256b)internalconstantreturns(uint256){//assert(b>0);//Solidityautomaticallythrowswhendividingby0uint256c=a/b;//assert(a==b*c+a%b);//Thereisnocaseinwhichthisdoesn'tholdreturnc;}functionsub(uint256a,uint256b)internalconstantreturns(uint256){assert(b=a);returnc;}}——区块链安全TOP10——www.
owasp.
org.
cn14/39三、失效的权限控制1.
风险描述由于权限控制在设计或编码过程中的疏忽和缺陷,导致本来应该限制使用范围的重要函数或权限没有控制好范围,从而被攻击者调用这些重要函数或者使用权限实施攻击.
2.
危害描述过去7年时间里,权限控制失效类问题导致的区块链安全事件共有6起,但导致的直接经济损失达2.
02亿美元.
其中,最著名就是以太坊钱包Parity的库权限没有控制好,被越权调用初始化函数,重置了钱包的所有者,导致了1.
68亿美元的直接经济损失.
3.
实际案例案例3-1:导致Parity钱包用户损失1.
68亿美元的就是下面这几行代码,开发者不应该把初始化函数设置为public,让其它合约也可以调用.
攻击者利用了这个漏洞将钱包的所有者修改,以致用户损失巨大.
functioninitContract()public{owner=msg.
sender;}——区块链安全TOP10——www.
owasp.
org.
cn15/39更多详细的介绍可以参考下面的链接:https://www.
parity.
io/the-multi-sig-hack-a-postmortem/另一种情况是编译器漏洞,如果在编写构造函数过程中不注意也会导致越权调用.
在小于0.
4.
22版本的solidify编译器语法要求中,合约构造函数必须和合约名字相等,名字受到大小写影响.
如:contractOwned{functionOwned()public{}而在0.
4.
22版本以后,引入了constructor关键字作为构造函数声明,但不需要functioncontractOwned{constructor()public{}如果没有按照对应的写法,构造函数就会被编译成一个普通函数,可以被任意人调用,会导致owner权限被窃取等更严重的后果.
更多详细的介绍可以参考链接:https://paper.
seebug.
org/741/Call是最常用的调用方式,调用后内置变量msg的值会修改为调用者,但执行环境为被调用者的运行环境,如果合约中有函数以msg.
sender作为关键变量的代码逻辑,比如向msg.
sender转账,那么就会导致越权操作,引发安全问题.
如下代码所——区块链安全TOP10——www.
owasp.
org.
cn16/39示,withdraw()函数设计的初衷为只能有合约拥有者和合约本身可以发起取款的操作;但由于call的问题,只要用户精心拼接字符序列调用call,从而调用withdraw()函数,就可以绕过isAuth()并取款.
functioncallFunc(bytesdata)public{this.
call(data);//this.
call(bytes4(keccak256("withdraw(address)")),target);//利用代码示意}functionwithdraw(addressaddr)public{require(isAuth(msg.
sender));addr.
transfer(this.
balance);}functionisAuth(addresssrc)internalviewreturns(bool){if(src==address(this)){//检查是否合约拥有者或合约本身returntrue;}elseif(src==owner){returntrue;}——区块链安全TOP10——www.
owasp.
org.
cn17/39else{returnfalse;}}4.
修复方案对初始化等重要函数不要设置为pubic权限,以致可以被外部调用.
要注意构造函数编写方式,以免被编译成普通函数,可以被任意调用.
注意call等的调用对msg的改变,以免导致绕过验证环节,被越权执行函数.
参考OWASPProActiveControls项目中有关访问控制的内容.
参考OWASPASVS项目中有关访问控制的内容.
参考OWASP测试指南项目中有关认证测试和授权测试的内容.
——区块链安全TOP10——www.
owasp.
org.
cn18/39四、不安全的共识协议1.
风险描述共识协议由于存在某些设计之初未考虑到的漏洞,导致漏洞可能被攻击者识别和利用,从而损害链上参与者的利益.
2.
危害描述在总共160个安全案例中,有15%(24个)是共识机制漏洞导致的安全事件,远高于本Top10中其它类型的安全事件,可见这类漏洞是攻击者最为关注的.
导致的直接经济损失为3823万美元,与被攻击的区块链规模较小,使用范围较窄有关,往往处于在虚拟或还没发展壮大的时候(比如:Krypton)或者是衰落的时候(比如:ETC).
共识机制本身的健壮性受到了很大的影响,容易被攻击.
在共识类案例中,以51%共识攻击最为常见.
而不同类型的共识协议在面对51%攻击的抵抗力又有所差别,虽然POW和POS两种共识协议在规模较小时都容易被攻击,但是POW类共识协议比POS类更容易被攻击,从攻击的角度来看,租用51%算力的成本往往比控制51%权益的成本更低,更可控.
3.
实际案例案例4-1:Krypton是一个基于以太坊的区块链,2016年8月的时候被51%攻击了,这次的攻击分为两部分,一部分用至少51%的算力回滚交易,以实现同一个币支付两次;另一部分是用DDOS攻击网络中的多个节点.
这次攻击者从Nicehash租用额外的哈——区块链安全TOP10——www.
owasp.
org.
cn19/39希能量,并且至少租用了4个矿池来实施攻击.
我们由此可以看到,矿池的出现让算力实现了中心化,同时这些算力资源还是可以被任意租用的,这也使得攻击门槛大为降低.
因此相比POW类共识协议,一般来说POS类共识协议更为安全.
更多详细的介绍可以参考链接:https://cryptohustle.
com/krypton-recovers-from-a-new-type-of-51-network-attack4.
修复方案51%的攻击会让交易所等参与交易的对手方损失惨重.
针对交易所,建议提升提款前的确认次数,比如:Krypton就将他们的提款时间增加到了1000次确认.
对共识协议来说,小规模的POW类数字货币,以及权益集中度高的POS类数字货币容易更容易受攻击,总体来说POW比POS更容易被攻击,建议根据具体的业务场景,谨慎选择共识协议.
——区块链安全TOP10——www.
owasp.
org.
cn20/39五、考虑不充分的程序逻辑1.
风险描述由于软件设计和编码的错误原因,存在没有考虑到的异常分支,导致程序逻辑可以被攻击者利用,以至于陷入设计者未预期的流程,造成重大损失.
2.
危害描述很多区块链安全研究者都把这类会导致重入的程序逻辑问题列为头号风险,主要还是因为当年的TheDAO事件(损失6000万美元)影响太大.
不过,除了2016年的TheDAO事件外,此后并没有发生其它有比较严重损失的案例,其它的4个案件总共也只损失不到7.
14万美元.
但这类事件一旦发生影响还是较大,就像TheDAO事件一样.
3.
实际案例案例5-1:以TheDAO事件为案例,首先要介绍两个背景知识,ETH智能合约的发送过程和fallback函数.
ETH智能合约发送过程,在智能合约中用代码向某个地址(这个地址可以是人,也可以是智能合约)发送以太币,比较常见的两个方式是:一是调用send函数,比如:msg.
sender.
send(100);二是使用messagecall,msg.
sender.
call.
value(100).
这两个方式不同的是发送的gas数量.
当调用send方法时,只会发送一部分gas,一般是2300gas,一旦gas耗尽就可能抛出异常.
而使用messagecall的时候,则是发送全部的gas,执行完之后剩余的gas会退还给发起——区块链安全TOP10——www.
owasp.
org.
cn21/39调用的合约.
fallback函数,智能合约中可以有唯一的一个未命名函数,称为fallback函数.
该函数不能有实参,不能返回任何值.
如果其他函数都不能匹配给定的函数标识符,则执行fallback函数.
当合约接收到以太币但是不调用任何函数的时候,就会执行fallback函数.
如下两段代码是有重入漏洞的合约Bank和攻击合约Attack,攻击实施的基本流程如下:(1)假设Bank合约中有100wei,攻击者Attack合约中有10wei;(2)Attack合约先调用deposit方法向Bank合约发送10wei;(3)之后Attack合约调用withdraw方法,从而调用Bank的withdrawBalance;(4)Bank的withdrawBalance方法发送给了Attack合约10wei;(5)Attack收到10wei之后,又会触发调用fallback函数;(6)这时,fallback函数又调用了两次Bank的withdrawBalance,从而转走了20wei;(7)之后Bank合约才修改Attack合约的balance,将其置为0.
从这个攻击流程中,我们可以看出,出问题的地方在4-7这几个步骤,开发者原本预期步骤4完成后就会到步骤7,没有预料到中间还有5-6的fallback处理这个流程,以至于攻击者可以构造编写fallback代码,让处理流程走入异常分支,实现递归调用,直到gas耗尽.
——区块链安全TOP10——www.
owasp.
org.
cn22/39——区块链安全TOP10——www.
owasp.
org.
cn23/394.
修复方案注意代码中像fallback一类的隐含分支,避免处理逻辑出现异常.
在编写智能合约进行以太币发送的时候,使用send或者transfer,不要使用messagecall的方式.
更多详细的信息可以参考如下链接:https://blog.
csdn.
net/u011721501/article/details/79450122——区块链安全TOP10——www.
owasp.
org.
cn24/39六、不严谨的业务策略1.
风险描述目前比较突出的一种业务策略类问题是利用高额的以太费用和技术手段让以太坊堵塞,从而获得游戏中的大奖.
但根据场景不一样,会有许多不一样的业务问题,这些也都会对产品的公平性,乃至产品的生存造成重大影响,需要特别注意!
2.
危害描述目前各类区块链游戏是人气比较高的,因为区块链的去中心,更有利的确保了游戏规则公正公平,吸引了不少玩家.
但如果业务策略设计有漏洞,就容易导致公平性丧失,游戏奖励被特定的人利用漏洞来获得.
2018年共发生了2起业务策略漏洞类的安全事件,共导致了359万美元的直接经济损失,都发生在FOMO3D上.
3.
实际案例案例6-1:以FOMO3D为例,其游戏规则如下:(1)规则1:最后一个购买KEY的人获得奖池中的大奖;(2)规则2:每有人购买一个KEY,倒计时时间会增加30秒;(3)规则3:游戏启动后从24小时开始倒计时.
曾经,大部分人都认为这是一个不可能结束的游戏,因为一旦快到倒计时结束的时候就会很多人蜂拥而至去购买KEY.
但是2018年8月22日下午14点48分,这个游戏终止了,一个地址获得了共291万美元的奖励.
那么他是怎么获得的呢是因——区块链安全TOP10——www.
owasp.
org.
cn25/39为运气好,刚好在他购买之后没有其他人购买了,还是其它原因分析认为这位获奖者是一位黑客,他在自己购买KEY后,使用高额的以太费用和技术手段让以太坊堵塞了3分钟,进而使得其他玩家无法打包购买KEY的交易,最终等到了倒计时结束,获得了最后的大奖!
所以当业务策略设计时不考虑到以太坊网络是有可能被人为的拥堵住的话,你就可能付出和这个案例一样的代价.
同时也让这个游戏没落和失败.
更多详细的介绍可以参考如下链接:https://mp.
weixin.
qq.
com/s/s_RCF_EDlptQpm3d7mzApAhttps://www.
bcsec.
org/index/detail/id/2854.
修复方案由于目前的几个主要公链的性能都比较差,使用很少的成本就能让交易网络阻塞,所以在设计业务策略的时候一定要考虑这些因素,攻击可能让交易出现阻塞和回滚,以至于影响游戏公平性.
——区块链安全TOP10——www.
owasp.
org.
cn26/39七、校验不严格的交易逻辑1.
风险描述交易的校验逻辑不够严密,以致攻击者可以构造假的交易行为,但却被校验方验证通过,误认为真的交易行为.
或者提交了真的交易操作,但是通过时间差,黑名单等因素,让交易操作产生回滚来实现,实际上的交易动作并没有完成,而商家仅验证是否有交易行为的话,就可能导致资金上的损失.
2.
危害描述这里问题通常包含两大类假转账类问题和回滚类问题,截止2019年1月共发生了26起,损失金额233.
72万美元,大多数在于校验方的校验逻辑存在问题,从而可以被攻击者绕过校验,以假的充值行为却获得真实的数字货币入账;或者通过时间差,黑名单等因素让之前的交易操作回滚,从而欺骗商户获得商品.
从古典互联网的安全案例来看,这类漏洞很常见,也是容易造成大额经济损失的漏洞,预计在区块链领域也不例外.
3.
实际案例案例7-1:EOSBET案例是假转账攻击案例的典型代表,账号A和账号B都是由攻击者控制的账号,攻击者使用账号A给帐号B转账,正常的转账只有账号A和帐号B能收到转账通知.
然而攻击者在账号B上部署了合约,并将这个转账消息转发给EOSBet合约,这样EOSBet也会收到A给B的转账通知.
关键的问题是,EOSBet合约.
——区块链安全TOP10——www.
owasp.
org.
cn27/39(图示:假转账攻击过程)在收到转账通知后,并没有校验transfer中的to是否为_self,就将其错误判断为一笔正常转账,然后根据平台游戏规则给了账号A发送相应的EOS奖励,但实际上,账号A和账号B都是黑客的账号,黑客正是通过控制两个不同账号互相转账,就这样以"零成本"骗取了平台巨额奖励.
https://www.
chaindd.
com/3135554.
html案例7-2:回滚类攻击是利用交易广播的时间差来实施攻击,达到后提交的交易先被打包的效果.
区块链的底层网络基于P2P网络,正常情况下P2P网络的交易广播涉及到节点发现和路由,速度比较慢,而攻击者可以对它的交易广播路径进行优化,对当前的出块节点实现直连,不再经过节点发现和P2P路由阶段,那么它的网络速度就会快很多,很可能比先提交的但通过正常网络通信的交易更快到达出块节点,实现后发先至,从而提前被打包.
从攻击场景来说,攻击可以先通过正常网络成功发起一个交易,然后再通过优化后的网络发起一个将当前余额清零或者其他可以让上一个交易不成功的攻击交易,当攻击交易比正常交易先被打包后,正常的交易条件不再满足,交易被回滚,攻击者没有任何的支出.
但很多DAPP的处理只会判断交易是否被成功发——区块链安全TOP10——www.
owasp.
org.
cn28/39起,不判断后面是否出现了回滚,这样它们仍会认为交易已成功,而给攻击者发放对应的数字商品.
案例7-3:BetDice是所有案件中损失最大的一个,攻击手法分为两种,一种是利用时间差来实现如上节所述的回滚攻击,另一种是利用黑名单功能,提交不可能被打包的交易.
利用时间差的手法:如上文所述交易广播是通过P2P网络一个节点一个节点广播的,扩散是比较缓慢的,路径并不一定是最优的,存在通过最优路径后发先至的可能,也就是说即使节点A发送交易a比节点B发送交易b要早那么一点点,但是节点B跟当前出块节点直连,那么交易b会比交易a先被广播到出块BP并且被打包.
具体的攻击流程如下所示:(1)攻击者往游戏开奖节点下注,发起下注交易;(2)然后立刻往当前出块节点的seed发送转账清空账号余额的交易,以便于比下注交易更快被打包;(3)此时,开奖节点不知道攻击者的账号已经清空了(因为该节点还不知道有情况账号余额的交易),所以下注交易在开奖节点成功了(而当下注交易广播到出块BP时,因为攻击者账号余额为空,所以下注交易失败,所以攻击者无成本);(4)当游戏方直接根据节点的state获取开奖数据,但经过上面的分析我们知道,这个state其实是需要被回滚的,所以该数据不能为准.
但游戏方还是根据这个数据进行开奖了,而开奖交易发送到BP,因为DAPP的合约里没有对下注单是否存在进行判断,所以打包成功,游戏方转账给攻击者.
——区块链安全TOP10——www.
owasp.
org.
cn29/39利用黑名单的手法:ECAF是EOS的一个仲裁组织,对一些恶意事件发起仲裁,对一些恶意账号会列入黑名单,并下发给各打包节点,恶意账号就不能进行交易,攻击者利用了ECAF的这个特性实施了攻击,具体攻击流程如下所示:(1)attack合约部署攻击合约;(2)用blacklist发起转账请求,推送下注交易;(3)此时游戏节点执行成功并开奖但出块节点BP发现黑名单不予打包;(4)则下注交易回滚,但开奖交易依旧打包成功.
更多详细的介绍,可以参考如下两个链接的文章:https://eos.
live/detail/19215https://eos.
live/detail/192554.
修复方案关键逻辑不仅要校验是否真实的转账消息,还需要校验转账的目标账户是否正确.
不仅要确认支付是否成功提交,还需要等待一定时间,看支付是否回滚,再确认支付是否成功.
——区块链安全TOP10——www.
owasp.
org.
cn30/39八、脆弱的随机数机制1.
风险描述这里指的不仅仅是伪随机函数的问题,而是整个随机数生成机制不够安全,导致可以被攻击者提前获取或猜测到随机数的结果,以实施攻击.
2.
危害描述随机数问题也是近期比较常发的安全事件,特别是随着一些智能合约类游戏的爆发.
随机数作为游戏公平性的保证,一旦有漏洞就会导致游戏机制被破坏,就可以从中获利,所以常常被各种攻击者盯上,以至于2018-2019年就发生了至少15起案件,包括2018年非常火热的LastWinner和Fomo3D项目,部分DAPP还因为安全事件而关闭.
虽然总的损失金额不大,只有194万美金,但跟这些游戏的规模都还不大有关系,黑客在这些游戏早期就开始关注并开始攻击窃夺资金,以至于他们没有机会长大.
另外,攻击数量多也说明弱随机数攻击的门槛不高,以至于很多黑客都可以发起攻击,所以区块链开发者需要特别注意弱随机数带来的安全风险.
3.
实际案例案例8-1:如下是Fomo3D判断是否空投奖励的代码,像lastwinner这类山寨Fomo3D的游戏基本也都是类似的代码:functionairdrop()privateviewreturns(bool){——区块链安全TOP10——www.
owasp.
org.
cn31/39uint256seed=uint256(keccak256(abi.
encodePacked((block.
timestamp).
add(block.
difficulty).
add((uint256(keccak256(abi.
encodePacked(block.
coinbase))))/(now)).
add(block.
gaslimit).
add((uint256(keccak256(abi.
encodePacked(msg.
sender))))/(now)).
add(block.
number))));if((seed-((seed/1000)*1000))因此,只要知道这几个数据,我们就可以预测出是否可以获得空投奖励.
其中msg.
sender是可以由用户或攻击者控制,因此攻击者可以不断尝试构造出满足空投奖励条件的msg.
sender以获得比正常用户高很多的空投奖励.
其中在lastwinner中,攻击者在6天内就获得了170万美金的空投奖励.
更多详细的内容可以参考如下链接:——区块链安全TOP10——www.
owasp.
org.
cn32/39https://www.
reddit.
com/r/ethereum/comments/916xni/how_to_pwn_fomo3d_a_beginners_guide/https://paper.
seebug.
org/672/4.
修复方案首先,一般来说随机数的构成元素不应该可以被用户控制,其次不应该在开奖前让用户可以预测到开奖结果.
——区块链安全TOP10——www.
owasp.
org.
cn33/39九、存在缺陷的激励机制1.
风险描述激励机制是区块链的重要环节,但若开发者设计的激励机制存在可以被利用的漏洞,就可能会给开发者或用户带来损失.
2.
危害描述激励机制跟报酬的多少直接相关,因此会被很多的攻击者盯上,带来不少的安全风险,有漏洞的激励机制将会给团队带来巨大的经济损失.
Eligius矿池遭受的"块代扣攻击"就让他损失了120万美元.
攻击方利用了矿池激励机制的漏洞,参与分红,但是不做贡献,挖到了矿就自己藏起来,给一起挖矿的矿工和矿池都带来了损害,长期来看矿池的吸引力也会受到影响.
3.
实际案例案例9-1:2014年的时候,Eligius矿池遭受"块代扣攻击",损失了120万美元.
块代扣攻击是指,一个恶意的矿工可以运行一个自己开发的挖矿软件,该怎么挖怎么挖,但是碰到真正解的话就扣下不提交给矿池,因为从矿池方看来,他们似乎正在为矿池工作,并继续得到分配的报酬,而实际上,并不是真正的为矿池做有益的贡献.
对矿池和矿工来说,在不同的激励机制下,他们受到的危害也不一样.
如果矿池是按照工作量给钱的,那么这种攻击不会伤害其他矿工,却会从矿池老板那里白领报酬.
如果矿——区块链安全TOP10——www.
owasp.
org.
cn34/39池是按比例分账的,那么块代扣攻击就危害其他矿工的利益,因为他分酬劳而不做贡献.
由于BTC挖矿机制的设置,这种攻击并没有办法让攻击者独吞扣下的挖矿奖励,因为他挖的是矿池指定的块,而这些块的奖励只能指向矿池.
所以这类的攻击还不算多,但我们在设计其它激励机制的时候一定好仔细考虑,以防出现可以被利用的漏洞,造成重大损失.
https://www.
8btc.
com/article/203414.
修复方案从上面的案例来看,我们在设计激励机制时千万不要假设所有的参与者都是诚实的,一定要防范恶意者的攻击,以保护大家的利益.
——区块链安全TOP10——www.
owasp.
org.
cn35/39十、日志记录和监控不足1.
风险描述日志记录和监控的问题对区块链团队和公司来说非常很重要.
如果没有足够的日志记录和监控,被攻击的过程中,你会不知道,不能及时止损.
发生安全事件后,你没有办法调查,也没有办法改进以避免再犯同样的错误.
所以日志记录和监控不足的问题也很严重!
2.
危害描述缺少日志和监控会让黑客攻击变得更肆无忌惮,因为你无法发现攻击行为,无法知道是哪里存在安全漏洞,也就没有办法找到修复的方案,整体的安全风险处于失控的状态.
3.
实际案例比如前文提到的Mt.
Gox(案例1-1)等安全事件,黑客的攻击路径和手法并没有清晰的披露出来,若排除交易所本身不愿意披露这个因素外,更大的可能是交易所本身并没有完善的日志记录和监控,以至于无法复盘整个攻击流程,无法确切的知道黑客攻击行为的细节.
4.
修复方案要确保所有登录、访问控制失败、输入验证失败都能够被记录到日志中去,并保留足够的用户上下文信息,以识别可疑或恶意帐户,并为后期取证预留足够时间;确保日志以——区块链安全TOP10——www.
owasp.
org.
cn36/39一种能被集中日志管理解决方案使用的形式生成;确保高额交易有完整性控制的审计信息,以防止篡改或删除,例如审计信息保存在只能进行记录增加的数据库表中;建立有效的监控和告警机制,使可疑活动在可接受的时间内被发现和应对;建立或采取一个应急响应机制和恢复计划.
——区块链安全TOP10——www.
owasp.
org.
cn37/39后序主编在研究区块链安全的过程中,发现并没有权威的指导性安全文档,所以联合了各区块链安全公司和各一线企业的安全专家,一起给出了区块链安全的Top10,由于作者们时间和水平有限,如有任何错误的地方,或者更好的方案,请立即联系(项目组邮箱:project@owasp.
org.
cn),我们可以不断改进和提升文档的质量.
——区块链安全TOP10——www.
owasp.
org.
cn38/39参考文献【1】https://www.
bcsec.
org/analyse【2】https://www.
bcsec.
org/event【3】https://xz.
aliyun.
com/t/3737【4】https://www.
parity.
io/the-multi-sig-hack-a-postmortem/【5】https://paper.
seebug.
org/741/【6】https://www.
anquanke.
com/post/id/147913【7】https://cryptohustle.
com/krypton-recovers-from-a-new-type-of-51-network-attack【8】https://blog.
csdn.
net/u011721501/article/details/79450122【9】https://www.
reddit.
com/r/ethereum/comments/916xni/how_to_pwn_fomo3d_a_beginners_guide/【10】https://paper.
seebug.
org/672/【11】https://www.
chaindd.
com/3135554.
html【12】https://ethereumdev.
io/safemath-protect-overflows/【13】https://www.
freebuf.
com/vuls/169741.
html【14】https://www.
chaindd.
com/3135554.
html【15】https://eos.
live/detail/19215【16】https://eos.
live/detail/19255【17】https://www.
bcsec.
org/index/detail/id/134【18】https://www.
bcsec.
org/index/detail/id/223【19】https://mp.
weixin.
qq.
com/s/s_RCF_EDlptQpm3d7mzApA——区块链安全TOP10——www.
owasp.
org.
cn39/39【20】https://www.
bcsec.
org/index/detail/id/285【21】https://www.
8btc.
com/article/20341