一、事件背景

 

Balancer官网(https://balancer.finance/)上对于其具体功能的描述为『Easily swap ERC20 tokens. Exchange tokens without deposits, bids/asks, and order management. All on-chain.』。简单来说Balancer就是提供在链上进行tokens交换的区块链智能合约应用。

2020年6月29日凌晨(北京时间),Balancer项目的两个资金池遭受攻击。攻击者在此次事件中获利约46万美元,资金池市商损失约50万美元。

根据此次安全事件的具体过程,可以将此次事件比喻为攻击者『偷梁换柱』。

 

二、抽丝剥茧还原攻击者『偷梁换柱』经过

 

2.1、安全事件概述

▷根据链上交易数据显示:

1、 攻击者利用自建合约

(0x81d73c55458f024cdc82bbf27468a2deaa631407)对存在通缩货币STA的资产池

(0x0e511Aa1a137AaD267dfe3a6bFCa0b856C1a3682)进行了攻击;

2、 攻击者利用自建合约

(0xab9a95521107bc40dfa2e795059319f8b1302866)对存在通缩货币STONK的资产池

(0xb9eaf49d9f913bC1314e37bb5482891840c8e3C1)进行了攻击。

2.2、攻击步骤简介

攻击者首先通过闪电贷借款大量WETH,而后使用借得的WETH将被攻击资金池中的通缩货币(STA或STONK)兑换出来,仅留下1e-18个通缩货币。完成上述准备工作后,攻击者开始发动攻击,不断使用1e-18个通缩货币(STA或STONK)兑换资金池内的其他代币,以达到『偷梁换柱』的目的。直到池内资金基本被转移完后,攻击者将获利存入如下地址:

0xBF675C80540111A310B06e1482f9127eF4E7469A

攻击过程如下图所示:

△图1

此次事件发生后,Balancer团队表示已对资产池进行审计,正在进行第三次审计,并将在UI界面启用通缩货币黑名单,禁止用户建立存在通缩货币的资产池。

2.3、漏洞原理详细分析

在分析漏洞具体信息之前我们需要知道以下两点:

1、Balancer项目允许个人建立资金池。资金池本质上是一个智能合约,用户可以调用资金池的函数进行代币兑换。资金池中可以存在多种货币,用户可以使用资金池中存在的货币进行兑换,兑换的比例按照一种固定的算法,如图所示:

△图2

我们以用STA兑换WETH为例:

▷TokenAmountOut 表示可以兑换出的WETH的值

▷TokenBalanceOut 表示当前池内的WETH的值

▷TokenBalanceIn 表示当前池子内的STA的值

▷TokenAmountIn 表示用户输入的STA的值

▷TokenweightIn 表示STA的权重,为一个固定值,只能由资金池的管理者更改

▷TokenweightOut 表示WETH的权重,为一个固定值,只能由资金池的管理者更改

▷SwapFee 表示手续费,为一个固定值,只能由资金池的管理者更改

 

综上所述,当一种货币STA在一个资金池中的存量较少时,也就是bI较小时,就可以使用STA兑换更多的WETH。

2、STA代币是一种通缩货币,当进行转账操作时,会自动销毁一定量的STA。如下图所示:

△图3

tokensToBurn即为每次交易销毁的值,其销毁数额是转账数额的1/100(向上取整),如当数值为1e-18时,其销毁值也是1e-18。销毁值的计算源码如下图所示:

△图4

△图5

接下来我们对本次攻击事件进行分析,以存在STA 的被攻击资金池为例。攻击者向自建合约

(0x81d73c55458f024cdc82bbf27468a2deaa631407)发起了一笔交易

(0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106)。在此笔交易中,攻击者首先从闪电贷借出了104331个WETH,如下图所示:

△图6

而后使用借来的WETH兑换被攻击资产池中的STA,因为STA是通缩货币,每次transfer都会使得STA销毁转账金额的1/100(向上取整)。如下图为一次兑换:

△图7

这笔交易共进行了20余次兑换,使得被攻击资金池中的STA余量为一个极小值(10-18)后开始使用STA兑换其他代币(WETH),如下图所示:

△图8

我们可以发现,在此笔交易中,攻击者转给被攻击合约的STA个数是『0』,但却扣除了1e-18个STA,这不符合正常兑换情况。于是我们对此进行深入分析,通过事件日志确定攻击者发送了1e-18个STA。如下图所示:

△图9

由此可得出结论,在发送过程中,因为STA的通缩机制,发送给资金池的STA会被销毁,导致被攻击资金池无法收到STA,但资金池合约仍然会认为收到了1e-18个STA,并更新STA的存量(inRecord.balance)。如下图所示:

△图10

如果STA的存量增加,就会使得STA能够兑换其他代币的比例下降,因此攻击者又调用了gulp()方法来更新STA的余额,使得资金池的STA余额等于实际余额。如图所示:

△图11

每进行一次兑换,攻击者就会调用一次gulp()对STA的余额进行更新,这样使得STA的余额始终为1e-18个,因此每次攻击取出余额的比例都是不变的(1/2),如下图所示:

△图12

攻击者使用这种方式,将资金池中的所有代币以每次1/2的比例进行兑换,最终几乎将资金池中的所有代币全部提出。

 

2.4、攻击事件总结

根据我们日常智能合约安全审计经验来看,本次事件产生的原因,可能是资金池合约对流入资金的处理方式不够完善,并没有考虑到通缩性代币的情况,在计算应当输出的值tokenAmountOut和货币余额inRecord.balance的增减时,都是使用由用户控制的tokenAmountIn参数,而不是实际收到的代币数,导致实际池中的流入资金与记录资金不相符,如下图所示:

△图13

另外,用于更新代币余额的gulp()函数的权限是external,这两点组合起来,导致了本次事件漏洞的产生,如下图所示:

△图14

本文链接:https://www.8btc.com/media/617174
转载请注明文章出处

文章标签: 安全 Balancer
评论
登录 账号发表你的看法,还没有账号?立即免费 注册