EOS:慢雾：破解造成 BetDice 项目恐慌的交易回滚攻击手法

2018年12月19日，众多游戏类DApp遭遇交易回滚攻击，其中包括BetDice，EOSMax，ToBet等。按当时18元人民币的价格计算，损失超过500万人民币。期间BetDice通过链金术平台发出多次公告,一度造成恐慌。

与此同时，慢雾安全团队对交易所和中心化钱包给出了暂时性的方案。此刻，攻击手法依旧是一个谜团。那么，攻击手段究竟是怎样的呢？在进行攻击回顾之前，需要先了解一点技术背景。

技术背景

1、我们知道EOS采用的共识算法是DPOS算法，采用的是21个超级节点轮流出块的方式。除了21个超级节点外的其他全节点，并没有出块的权限。起到的作用是将收到的交易广播出去，然后超级节点将其进行打包。

说到这里，很容易看出，如果一笔交易是发给除了超级节点外的其他全节点，这笔交易会经历两个过程。首先，这笔交易先被全节点接收，然后交易再被节点广播出去进行打包。而一笔交易是需要超级节点中超过2/31的节点进行确认之后才是不可回滚的，也就是不可逆的。

这个过程大概需要3分钟左右，也就是说，交易发到除了超级节点外的全节点的时候，由于全节点没有打包的权利，此时此刻交易仍然处于可逆状态。这是一个核心关键点。

慢雾：利用者通过执行恶意提案控制了Tornado.Cash的治理:金色财经报道，SlowMist发布Tornado.Cash治理漏洞解析。 5月20日，Tornado.Cash遭受了治理攻击，利用者通过执行恶意提案控制了Tornado.Cash的治理。5月13日，利用者发起了20提案，并在提案中说明20提案是对16提案的补充，具有相同的执行逻辑。但实际上，提案合约多了一个自毁逻辑，其创建者是通过create2创建的，具有自毁功能，所以在与提案合约自毁后，利用者仍可以部署不同的以与以前相同的方式将字节码发送到相同的地址。不幸的是，社区没有看到拟议合约中的犯规行为，许多用户投票支持该提案。

在5月18日，利用者通过创建具有多个交易的新地址，反复将0代币锁定在治理中。利用提案合约可以销毁并重新部署新逻辑的特性，利用者在5月20日7:18（UTC）销毁了提案执行合约，并在同一地址部署了一个恶意合约，其逻辑是修改用户在治理中锁定的代币数量。

攻击者修改完提案合约后，于5月20日7:25（UTC）执行恶意提案合约。该提案的执行是通过 Delegatecall 执行的，因此，该提案的执行导致治理合约中由开发者控制的地址的代币锁定量被修改为 10,000。提案执行完成后，攻击者从治理库中解锁了TORN代币。金库中的TORN代币储备已经耗尽，同时利用者控制了治理。[2023/5/21 15:17:00]

2、每一个bp，都可以在自己的节点的config.ini文件内进行黑名单的配置，在黑名单中的帐号是不能进行交易的，也就是说无论怎样，黑名单的交易都会被回滚。

慢雾：昨日MEV机器人攻击者恶意构造无效区块，建议中继运营者及时升级:金色财经报道，慢雾分析显示，昨日MEV机器人被攻击的问题原因在于即使信标区块不正确，中继仍将有效载荷（payload）返回给提议者，导致了提议者在另一个区块被最终确定之前就能访问区块内容。攻击者利用此问题，恶意构造了无效的区块，使得该区块无法被验证，中继无法进行广播（状态码为202）从而提前获得交易内容。mev-boost-relay昨日已紧急发布新版本缓解此问题，建议中继运营者及时升级中继。

据此前报道，昨日夹击MEV机器人的恶意验证者已被Slash惩罚并踢出验证者队列。[2023/4/4 13:43:37]

黑名单配置路径：

MacOS：

~/Library/ApplicationSupport/eosio/nodeos/config/config.ini

Linux:

~/.local/share/eosio/nodeos/config/config.ini

配置方法：将config.ini文件内的actor-blacklist填入黑名单帐号，如下图中，将attacker这个帐号作为黑名单帐号。

