TronBank 2673万TRX被盗 或因TRX Pro在主网的合约中存在后门

导读:此次TronBank合约被盗事件再次印证了一个简单到令人发指的常识——所谓智能合约的开源并不能等同于“无条件的安全”,而且粗糙的去中心化机制可能存在被利用的中心化黑幕可能。在目前这个混沌无序的市场环境中,作为一个成熟的“韭菜”,请不要再轻易相信任何口头上的去中心化承诺。

北京时间5月3日凌晨4点12分,一笔神奇的合约调用转走了TronBank合约中的2673万TRX(价值427万RMB),合约余额归零。

WeChat46a0349909093ab2440ebb1e07fe4de8.png


仅仅在20多天前,Tronbank团队的第二个游戏BTTBank在发布3小时内即被黑客用假币攻击并盗走数千万BTT(并非1.8亿BTT),事隔不到一个月,第三款游戏TRX Pro于4月29日20点正式上线,几天时间之内,合约余额已经突破2500万TRX。

这是否是TRON生态上的Dapp又一次被黑客盯上并成功洗劫一空?

WeChatf159beb2f762fe82cc85021a5ffb8f11.png而接下来发生的这一切 更让所有人始料未及

偶然触发的Bug?

合约余额归零后,项目方telegram群里面骗局和黑客的质疑声不绝于耳,DappReview和小伙伴们开始着手研究到底发生了什么。"黑客"的地址为THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH,利用DappReview的玩家数据查看工具,可以看到该地址的所有者像是一个正常的Dapp玩家,从今年1月到5月该玩家涉猎过数十个Dapp,其中TronGoo是他玩过最多的游戏,从TronGoo官方排行榜可以看到他就是排名第二的大户玩家。

WeChatb3ccc668fad4e37f138e6bfed8a5255a.png数据来源 https://player.dapp.review/

发生被盗事件约2个小时之后,在一个名为Scam Watch(骗局观察)的Discord频道中,调走这一笔2673万TRX的地址THeRTT**拥有者wojak现身了。

WeChat2142bc966e8f2d2ca5b243652297f014.png根据wojak的说法,他写了个脚本在分析波场虚拟机字节码,批量扫描合约并发起交易看看有没有什么能赚到钱的方法,结果偶然之中命中了Tronbank合约的bug。一开始连他自己都不知道这笔钱是从Tronbank打过来的。

社区里部分人建议wojak把钱还给Tronbank开发者,而wojak认为这不是他的问题,开发者应该自己写测试例子,做审计以及至少跑一些形式化验证(很显然他们啥都没干),他愿意把这笔钱原封不动还给Tronbank的每一个投资者,而不是项目方的开发者。

wojak要求参与了Tronbank的投资者发给他投资的交易hash值以及自己的地址,他将写一个脚本进行验证,并承诺退款给有损失的Tronbank投资人。

刻意埋藏的后门?

随着调查的深入,那一笔触发Bug的交易被放回桌面上被仔细的剖析。我们再来看一下:

WeChat46a0349909093ab2440ebb1e07fe4de8.png      

注意到,该笔交易调用的是合约里withdraw函数,发送的金额为0.011911 TRX,要注意在Tronbank正常的业务逻辑下,调用withdraw函数是不应该发送任何TRX的,金额应该为0。这一点在源代码中就可以验证。

像Tronbank这样资金盘属性的Dapp,往往都会把代码开源让合约和逻辑变得透明可信来吸引投资人,在网站最明显的位置,也标明了通过第三方验证工具tronsmartcontract.space(以下简称TSC)进行合约代码验证后的代码信息。

WeChatd4669840ae6cf35bce918c4494821375.pngWeChat33d85502f79ab594f470fdd44faa77d9.png从TSC点开源代码之后,找到withdraw函数,函数第一行会先调用_withdraw()来取得可以提取的TRX金额,在_withdraw()函数的第一行我们可以看到:

require(msg.value == 0, "wrong trx amount");


这一行代码的意思是要求该笔交易发送的TRX金额必须为零,否则无法继续执行,交易会被REVERT。

也就是说,按照开源代码的逻辑,那一笔触发Bug的交易根本不可能发生。

现实变成了,TRX Pro的合约实际执行逻辑和所谓“开源”的代码逻辑并不一致。

