一、事件背景
Balancer官网上对于其具体功能的描述为『EasilyswapERC20tokens.Exchangetokenswithoutdeposits,bids/asks,andordermanagement.Allon-chain.』。简单来说Balancer就是提供在链上进行tokens交换的区块链智能合约应用。
2020年6月29日凌晨，Balancer项目的两个资金池遭受攻击。攻击者在此次事件中获利约46万美元，资金池市商损失约50万美元。
根据此次安全事件的具体过程，可以将此次事件比喻为攻击者『偷梁换柱』。
二、抽丝剥茧还原攻击者『偷梁换柱』经过
2.1、安全事件概述
?根据链上交易数据显示：
1、攻击者利用自建合约
对存在通缩货币STA的资产池
进行了攻击；
2、攻击者利用自建合约
对存在通缩货币STONK的资产池
进行了攻击。
2.2、攻击步骤简介
攻击者首先通过闪电贷借款大量WETH，而后使用借得的WETH将被攻击资金池中的通缩货币兑换出来，仅留下1e-18个通缩货币。完成上述准备工作后，攻击者开始发动攻击，不断使用1e-18个通缩货币兑换资金池内的其他代币，以达到『偷梁换柱』的目的。直到池内资金基本被转移完后，攻击者将获利存入如下地址：
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的被攻击资金池为例。攻击者向自建合约
发起了一笔交易
。在此笔交易中，攻击者首先从闪电贷借出了104331个WETH，如下图所示：
△图6
而后使用借来的WETH兑换被攻击资产池中的STA，因为STA是通缩货币，每次transfer都会使得STA销毁转账金额的1/100。如下图为一次兑换：
△图7
这笔交易共进行了20余次兑换，使得被攻击资金池中的STA余量为一个极小值后开始使用STA兑换其他代币，如下图所示：
△图8
我们可以发现，在此笔交易中，攻击者转给被攻击合约的STA个数是『0』，但却扣除了1e-18个STA，这不符合正常兑换情况。于是我们对此进行深入分析，通过事件日志确定攻击者发送了1e-18个STA。如下图所示：
△图9
由此可得出结论，在发送过程中，因为STA的通缩机制，发送给资金池的STA会被销毁，导致被攻击资金池无法收到STA，但资金池合约仍然会认为收到了1e-18个STA，并更新STA的存量。如下图所示：
△图10
如果STA的存量增加，就会使得STA能够兑换其他代币的比例下降，因此攻击者又调用了gulp()方法来更新STA的余额，使得资金池的STA余额等于实际余额。如图所示：
△图11
每进行一次兑换，攻击者就会调用一次gulp()对STA的余额进行更新，这样使得STA的余额始终为1e-18个，因此每次攻击取出余额的比例都是不变的，如下图所示：
△图12
攻击者使用这种方式，将资金池中的所有代币以每次1/2的比例进行兑换，最终几乎将资金池中的所有代币全部提出。
2.4、攻击事件总结
根据我们日常智能合约安全审计经验来看，本次事件产生的原因，可能是资金池合约对流入资金的处理方式不够完善，并没有考虑到通缩性代币的情况，在计算应当输出的值tokenAmountOut和货币余额inRecord.balance的增减时，都是使用由用户控制的tokenAmountIn参数，而不是实际收到的代币数，导致实际池中的流入资金与记录资金不相符，如下图所示：
△图13
另外，用于更新代币余额的gulp函数的权限是external，这两点组合起来，导致了本次事件漏洞的产生，如下图所示：
△图14
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。