探究随机数漏洞背后的技术原理：EOS.WIN竞猜游戏是如何被攻破的？

近一个月内，区块链安全公司 PeckShield 已经发现并披露了 EOSBet、EOSCast、FFgame、EOSDice、EOSWin、MyEosVegas、LuckyGo、EOS Lelego 等超8款 EOS 竞猜类游戏遭到了黑客攻击，黑客总共获利170,503.5个 EOS，以此前行情均价35元/个估算，黑客已从此类游戏上获利超5,967,662.5元，已严重威胁到正常的 EOS 生态秩序。 

PeckShield 安全人员通过对多款游戏的攻击特征进行提取，初步发现：1、攻击者背后有不同黑客团伙在实施有组织且针对性的攻击；2、大部分成功攻击的原因都和随机数漏洞有关；3、类似的攻击有可能愈加频繁，且他们的攻击效率有逐渐提升的迹象。

由于绝大部分 EOS 竞猜类游戏尚未开源，为了厘清随机数漏洞背后的技术原理，摸清楚黑客屡屡攻击得手的原因。PeckShield 安全团队以较为典型的 EOS.WIN 游戏为样本进行了黑客视角还原，带大家领略下随机数漏洞攻击背后的奥秘。

11月12日，据 PeckShield 态势感知平台数据显示：上午08:59至09:00，不到一分钟时间，黑客共计向 EOS.WIN 游戏合约（eosluckydice）发起10次攻击，获利超9,180个 EOS。PeckShield 安全人员跟踪分析发现，黑客先是于昨晚22:46实施小额测试攻击，在攻击165次掌握攻击方法后，选择于次日9时许采用多个关联账号实施快速攻击。尽管该款游戏也采用了较为稳妥的两次延迟交易（deferred transaction）的信息作为随机数的组成部分，但是黑客仍然巧妙地绕过了这些限制，成功地实施了攻击。

黑客攻击原理及开奖过程：

EOS.WIN 主要是由猜数字和21点两个游戏组成，猜数字游戏玩法，用户可以任意选取一个数字，系统会根据用户所选大小给出相应赔率，然后系统会随机给出一个数字，如果结果和用户的大小选择匹配则视为中奖，获得金额为投入金额乘以赔率。

该游戏的开奖过程为：游戏合约收到玩家的交易请求，延迟1.5秒后执行开奖方法（resolved 函数），并在开奖方法中使用开奖序号参与随机数生成，同时通过内联调用方式将开奖结果信息通知给玩家（receipt 函数），再将开奖序号加1并保存。开奖流程如下图所示： 

图示1：DICE类游戏开奖流程

 

PeckShield 安全人员分析发现，该合约的随机数是通过 get_random 函数获得，影响该随机数生成的因素有：txid 为交易哈希 ID, tapos_block_num成交块高度, tapos_block_prefix 区块 ID 前缀, bet_id 全局开奖序号等。

为了进一步深入了解，先得科普几个背景知识：

1、延迟交易与 tapos_block_prefix：常见的随机数生成方法中，大多使用 tapos_block_num 和 tapos_block_prefix  作为重要的组成部分，在交易中指定未来某个区块的信息，来保证不可预测性。如果合约中使用了延迟交易的方式，也就是说在交易时（比如开奖）指定了延迟的间隔，看似是使用未来信息，其实在发出这个交易时，系统就已经指定使用当前同步到的最新块（head_block）信息，进而 tapos_block_num 和 tapos_block_prefix 也是确定的。

2、交易状态信息回滚：在 EOS 的交易中，如果一个交易中的某个动作（action）执行异常，会导致整个交易状态的回滚。例如在自己的帐号中部署合约，在每次收到转账通知（transfer receipt）时抛异常，可以导致整个转账过程失败，所有的状态信息，包括余额等都保持原样。

3、计算交易哈希 ID：一个交易（transaction）中可以包含多个 action，如果所有 action 参数信息都确定，那么再结合前面提到的 tapos_block_prefix （ref_block_prefix） 信息，就能自己计算出交易哈希 ID。

简而言之，攻击者利用了开奖序号（ bet_id）参与随机数生成和内联调用失败可导致状态信息回滚的特性，在同一时间控制多个合约帐号同时发送交易请求，来尽量保证最后请求的帐号能够获得期望的开奖序号参与生成随机数，以赢得奖励。以 EOS.WIN 为例，攻击者先是用5个账号佯攻实施小金额投注，在掌握更高概率后，用最后1个金额最大的账号主攻投注，从而以更高概率斩获奖金。

具体攻击过程如下（如下图）：

一、攻击者部署了6个攻击合约，调用攻击方法时，在攻击合约中同时让这6个帐号发送交易请求，这样这些请求将会在同一个块中开奖，由于过程一致，开奖交易中的 tapos_block_num 和 tapos_block_prefix 是一样的，只有bet_id可能不同。

二、攻击者的前5个攻击合约，在收到开奖通知时，能够获取到当前的 bet_id，并判断此 id 能否让最后的帐号中奖。

1）如果计算得知最后的帐号不能中奖，则该帐号的开奖通知正常执行，使得后面的帐号使用新的开奖序号来计算随机数；

2）如果计算得知最后的帐号能中奖，则使该帐号的开奖通知失败，那么这个开奖序号被保留下来，直到最后的帐号中奖；

图示2：攻击者多账号实施攻击过程

 

获奖概率：

从上述的开奖和攻击过程可知，每增加一个佯攻的帐号，就多了一次提前计算最后主攻帐号能否获奖的机会。按猜数选择20来算赔率为5倍，6个帐号会提高中奖概率至大约74%，虽然仍无法保证每次攻击必中奖，但攻击者10次攻击能中奖6次，已经是超高且扰乱正常游戏的秩序的获奖概率。

安全建议：

在诸如此类 EOS.Win 的游戏中随机数受到攻击者可控制的变量即游戏开奖序号（bet_id）的影响，因此PeckShield在此建议开发者，在 DApp 的随机数生成上，需要去除攻击者可控制的变量如游戏开奖序号等影响，同时避免开奖动作和通知动作（receipt）在同一个交易中，从而避免交易状态的回滚，进而阻止来自黑客的攻击。

--------------------- 
作者：PeckShield 
来源：CSDN 
原文：https://blog.csdn.net/PeckShield/article/details/84335728 
版权声明：本文为博主原创文章，转载请附上博文链接！