被盗 1.7 亿 BTT 今又被盗 2600 万 TRX,TronBank 在刻意埋藏后门?_OJA:ITH

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

原文标题:《2600万TRX被盗背后的罗生门》作者:DR小伙伴

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

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

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

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

偶然触发的Bug?

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

Azuki #3426被盗并在X2Y2平台以14.35 ETH出售:2月13日消息,Web3网络安全公司Ancilia监测数据显示,Azuki #3426被盗并在X2Y2平台上以14.35 ETH(超过2.17万美元)的价格被出售。[2023/2/13 12:03:43]

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

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

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

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

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

刻意埋藏的后门?

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

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

尼日利亚公司 Looty 希望以数字形式归还被盗的非洲艺术品:金色财经报道,尼日利亚一家以艺术为导向的公司 Looty 想出了一种方法,让非洲人可以看到非洲大陆在殖民时代失去的所有艺术。尼日利亚创意设计师兼 Looty 创始人 Chidi 表示,该公司首先在全球博物馆中追踪非洲艺术品,然后使用特殊的应用程序和技术将艺术品扫描并转换为 3D 格式。Looty 网站于 5 月 13 日上线。然而,该项目于去年 11 月正式开始运营。Chidi 与两名尼日利亚人和一名索马里人一起研究潜在的艺术作品并将其转换为数字形式。每个团队成员都擅长 3D 设计、NFT 技术或编辑。(cryptoslate)[2022/5/10 3:02:21]

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

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

require(msg.value==0,"wrongtrxamount");

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

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

现实变成了,TRXPro的合约实际执行逻辑和所谓「开源」的代码逻辑并不一致。

派盾:BitMart热钱包疑似被盗,金额或超1亿美金:12月5日消息,据派盾推特,BitMart热钱包疑似被盗。据推特napgener,被盗金额超过9位数(1亿美金)。黑客通过1inch将被盗代币转换为ETH,并发送至TornadoCash混币。[2021/12/5 12:52:01]

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

1、开发者在主网发布合约;2、开发者在TSC上传代码,选择编译版本,编译为bytecodes;3、TSC把步骤2中的bytecodes和步骤1中发布合约的bytecodes做匹配,匹配成功,则认证通过,理论上多或者少一个空格都不行;

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

反编译工具:

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

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

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

1、在主网上部署的合约,通过反编译发现,调用withdraw函数时,如果发送金额等于0.011911TRX,则会转移全部合约余额;2、在TSC上认证过的开源代码中,如果发送金额不为零调用withdraw函数,交易会被撤回。

动态 | 赵长鹏发推感谢孙宇晨表示被盗损失将由币安SAFU基金承担:针对币安被盗事件,孙宇晨早间表示个人愿意向币安存入7000个BTC等值的美元支持。对此,赵长鹏发推表示感谢,并表示没有必要,称币安SAFU基金将承担此次损失,币安虽然受到了攻击,但是并没有破产,会尽快解决问题以便每个人都可以再次存款和取款。[2019/5/8]

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

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

1、TRXPro在主网的合约中存在后门

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

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

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

客观来分析存在的可能性,有以下几种:

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

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

Bithumb被盗过程还原:黑客利用百倍交易费不计成本加速转账,疑似已累计转移1900BTC:Chaindigg通过对Bithumb比特币流向分析发现,从19日23点07分,黑客利用其已经掌握的Bithumb热钱包地址私钥,将Bithumb热钱包中的比特币不断转移至自己不同的钱包地址。为了加快交易速度,使交易尽快得到确认,黑客将每一笔转账交易的交易Fee都设置为0.1BTC,较正常交易Fee高出百倍。半小时后,Bithumb察觉了其热钱包动向的异常行为。自此,Bithumb与黑客的数字资产转移竞赛拉开序幕。但由于黑客不计成本,矿工在对同一个地址中的比特币进行交易时,会优先确认交易Fee高的交易,因此,黑客占得绝对先机。截止20日15点45分,疑似黑客已经累计从Bithumb转移1900BTC。[2018/6/20]

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

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

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

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

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

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

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

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

投资者的钱怎么办?

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

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

5月3日下午2点44分

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

5月3日晚上9点13分

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

5月4日下午1点24分

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

5月4日下午3点-4点

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

5月4日晚上7点

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

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

结语

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

投资者们对于去中心化的信任崩塌,寄托于中心化的信任。虽然严格意义上来讲最终的真相可能并不是「去中心化的锅」,但对于普通用户而言,很难区分其中差异,大部分用户的认知只能停留在「智能合约为什么开源了明明没有问题还被黑了?」

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

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

来源链接:mp.weixin.qq.com

本文来源于非小号媒体平台:

DappReview

现已在非小号资讯平台发布1篇作品,

非小号开放平台欢迎币圈作者入驻

入驻指南:

/apply_guide/

本文网址:

/news/3627214.html

TRX波场

免责声明:

1.资讯内容不构成投资建议,投资者应独立决策并自行承担风险

2.本文版权归属原作所有,仅代表作者本人观点,不代表非小号的观点或立场

下一篇:

如何利用CORS配置错误漏洞攻击比特币交易所

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:15ms0-3:64ms