这里补充说明一下,所谓的代码认证过程是这样:

1. 开发者在主网发布合约

2. 开发者在TSC上传代码,选择编译版本,编译为bytecodes,

3. TSC把步骤2中的bytecodes和步骤1中发布合约的bytecodes做匹配,匹配成功,则认证通过,理论上多或者少一个空格都不行

进一步深扒,从tronscan上找到TRX Pro合约的bytecodes,用反编译工具进行处理得到:

WeChat6d3ed3845671ca4cc73baef37b9ba34b.png反编译工具:

https://www.trustlook.com/products/smartcontractguardian

在withdraw函数中,多了一个判断 else if ((0x2E87 == msg.value)),如果满足条件,那么就会把合约的余额全部转给交易发起者!我们把16进制的数字0x2E87转换成10进制,也就是11911,要知道TRX的精度为6位,11911所对应的TRX金额就是0.011911 TRX... 而这一部分判断在TSC的开源代码中是不存在的,看起来就像是是一个被藏起来没有公布的后门。

用更简单的语言梳理一遍:

1. 在主网上部署的合约,通过反编译发现,调用withdraw函数时,如果发送金额等于0.011911 TRX,则会转移全部合约余额;

2. 在TSC上认证过的开源代码中,如果发送金额不为零调用withdraw函数,交易会被撤回。

那么一切就很清晰了,实际发生的与第一点完全吻合,主网的代码运行没有问题,即TronBank在主网部署的合约中存在一个可以直接提走合约余额的后门代码,而有意思的在于第二点,明明不一样的代码逻辑是如何上传后通过了TSC的认证过程?

根据已有的信息,断定“是开发者在合约之中放置后门”这个结论仍然为时过早,目前我们可以得出的客观结论只有两点

1. TRX Pro在主网的合约中存在后门

2. TSC上认证过的代码与实际合约运行逻辑不符


注:以下内容是基于现有事实依据的可能性探讨,不代表最终结论和真相,请在传播时不要断章取义。

至于后门是谁放置的,如何放置的?目前没有任何实锤证据,有的人认为是Tronbank开发者,有的人认为开发者的实力还不足以通过欺骗TSC验证与实际部署所不同的代码。

客观来分析存在的可能性(注意,此处仅讨论可能性,即便该可能性极低,真相目前没有任何实锤证据),有以下几种:

可能性一:Tronbank开发者在实际部署的合约中夹杂私货放置了后门,并成功欺骗了TSC完成了另一份没有后门的代码验证

在探讨这种可能性时,如何欺骗TSC成为了焦点,如果真的TSC的验证存在Bug,那么这意味着之前所有通过TSC认证并标榜开源的Dapp都不再可信和透明,事实上,在Discord群里,TSC的开发者Khanh承认代码已经很久没有维护并存在bug的可能性,也有其他开发者证实自己实际部署的代码和通过认证的代码可以不完全相同。

另一方面,Tronbank开发者在Telegram群中多次声称团队没有在合约中放置任何的后门,有一种自证清白的方式是:官方给出部署时的源代码以及编译方式(包括编译工具以及版本),理论上任何人按照同样方式编译出来的bytecode和线上部署的TRX Pro合约应该一致。但当我们提出该质疑时,官方回复如下:

WeChat0ff34dea5849ff03b2b8ef9fbfc1d2eb.png这个回复的内容如果当真,则该事件将更加戏剧化和复杂化,参考可能性三

可能性二:Tronbank团队和TSC团队合谋,部署了有后门的合约,同时TSC协助用另一个没有后门的合约完成验证。

这是在“欺骗TSC”很难成立的前提下提出的可能性,TSC最终打上验证的标签其实是中心化的行为,完全可以人为操作,但对于TSC作为一个第三方合约验证工具来说,目前尚无竞品,做这样的事情无疑严重损伤自己的品牌,串通合谋是在性价比太低。

可能性三:Tronbank团队没有在合约中放置后门,而是后门在合约部署过程中以某种方式产生。

这种可能性是基于“可能一”中的官方回复的一种暗示,即项目方在合约部署时确实使用的是没有后门的合约,编译工具在部署合约到主网的过程中出现了猫腻,加入了有问题的后门。但项目方目前没有提供任何的可验证信息,使用的编译工具,以及同样代码两次编译不同结果的信息。