慢雾：GenomesDAO被黑简析:据慢雾区hacktivist消息，MATIC上@GenomesDAO项目遭受黑客攻击，导致其LPSTAKING合约中资金被非预期的取出。慢雾安全团队进行分析有以下原因：

1.由于GenomesDAO的LPSTAKING合约的initialized函数公开可调用且无权限与不可能重复初始化限制，攻击者利用initialized函数将合约的stakingToken设置为攻击者创建的虚假LP代币。

2.随后攻击者通过stake函数进行虚假LP代币的抵押操作，以获得大量的LPSTAKING抵押凭证。

3.获得凭证后再次通过initialized函数将合约的stakingToken设置为原先真是的LP代币，随后通过withdraw函数销毁LPSTAKING凭证获取合约中真实的LP抵押物。

4.最后将LP发送至DEX中移除流动性获利。

本次事件是因为GenomesDAO的LPSTAKING合约可被任意重复初始化设置关键参数而导致合约中的抵押物被恶意耗尽。[2022/8/7 12:07:06]

了解了以上的知识点之后，我们就可以进行整个攻击事件的回顾了。

慢雾：Polkatrain 薅羊毛事故简析:据慢雾区消息，波卡生态IDO平台Polkatrain于今早发生事故，慢雾安全团队第一时间介入分析，并定位到了具体问题。本次出现问题的合约为Polkatrain项目的POLT_LBP合约，该合约有一个swap函数，并存在一个返佣机制，当用户通过swap函数购买PLOT代币的时候获得一定量的返佣，该笔返佣会通过合约里的_update函数调用transferFrom的形式转发送给用户。由于_update函数没有设置一个池子的最多的返佣数量，也未在返佣的时候判断总返佣金是否用完了，导致恶意的套利者可通过不断调用swap函数进行代币兑换来薅取合约的返佣奖励。慢雾安全团队提醒DApp项目方在设计AMM兑换机制的时候需充分考虑项目的业务场景及其经济模型，防止意外情况发生。[2021/4/5 19:46:39]

攻击回顾

跟踪攻击者的其中一个攻击帐号，发现帐号合约内只有一个transfer函数

同时，我们可以通过复盘这个帐号的所有交易记录发现，这个帐号只有开奖记录，而没有下注记录，看起来就好像项目方故意给这个帐号进行开奖一样。然而事实上并非如此。那为什么会出现这样的情况呢？这就需要上面的技术背景的知识了。以下是详细的攻击手法：

声音 | 慢雾：使用中心化数字货币交易所及钱包的用户注意撞库攻击:据慢雾消息，近日，注意到撞库攻击导致用户数字货币被盗的情况，具体原因在于用户重复使用了已泄露的密码或密码通过撞库攻击的“密码生成基本算法”可以被轻易猜测，同时用户在这些中心化服务里并未开启双因素认证。分析认为，被盗用户之所以没开启双因素认证是以为设置了独立的资金密码就很安全，但实际上依赖密码的认证体系本身就不是个足够靠谱的安全体系，且各大中心化数字货币交易所及钱包在用户账号风控体系的策略不一定都一致，这种不一致可能导致用户由于“惯性思维”而出现安全问题。[2019/3/10]

1、首先：攻击者调用非黑名单合约的transfer函数，函数内部有一个inlineaction进行下注，from填写的是攻击者控制的非黑名单合约帐号，to填写的是游戏合约帐号。这时，攻击者发送交易是发向游戏合约自己的全节点服务器。使用的是黑名单帐号进行。

2、游戏节点读取到了这笔交易，立刻进行开奖，如果中奖，将对攻击者控制的非黑名单帐号发送EOS。

3、在经历了一个1，2两个操作之后。理论上攻击者控制的非黑名单帐号是进行了余额扣除。然后进行正常的开奖逻辑。到这里之前，一切都是正常的。也许有读者会问，为什么配置了黑名单，交易还能正常发起？原因是这个黑名单生效范围是在bp内，普通的全节点的config.ini内是没有黑名单的配置的。所以攻击者依然可以发起交易。

