虚假的EOS代币漏洞介绍,Apply函数中没有检查EOS的发行者是否是真正的发行者eosio.token,这使得攻击者能够 发布同名的EOS,然后触发受攻击合约的transfer函数,从而获得真正的EOS。向左向右滑动查看完整代码,该代码没有校验EOS的发布程序。这个例子就是,创建一个假的EOS货币,转移到eosdiceadmin。避免提示:校验真实发行人的身份code==name("eosio.token").value假币漏洞不仅存在于以太坊平台上,还存在于EOS中。而且EOS上的攻击方式更加多样。缺陷引入这个漏洞是因为项目方没有检查交易的status状态,而仅仅是判断交易是否存在。但交易可能被执行,并且交易状态成为hard_fail。来自hard_fail的交易也会显示在链上。因此,以交易是否存在为充值成功的基础是不正确的。
例如,EOS游戏VegasTown(eosvegasgame合同号)遭到攻击,损失了数千个EOS。这次攻击主要有两点,一是hard_fail,二是由于交易延迟,导致hard_fail。hard_fail表示:目标错误和错误处理程序未正确执行。简言之,就是出现错误但没有使用错误处理器(errorhandler)处理错误,例如使用onerror捕获处理,如果没有这样做,则使用hard_fail。
在cleos中只需要设置一个参数就可以延迟交易,这是一个攻击例子。但此交易与合约发出的eosio_assert不同,它没有错误处理。按照官方文档的描述,自然就变成了hard_fail。关键点在于,hard_fail将记录显示在链上,能够 通过项目方的校验。就是没有成本的充值也能成功。
回避建议,不要仅仅判断交易是否存在,而要判断押注交易是否成功实施。回滚漏洞,回滚攻击经常被用来猜测彩票合约的结果,攻击者首先进行投注,然后监控开奖结果,如果没有中奖则进行回滚。相反的是下赌注。进攻者不会损失任何的EOS,从而达到稳定胜利的结果。在EOS上,回滚攻击实际发生了多次。
根据inlineaction的回滚攻击漏洞介绍,该攻击的前提是实时检测并分发中奖奖金,即在被攻击合约转移的过程中计算竞猜结果并立即发放奖金,如果中奖,则恶意合约的EOS余额将增加。因此,在"为竞猜合约转帐"action之后插入余额检测action就可以达到盈利检测的目的。
背景知识:上面提到的Action是EOS上的消息(EOS系统是基于消息通信的)的载体。若要调用某个智能合约,请发送Action消息给它。内联交易:多个不同的action在一个transaction中(在一个交易中触发了随后的多个action),并且,只要出现一个action异常,那么整个transaction就会失败,并且所有的action都会回滚。延迟交易:两个transaction中的两个不同的action,每一个action的状态互不影响。
还没有评论,来说两句吧...