不论如何,TronBank开发者实际部署的代码原样我们不得而知,也无法验证真伪,该事件的真相需要等待各方提供更有说服力的证据才能被逐渐还原出来。

至少在此刻,我们还不能下定论,究竟是谁埋下了这个后门。


投资者的钱怎么办?

在以上错综复杂的信息之下,大部分玩家已经放弃了追查真相,而更关注的则是找回损失。

在承诺退款并要求蒙受损失的投资人发送交易信息之后,wojak整整失联了超过12小时,这期间wojak账户里的钱大部分被转移到了币安交易所。有人开始怀疑wojak并没有打算退钱准备捐款跑路,还有人认为这是TronBank项目方监守自盗,wojak就是项目方之一。

5月3日下午2点44分

另一边,在Tronbank的官方群里,管理员贴出的置顶消息是“TRX Pro被黑客THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH攻击,目前开发团队正在紧急处理,将会及时在群里更新消息”

WeChatf01d349c7ce13e29881e08f47f0aec8f.png5月3日晚上9点13分    WeChat3579b2050ee928c58f069b300219b8ce.png

wojak再次现身,说自己花4个多小时写了脚本从链上获取到tronbank的投资数据来跟收集到的损失信息对比,其中有不少人虚报损失,甚至有完全没有参与过投资的用户也来谎报损失,仅有少数人诚实地汇报了数字。wojak也把比对信息贴了出来https://pastebin.com/raw/gMtxCw97。

5月4日下午1点24分

整整一天之后,Tronbank项目方再次发出通知,他们正在联系wojak进行退款,如果wojak在5月4日晚7点时没有任何回复,官方将提供给投资人的补偿方案。

WeChatb83e2c68e1fc8f3281d329a290ecc0ad.png5月4日下午3点 - 4点

针对之前所承诺的24小时内给出事件分析报告,官方将再次延期,声称将联系安全公司,TSC以及波场官方做更多的调查。同时评论到,有很多细节仍需确认,之前从未遇到类似情况,这有可能是一个精彩的故事。

WeChata34bfe9b6c57bc4a19de7803a51d925d.png

WeChate8a1a5536c6d1388c6229d2478587df2.png

5月4日晚上7点

Tronbank项目方如约公布了赔偿方案,令大部分人吃惊的是项目方没有跑路,而是承诺在24小时内收集信息,并在72小时内进行全额赔付。如果赔付照常发放,这可能是Dapp历史上最大的一次项目方赔付。

WeChat2ccb091636924b6df1427c2c6d639254.png而此次赔付通知,可以说是给投资者吃了一颗定心丸,使得大部分用户打消了“后门是由开发者留下”的疑虑。但在真相露出水面之前,DappReview依旧保留质疑的态度,等待项目方公开更多的调查报告。

结语

原本看起来是一起常见的黑客攻击事件,却喜剧般演化成一场罗生门。究竟是开发者留后门,巧被程序员打开,还是如项目方所说有更底层的问题存在?除了当局者本身,无人知晓。

投资者们对于去中心化的信任(TSC提供的代码认证)崩塌,寄托于中心化的信任(起初是wojak的承诺,后来是Tronbank的赔付公告)。虽然严格意义上来讲最终的真相可能并不是“去中心化的锅”,但对于普通用户而言,很难区分其中差异,大部分用户的认知只能停留在“智能合约为什么开源了明明没有问题还被黑了?”

在本次事件中,虽然Tronbank承诺赔付投资人受损的利益,但受伤的无疑是波场的整个Dapp生态,基于TSC认证的开源代码所产生的信任和背书已经毫无价值,在波场官方出来验证工具之前,DappReview建议各位Dapp玩家不要轻信项目方所谓代码开源言论。

此外,截至到发稿,wojak尚未再次露面,也未将资金退还给任何投资人。

*文章为作者独立观点,不代表BSCEC立场

转载此文章须经作者同意,并请附上出处(DappReview)及本页链接。原文链接 https://mp.weixin.qq.com/s/aInEaYdS9X7HP7FbzWl6AQ

白帽汇安全研究院转载2019-05-05 10:22:05 DappReview 2771