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

EOS假充值(hard_fail 状态攻击)细节披露与修复方案

来源:本站整理 作者:佚名 时间:2019-03-15 TAG: 我要投稿


 
by 慢雾安全团队
披露时间线
2019 年 3 月 10 日,我们捕获了 EOS DApp 上的一种新型攻击手法,一个帐号名为 fortherest12 的攻击者通过 hard_fail 状态攻击手法攻击了 EOS 游戏 Vegas town ,并造成了一定数量的损失。
2019 年 3 月 10 日,我们注意到出现了数量更多的 hard_fail 类型攻击。
2019 年 3 月 11 日,我们披露了相关的攻击手法,但是没有披露具体的攻击细节,并及时联系了相关的交易所以及项目方。
2019 年 3 月 12 日,我们发布红色预警,提醒交易所和钱包需要对 EOS 交易执行状态进行校验,必要时可暂停充提系统。
2019 年 3 月 13 日,预警得到 EOS New York 及 Block.one 的 BM 等核心成员响应及认可。
2019 年 3 月 14 日,细节正式公开。
 
漏洞细节
参考官方文档,可以得知 EOS 交易的执行状态存在多种,相应的类别及相应的描述分别为:
executed:交易正确执行,没有触发 error handler
soft_fail:交易客观失败(没有执行),但正确触发 error handler
hard_fail:交易客观失败,但没有触发 error handler
delayed:交易延迟/deferred/在队列中待执行
expired:交易过期
此次的攻击手法就是利用了上述状态中的 hard_fail 状态进行攻击,在以前的开发过程中,许多开发者都不曾碰到过这种交易执行状态,常规的区块浏览器上也无法查询到相关的交易,造成了开发者缺少对这种交易状态的认知。开发中的惯常思维也是只有合约才能发起延时交易。但是,通过 cleos 中的具体参数配置 delay-sec 参数:

即使使用非合约帐号也能正常发起 delay 交易,针对使用中心化开奖的 DApp 项目方或使用中心化管理的交易所及钱包,如果没有对 EOS 交易的执行状态进行校验,就有可能出现 “假充值” 攻击,攻击者不需要付出任何成本,却可以获得大量的 EOS。这是一种全新的攻击手法,而且也是大家十分容易忽略的点,但是导致的危害却是巨大的。对于这种手法,我们已经捕获到真实攻击,并成功阻止了一起损失金额以人民币亿为单位的攻击及多起巨额损失。但遗憾的是,还是存在几起被成功攻击的事件,这个超出了我们的能力,我们的客户或伙伴只是这个生态里的一小部分而已。
基于上述情况,我们于 3 月 12 日发布了我们的红色预警,但由于我们的翻译不够严谨,在 EOS 社区引起了恐慌,让 EOS 社区误以为这是 EOS 的漏洞,我们对此致以歉意。EOS 社区的一些成员认为,只要交易所及钱包做好相关的检查,并不会出现此类问题。但是我们很难要求所有程序员都能写出最佳安全实践的代码,当出现不严谨的校验方式便会导致攻击发生。
经过我们的分析,我们更倾向于 transaction status 属于 EOS 的一种特性(features),历史上曾经出现多例与特性相关的 “假充值” 漏洞。
如我们主导披露的:
USDT 虚假转账安全风险分析
以太坊代币“假充值”漏洞细节披露及修复方案
及我们参与披露的:
XRP 官方披露的假充值漏洞及相关分析
这些问题都不是链自己本身的漏洞,但是由于链自己本身的特性的原因,以及开发者对此类特性校验的不严谨从而导致了攻击的发生。这就是我们为什么会发布红色预警。这不是恐吓(FUD),更像是一种容易被人忽略的攻击手法。此类攻击手法之前在 EOS 上没有相同的攻击案例,但在我们公布相关的攻击手法后,根据我们联合 EOSPark 的数据分析系统发现,已经有十几个帐号开始分别对 DApp、交易所以及钱包作出攻击测试,这些帐号有:
bobukulabobucuancuan2323testsuperdexzhangjiayibajustjiezhan1wnze2qwdiynehavls3k3iygeha11w4zzmpgewkdoptxcjvdnxmqukuailianallosaurusesccholr1ub2kuwalletthomasfuckhakcer.xjohnwickteameosiotokeniopeospeospeoseczpfezhvnrk等等其他帐号
其中不乏攻击成功的帐号。因此,我们继续发出后续预警,提醒相关项目方做好防范措施。除此之外,Twitter 帐号 Whale Alert 也关注到了此类攻击行为。Whale Alert 官方帐号在 3 月 11 日发布推文称帐号 fuckhacker.x 转账 1 万亿 EOS,随后被官方证明为虚假交易。可见此次攻击波及范围之广。应引起足够的重视。
 
修复方案
针对此类型的交易,相关项目方以及交易所及钱包需要对 EOS 转账的执行状态进行校验,确保交易执行状态为 “executed”,除此之外,在区块不可逆的情况下,也要做到以下几点防止其他类型的 “假充值” 攻击的发生
判断 action 是否为 transfer
判断合约账号是否为 eosio.token 或其它 token 的官方合约账号
判断代币名称及精度
判断金额
判断 to 是否是自己平台的充币账号
 
后记 Q&A
Q:节点开启 read only 模式能防范此类攻击吗?A:根据官方文档对 read only 模式的描述

节点开启 read only 模式后可以查询到线上记录并存在的确认的交易。而此类攻击手法是先发出 defer 交易,defer 交易是在链上保存的真实存在的交易,随后这笔交易才会转变成 hard_fail,所以开启 read only 模式并不能防御此类攻击手法。交易的状态是从 delay 转变成 hard_fail,并不是回滚,这是需要注意的地方。
Q:为什么我在其他的区块浏览器上,如 EOSX 等不能查询到 hard_fail 交易?A:现有的查询交易是通过 EOS 的历史插件 history plugin 来查询的,而根据 history plugin 的代码实现

[1] [2]  下一页

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