EOS 回滚攻击手法深度剖析：黑名单漏洞利用全解析

查找币:余老师 | 漏洞披露 | 2026-05-10 00:03 | 2 次浏览 | 0 条回复

查找币漏洞披露安全研究 Web3安全区块链安全

## 事件背景：一场席卷DApp的金融风暴 2018年12月19日，EOS生态遭遇了一场前所未有的安全危机。BetDice、EOSMax、ToBet等头部游戏类DApp相继遭受交易回滚攻击，按照当时18元人民币的EOS价格计算，总损失超过500万人民币。恐慌情绪迅速蔓延，BetDice甚至通过链金术平台多次发布紧急公告，整个生态陷入信任危机。作为查找币安全团队，我们第一时间为交易所和中心化钱包提供了临时防护方案。但攻击手法的真相，直到深入技术分析后才浮出水面。本文将完整还原这一经典攻击的底层逻辑与技术细节。 ## 技术背景：理解攻击的基石 ### 1. EOS共识机制的特殊性 EOS采用DPOS（委托权益证明）共识算法，由21个超级节点（BP）轮流出块。普通全节点没有出块权限，仅负责接收交易并广播给超级节点打包。 **关键点在于**：当交易发送给非超级节点的全节点时，交易会经历两个阶段： - 第一阶段：全节点接收交易 - 第二阶段：交易被广播至超级节点打包根据EOS共识规则，一笔交易需要获得超过2/3+1的超级节点确认（约3分钟）后，才成为不可逆区块。这意味着，交易在到达全节点但尚未被超级节点确认前，**始终处于可逆状态**（假设节点读取模式为默认的`speculative`模式）。 ### 2. 超级节点的黑名单机制每个超级节点都可以在`config.ini`文件中配置黑名单账户。被列入黑名单的账户发起的任何交易，都会被该超级节点无条件回滚。 **黑名单配置路径**： - Mac OS：`~/Library/Application Support/eosio/nodeos/config/config.ini` - Linux：`~/.local/share/eosio/nodeos/config/config.ini` **配置方法**：在`actor-blacklist`字段填入黑名单账户名，例如将`attacker`加入黑名单。 ## 攻击回顾：一场精心设计的“回滚魔术” 追踪攻击者的其中一个账户，我们发现其合约内仅包含一个`transfer`函数。更诡异的是，链上记录显示该账户只有开奖记录，**完全没有下注记录**——这就像项目方故意给这个账户开奖一样。 ### 攻击步骤详解 #### 第一步：构造“双账户”体系攻击者控制两个账户： - **黑名单账户**：用于下注，但已被项目方节点配置为黑名单 - **非黑名单代理账户**：用于接收开奖收益 #### 第二步：定向发送交易攻击者将下注交易直接发送至游戏项目方的全节点服务器（非超级节点）。该交易的`from`字段填写黑名单账户，`to`字段填写游戏合约账户。 #### 第三步：项目方节点即时开奖项目方节点收到下注交易后，立即执行开奖逻辑（线下开奖模式）。如果中奖，项目方节点会向攻击者的非黑名单代理账户发送EOS奖励。 #### 第四步：黑名单触发回滚项目方节点将下注交易和开奖交易广播给超级节点时： - **下注交易**：发起方为黑名单账户 → 被超级节点回滚（打包失败） - **开奖交易**：发起方为项目方（不在黑名单） → 被正常打包结果：攻击者只付出了“空气下注”，却获得了真实的EOS奖励。链上只留下开奖记录，下注记录全部消失。 ### 攻击流程图解 ``` 攻击者黑名单账户 → 下注交易 → 项目方全节点（即时开奖） ↓ 广播至超级节点 ↓ 下注交易（黑名单）→ 回滚开奖交易（正常）→ 打包 ``` ## 攻击复现：验证技术可行性（本复现参考EOS LIVE钱包团队的技术文章） ### 环境搭建 1. **出块节点**：模拟真实超级节点，配置黑名单账户`attacker` 2. **同步节点**：模拟项目方节点，开启自动开奖插件 ### 复现步骤 1. 在出块节点配置`actor-blacklist = attacker` 2. 通过同步节点发送下注交易，发起方为`attacker` 3. 观察链上记录：仅出现开奖交易，无下注交易查询攻击代理账户`attackproxy1`的记录，结果显示与真实攻击完全吻合——只有开奖记录，仿佛项目方在“定向送钱”。 ## 防御建议：构建多层安全屏障 ### 针对DApp开发者的防护方案 **方案一：开启Read Only模式** - 配置节点为`read-only`模式，阻止节点服务器处理未确认区块 - 配置参考：https://developers.eos.io/eosio-nodeos/docs/read-modes **方案二：建立开奖依赖机制** - 开奖逻辑必须验证对应下注订单的存在性 - 即使节点服务器开奖成功，若下注订单在超级节点被回滚，开奖记录也会自动失效 ### 针对交易所与中心化钱包的防护方案 **关键检查点**：通过RPC接口`get_actions`查询热钱包充值记录时，必须验证： - 充值交易所在的`block_num`是否小于`last_irreversible_block`（最新不可逆区块） - 若`block_num > last_irreversible_block`，则该区块仍处于可逆状态，存在“假充值”风险 ## 致谢感谢EOS LIVE钱包团队在攻击复现过程中的技术解疑与代码支持。 ## 参考文献 1. EOS节点配置指南：https://developers.eos.io/eosio-nodeos/docs/read-modes 2. EOS LIVE钱包团队技术分析：https://eos.live/detail/19255 --- **本文由查找币安全团队整理发布**

EOS 回滚攻击手法深度剖析：黑名单漏洞利用全解析

查找币安全研究院

主题延伸阅读