8 月 22 日,一个名不见经传的游戏 God.Game 发出通告,声称遭遇黑客攻击,游戏内的以太币被黑客全部转走。这一消息一时间传遍各大媒体以及讨论群,人们在质疑相关游戏安全性之余,也在揣测项目方动机,一时间难以分清到底是黑客攻击,还是游戏开发方留有后门跑路。
安比(SECBIT)实验室的小伙伴在得到消息后,迅速开展了追踪分析。
God.Game 简单规则如下:GOD 股份购买的所有数量的 10% 被征税并且作为被动的 ETH 收入分配给所有GOD所有者。
通过游戏官网规则,以及合约源码分析,不少人会认为 God.Game 是 PoWH3D 的直接仿品,安比(SECBIT)实验室仔细分析后发现,它其实是综合“借鉴” PoWH3D 和 Zethr 的混合仿品。
PoWH3D 是最近大热的 Fomo3D 游戏团队上一款作品。而 Zethr 则是在 PoWH3D 基础上进一步开发优化,新增不同玩法的另一款热门游戏。二者在玩法规则层面的细节差别,这里不做讨论。
God.Game 游戏漏洞本身不复杂,不少安全公司也发出相关攻击手法的短篇快讯消息,部分不够详尽,安比(SECBIT)实验室通过本文全面分析该漏洞,重点分享漏洞追踪和定位的详细过程与大家讨论交流。
疑点一:攻击是无意还是刻意
一下子提走合约内所有以太币的人,是参与游戏过程中无意发现了漏洞,还是刻意进行的操作?
安比(SECBIT)实验室认为是后者,因为分析下来,该漏洞虽然隐藏不是很深,但实际触发需要一系列组合操作(类似玩游戏按上上下下左左右右开启作弊),正常游戏玩家的普通参与几乎不可能触发漏洞。安比(SECBIT)实验室分析攻击者的交易记录,发现其手段十分娴熟,目的性极强,明显是奔着该漏洞而来。
疑点二:攻击者的时机选择
攻击者为什么恰好选择在奖池金额 243 个以太币时发动攻击?
上面是游戏合约账户余额趋势图,横坐标是区块高度,纵坐标是 God.Game 合约账户余额。此图可反映随着时间推进,入场资金情况。安比(SECBIT)实验室发现,God.Game 合约部署上线后,合约资金量长期一直在 50 以太币以下,但在 6179500 区块高度以后,入场资金开始猛增到接近 260 个以太币(大量韭菜入场),随后略有衰退(一部分人选择提现退出),进入一段很长的调整停滞期。
无论是 Fomo3D 还是 PoWH3D,这类庞氏游戏最早期入场资金优势都很大,可以较快速回本。后续只有在持续大规模地运营宣传下,才可能有大量新资金入场参与游戏。因此游戏第一时间内的入场资金,基本决定了游戏资金量的总体规模。
而攻击者正是在资金规模就快回升到前期高点时,果断出击,利用漏洞果断提走游戏内的所有以太币。于是形成了上图类似“高台跳水”的有趣情景。
这蹊跷的手法、这迷人的走势是不是有些眼熟?
疑点三:是漏洞还是后门
到底是无意引入的漏洞还是刻意暗留的后门?
前面提到,God.Game 游戏代码重度参考了 PoWH3D 和 Zethr。而与漏洞相关的关键函数名 transferFromInternal()
只在 Zethr 合约代码中有出现。
上图所示问题代码,“创新”地增加了一组关于转账双方是合约、还是普通账户的分支情况处理。面对这一串冗长的代码,只要清楚 PoWH3D 工作原理,就很容易能发现此处代码逻辑根本说不通,也无法在游戏实际规则中找到适配点。并且这种根据账户类型分别处理账本的逻辑在原版 PoWH3D 和 Zethr 中根本没有出现。
God.Game 代码此处函数命名仿照了 Zethr,但是具体变量名却是仿造 Fomo3D,代码风格十分诡异。可以推断以下两种情况:代码作者有可能是因为没有理解 PoWH3D 游戏机制引入了漏洞;也有可能是故意增加代码混乱度来迷惑他人,以达到埋藏后门之目的。
特别地,安比(SECBIT)实验室还发现同样是 transferFromInternal()
函数,God.Game 代码中唯一与 Zethr 相近的地方,就是上图示例中针对 ERC223 代码做的回落处理,似乎是想通过引入此段代码(需要判断目标地址是否是合约)来为前面提到的不合逻辑代码打掩护。
异常:飙升的 Token 售价
下面让我们进入安比(SECBIT)实验室安全研究员 sha3 的第一视角,让 TA 为你拨开漫漫迷雾找出漏洞。
Good Luck Have Fun.
我们首先进入游戏首页,发现单个God token的售价已经飙升至300ETH,而被God.Game抄袭的火爆原版游戏PoWH3D的单价才0.02ETH,面对不寻常的数值,敏感的安比(SECBIT)实验室小伙伴首先怀疑该游戏合约可能存在整数溢出漏洞。
为了考证我们的想法,我们想到了回溯God.Game过往的售价变化过程(感谢区块链技术,让我们无法消灭历史),寻找在何处触发了整数溢出漏洞。
通过遍历区块历史数据,发现在6182409高度时,buyPrice/sellPrice等数据飙升,于是我们便仔细分析该区块中和God.Game相关的交易。
分析发现,在6182409区块中,唯一和God.Game产生关联的交易是0x368688a944059fdd657e7842d8762b05250bd45f3a2a16cbae1b29727023b00f
。
在该交易中,0x2368Beb4调用0x7f325EfC的reinvest()
后,继而调用了0xca6378fc中的reinvest()
,(通过简单的逆向分析,我们暂时认为0x7f325EfC是一个简单的代理合约,实现了God.Game游戏的基本接口)。
一番操作:定位到攻击源
我们不禁问道,为何调用一次reinvest()
就可以将游戏中的各个数据全部暴增,我们怀疑创建这个合约的账户就是攻击者。
顺着这条线索,我们观察到这个合约的创建者,即0x2368Beb4,在6182409高度之前通过合约0x7f325EfC进行了另外几次操作。
具体操作历史如下:
区块高度 | From | To | call |
---|---|---|---|
6182399 | 0x2368Beb4 | 0xca6378fc | transfer(address,uint256) |
6182399 | 0xca6378fc | 0x7f325EfC | tokenFallback(address,uint256,bytes) |
6182403 | 0x2368Beb4 | 0x7f325EfC | withdraw() 3ccfd60b |
6182403 | 0x7f325EfC | 0xca6378fc | withdraw() 3ccfd60b |
6182403 | 0xca6378fc | 0x7f325EfC | |
6182406 | 0x2368Beb4 | 0x7f325EfC | transfer(address,uint256) |
6182406 | 0x7f325EfC | 0xca6378fc | transfer(address,uint256) |
6182409 | 0x2368Beb4 | 0x7f325EfC | reinvest() fdb5a03e |
6182409 | 0x7f325EfC | 0xca6378fc | reinvest() fdb5a03e |
6182419 | 0x2368Beb4 | 0x7f325EfC | sell(uint256) |
6182419 | 0x7f325EfC | 0xca6378fc | sell(uint256) |
6182439 | 0x2368Beb4 | 0x7f325EfC | transfer(address,uint256) |
6182439 | 0x7f325EfC | 0xca6378fc | transfer(address,uint256) |
6182462 | 0x2368Beb4 | 0x7f325EfC | transfer(address,uint256) |
6182462 | 0x7f325EfC | 0xca6378fc | transfer(address,uint256) |
再看看reinvest()
函数调用时产生的event。
我们看到了0000000000000000fffffffffffffffffffffffffffffffffffcf2ac578ec8d9
这个极像溢出的值。
随即我们打开God.Game源代码,搜寻其中的蛛丝马迹。
我们将目标锁定到reinvest()
函数。
function reinvest()
onlyProfitsHolders()
public
{
// fetch dividends
uint256 _dividends = myDividends(false);
// retrieve ref. bonus later in the code
// pay out the dividends virtually
address _customerAddress = msg.sender;
payoutsTo_[_customerAddress] += (int256) (_dividends * magnitude);
// retrieve ref. bonus
_dividends += referralBalance_[_customerAddress];
referralBalance_[_customerAddress] = 0;
// dispatch a buy order with the virtualized "withdrawn dividends"
uint256 _tokens = purchaseTokens(_dividends, 0x0);
// fire event
emit onReinvestment(_customerAddress, _dividends, _tokens);
}
首先大概浏览一下reinvest()
函数主体,仅有两个简单的加法,但是通常在减法溢出中会出现巨型整数,我们便开始探索reinvest()
调用的函数。
首先引起我们注意的便是myDividends(false)
函数,由于参数传入了false,我们就直接研究它最终调用的函数dividendsOf(_customerAddress)
。
function dividendsOf(address _customerAddress)
view
public
returns (uint256)
{
return (uint256) ((int256)(profitPerShare_ * tokenBalanceLedger_[_customerAddress]) - payoutsTo_[_customerAddress]) / magnitude;
}
Aha,看到减法了!
会不会就是在这里发生了溢出呢?
历史回放:精确找到溢出点
带着这样的疑问,我们回溯了0x368688a944059fdd657e7842d8762b05250bd45f3a2a16cbae1b29727023b00f
这笔交易的trace,我们跟着静态分析结果,直接在trace中将PC指针定位到了dividendsOf
函数中。
发现在0x0a8c指针处执行了sub指令,并且sub指令在栈上的两个参数分别为0和0x30d53a87137270000000000000000
减法、除法执行完毕后栈顶变成了0xfffffffffffffffffffffffffffffffffffcf2ac578ec8d9
,和event中的值完全相同。
果然,我们找到了发生溢出的地方,并且确定reinvest()
函数使用了溢出后的值。
顺藤摸瓜:推理怎么构造溢出条件
那么问题来了,我们有什么办法能让这个减法溢出呢?
回想sub指令的参数:
- 第一个参数 0 对应
profitPerShare_ * tokenBalanceLedger_[_customerAddress]
- 第二个参数
0x30d53a87137270000000000000000
对应payoutsTo_[_customerAddress]
思路来了,我们需要达成2个目标:
- 使得
profitPerShare_ * tokenBalanceLedger_[_customerAddress]
的计算结果为0, - 使得
payoutsTo_[_customerAddress]
中存储的值为正数
首先我们看目标1,对于profitPerShare_
变量,纵观全部代码,只有增加没有减,无法有效地将这个值变为0,那么只有tokenBalanceLedger_[_customerAddress]
才能给我们修改的机会。
然后目光看向目标2,payoutsTo_[_customerAddress]
必须设置为正值。
我们看到在transferFromInternal()
、withdraw()
函数均中对该值有操作,不由得想到了上文看到攻击者的4步组合拳,这4步具体发生的操作如下:
- transfer (攻击者调用God.Game合约的transfer函数将token转移到到攻击者创建的合约)
- withdraw (攻击者调用代理合约的withdraw函数,代理合约调用God.Game的withdraw函数讲ETH提入代理合约)
- transfer (攻击者调用代理合约的transfer函数,将God.Game中代理合约的token转移到攻击者账户)
- reinvest (攻击者调用代理合约的reinvest函数,代理合约调用God.Game的reinvest函数触发溢出)
谜底揭开:漂亮的组合拳
我们不妨看看在God.Game合约中发生了什么?
攻击者第1步:从自己账户转移token到合约,触发transferFromInternal
函数中的第一个else if分支:
else if (fromLength <= 0 && toLength > 0) {
// human to contract
contractAddresses[_toAddress] = true;
contractPayout += (int) (_amountOfTokens);
tokenSupply_ = SafeMath.sub(tokenSupply_, _amountOfTokens);
payoutsTo_[_from] -= (int256) (profitPerShare_ * _amountOfTokens);
}
攻击者将自身的payoutsTo_[_customerAddress]
被减为负数,紧接着修改``tokenBalanceLedger_[from/to]`进行普通的token转账操作,给代理合约一些token以便拥有dividens。
攻击者第2步:代理调用withdraw()
,payoutsTo_[_customerAddress]
值增加。
攻击者第3步:将代理合约的token转移到攻击者账户,触发transferFromInternal
中的if分支:
if (fromLength > 0 && toLength <= 0) {
// contract to human
contractAddresses[_from] = true;
contractPayout -= (int) (_amountOfTokens);
tokenSupply_ = SafeMath.add(tokenSupply_, _amountOfTokens);
payoutsTo_[_toAddress] += (int256) (profitPerShare_ * _amountOfTokens);
}
攻击者的payoutsTo_[_customerAddress]
值增加,同时将代理合约中的token全部转移到攻击账户中。
可以看到,这3步组合让代理合约满足了减法溢出所需条件:
- 通过第1、第3两步将代理合约的
tokenBalanceLedger_[_customerAddress]
置为0 - 通过第2步将
payoutsTo_[_customerAddress]
值置为正数
攻击者第4步,猛烈一击,调用reinvest()
触发dividendsOf()
的减法溢出,攻击者获取巨量的dividens,将divisions转换为token。
由于token数量过多,合约储备金额不够withdraw()
,攻击者便将部分token转移到0xC30E89DB73798E4CB3b204Be0a4C735c453E5C74,通过0xC30E89DB73798E4CB3b204Be0a4C735c453E5C74进行sell操作卖出token换取ETH,合约储备金面对巨量增发的token,瞬间消耗殆尽,攻击者成功提取了几乎所有的ETH。
Good Game.
God.Game 风波带来的思考
近来各类山寨版本智能合约游戏盛行,已经发生很多起安全事件,安比(SECBIT)实验室不久前已针对 Fomo3D 和 Last Winner 进行了一系列详细的漏洞披露和解析。而这次 God.Game 甚至上线不久就宣告被黑客攻击游戏结束,很多玩家的投入无法兑现,导致出现一些「游戏(投资)群」秒变「维权群」的闹剧。
安比(SECBIT)实验室提醒广大智能合约游戏爱好者,务必要擦亮双眼,提高安全意识,谨慎参与不明游戏(小心漏洞与后门),并且对于任何游戏都不要投入超出承受能力范围的资金。
游戏智能合约在一定程度上比一般 Token 合约更复杂,一些漏洞会隐藏得更深,触发条件更苛刻。很多游戏甚至会有更高层次的关于公平性、博弈机制的漏洞存在,需要从游戏模型设计、代码实现等各种角度进行安全评估。安比(SECBIT)实验室建议所有负责任的智能合约游戏开发商,都应该提高安全意识,加大安全投入。
参考文献
- [1] God.Game 合约地址,https://etherscan.io/address/0xca6378fcdf24ef34b4062dda9f1862ea59bafd4d
- [2] PowH3D (P3D) 合约地址,https://etherscan.io/address/0xb3775fb83f7d12a36e0475abdd1fca35c091efbe
- [3] Zethr (ZTH) 合约地址,https://etherscan.io/address/0xD48B633045af65fF636F3c6edd744748351E020D
- [4] BCSEC:GodGame漏洞原理以及黑客攻击手法分析,https://bcsec.org/index/detail/tag/2/id/252
- [5] 安比实验室:Fomo3D 千万大奖获得者“特殊攻击技巧”最全揭露,https://mp.weixin.qq.com/s/MCuGJepXr_f18xrXZsImBQ
- [6] 安比实验室:智能合约史上最大规模攻击手法曝光,盘点黑客团伙作案细节,https://mp.weixin.qq.com/s/YBG8YyPwh374HbGWcUKTdQ
以上数据均由安比(SECBIT)实验室提供,合作交流请联系info@secbit.io。
安比(SECBIT)实验室
安比(SECBIT)实验室专注于区块链与智能合约安全问题,全方位监控智能合约安全漏洞、提供专业合约安全审计服务,在智能合约安全技术上开展全方位深入研究,致力于参与共建共识、可信、有序的区块链经济体。
安比(SECBIT)实验室创始人郭宇,中国科学技术大学博士、耶鲁大学访问学者、曾任中科大副教授。专注于形式化证明与系统软件研究领域十余年,具有丰富的金融安全产品研发经验,是国内早期关注并研究比特币与区块链技术的科研人员之一。研究专长:区块链技术、形式化验证、程序语言理论、操作系统内核、计算机病毒。
网友评论