4、到此为止，攻击正式开始，也到了最关键的地方，由于项目方节点在收到下注交易的时候已经立马完成了开奖逻辑，而且采用的是线下开奖的模式，即下注交易和开奖交易是两笔不同的交易。但是，这两笔交易仅仅是在项目方的节点内完成，仍然是可逆的。当项目方节点向bp广播这两笔交易的时候，由于第一笔下注交易的发起者在bp节点的黑名单内，这一笔交易将被回滚，也就是打包失败，而开奖交易的发起者是项目方，不在黑名单之内，会被正常打包。因此两笔交易中的第一笔下注交易一定会被回滚，而开奖交易依旧会被打包，这也就解释了为什么只有开奖记录，而没有下注记录。因为下注记录都被回滚了。

整个过程可以参考下面的图：

攻击复现

本次攻击复现参考EOSLIVE钱包团队的文章：https://eos.live/detail/19255

1、环境准备

本地准备两个节点，一个出块节点，一个同步节点，出块节点用于模拟真实bp，而同步节点则用于模拟项目方，其中出块节点需要开启history插件，方便后续的debug，并且把attacker加入节点黑名单。方便后续的debug。打包节点则需要开启自动开奖插件,自动开奖插件配置详见：

https://github.com/superoneio/security

本次复现用到的代码：

https://github.com/superoneio/security

本地多节点配置方法官方参考：

https://developers.eos.io/eosio-nodeos/docs/local-multi-node-testnet

三个测试帐号，分别是tobetioadmin,tobetiologs1,attackproxy1，分别为项目方帐号，项目方log帐号，和攻击代理帐号，其中tobetioadmin部署tobet游戏合约，tobetiologs1部署logs合约，attackproxy1部署attack合约。注意除了攻击代理帐号外的其他两个帐号不要改为其他帐号，如果改为其他帐号需要对自动开奖插件进行修改，自动开奖插件是拦截tobetioadmin这个帐号的。

附上我的双节点的配置：

其中nodeos_main为出块节点，nodeos_second为同步节点。

2、启动节点

看到以上信息则代表dice_plugin配置成功

3、首先对正常的逻辑进行测试。

使用attackproxy1对tobetioadmin帐号进行正常的转账交易

可以看到，攻击代理合约进行了正常的转账。

4、开始攻击，使用黑名单帐号调用攻击代理合约，向项目方合约发起攻击。查询初始余额

为保证攻击成功，连续向项目方发起4起攻击

再次查询余额

查询attacker帐号记录

可见，并没有attacker对attackproxy1的调用记录，最后两条记录是我测试直接使用黑名单向tobetadmin发起攻击的时候留下的记录。与本次测试无关。但是通过查询发现，本地记录和链上记录是相吻合的，即无下注记录。

查询attackproxy1的帐号记录

可以看到的是，这个也与链上记录吻合，只有开奖记录，就像tobetadmio故意给attackproxy1开奖一般。

通过以上的复现及和链上记录的对比，我们可以证明上文说的攻击手法，就是黑客本次进行攻击的手法，采用的就是使用黑名单进行回滚的操作。

防御建议

1、针对DApp的防御建议

节点开启readonly模式，防止节点服务器上出现未确认的块建立开奖依赖，如订单依赖，开奖的时候判断订单是否存在，就算在节点服务器上开奖成功，由于在bp上下注订单被回滚，所以相应的开奖记录也会被回滚。

2、针对交易所和中心化钱包的防御建议

慢雾安全团队建议EOS交易所及中心化钱包在通过RPC接口get_actions查询热钱包充值记录时，应检查充值transaction所在的block_num是否小于last_irreversible_block，如果block_num大于last_irreversible_block则表示该区块仍然是可逆的，存在「假充值」风险。

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

慢雾科技

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

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

入驻指南：

/apply_guide/

本文网址：

/news/3627097.html

免责声明：

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

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

上一篇：

再提Mt.Gox，糟糕的「里程碑事件」正提升区块链世界的安全意识

下一篇：

复盘数十万EOS被盗过程，背后是其架构设计缺陷？

标签：EOSACKBETATTEOS Se7ensCryptojacksPUML Better Healthattn币价格

XMR热门资讯