02月15日，bZx团队在官方电报群上发出公告，称有黑客对bZx协议进行了漏洞攻击，且已暂停除了借贷外的其他功能。对于攻击细节，bZx官方并没有进行详细披露。
PeckShield安全人员主动跟进bZx攻击事件，发现这起事件是针对DeFi项目间共享可组合流动性的设计进行攻击，特别在有杠杆交易及借贷功能的DeFi项目里，该问题会更容易被利用。
Figure1:FiveArbitrageStepsinbZxHack
漏洞的攻击细节如下：
此攻击事件发生在北京时间2020-02-1509:38:57。攻击者的transaction信息可以在?etherscan?上查到。此攻击过程可以分为以下五个步骤：
第一步：闪贷获取可用资金
攻击者通过在部署的合约中调用了?dYdX闪贷功能借入了10,000个?ETH。这部分是已知的dYdX的基本借贷功能，我们不做进一步解释。
Figure2:FlashloanBorrowingFromdYdX
当第一步操作过后，如下表中攻击者资产，此时并没有收益：
第二步：囤积WBTC现货
通过第一步闪贷获得ETH后，攻击者将其中的5,500ETH存入Compound作为抵押品，贷出112WBTC。这也是正常的Compound借贷操作，贷出的WBTC将在第四步中被抛售。
Figure3:WBTCHoardingFromCompound
在此步骤操作后，我们可以看到关于攻击者控制的资产发生了改变，但此时仍然没有获益：
第三步：杠杆拉盘WBTC价格
利用bZx的杠杆交易功能，做空ETH购入大量WBTC。具体步骤是：攻击者存入1,300ETH并调用bZx杠杆交易功能，即接口mintWithEther()，在内部会继续调用接口marginTradeFromDeposit()。接下来，攻击者将从bZx5倍杠杆获得的5,637.62个ETH，通过?KyberSwap兑换成51.345576WBTC。请注意，此处做空ETH是借来的5倍。本次交易导致将WETH/WBTC的兑换率提高到109.8，大约是正常兑换率的3倍。
为了完成此交易，KyberSwap基本上会查询其储备金并找到最优惠的汇率，最终只有Uniswap能提供这样的流通性，因此这个交易从本质上推动了Uniswap中WBTC价格上涨了3倍。
Figure4:MarginPumpingWithbZx(andKyber+Uniswap)
应该注意的是，这步操作在合约内部实现有个安全检查逻辑，但是实际上在交易之后并没有验证锁仓值。也就是说，当攻击发生时，此检查没有启用，我们在后面会有一节详细介绍此合约中的问题。
在这一步之后，我们注意到关于黑客控制的资产有以下改变。不过，在这一步之后仍然没有获利。
第四步：抛售WBTC现货
在Uniswap中WBTC价格飙升后，攻击者将第二步中通过Compound借的112WBTC全部卖给Uniswap并返还了相应的WETH。
这次交易攻击者共计获得6,871.41个ETH的净额作为回报。在这一步之后，可以看到攻击者已经获得不少利润。
Figure5:WBTCDumpingWithUniswap
第五步：闪贷还款
攻击者从抛售的112WBTC中获得的6,871.41个ETH，将闪贷的10,000个ETH偿还给dYdX，从而完成闪贷还款。
在这一步之后，我们重新计算了以下资产详情。结果显示，攻击者通过此次攻击获得71ETH，加上这两个锁仓：Compound和bZx。bZx锁仓处于违约状态，Compound的锁仓是有利可图的。显然，在攻击之后，攻击者就开始偿还Compoud债务以赎回抵押的5,500个WETH。由于bZx锁仓已经处于违约状态，攻击者也不再感兴趣了。
参考1WBTC=38.5WETH的平均市场价格，若攻击者以市场价格购入112WBTC花费约需4,300个ETH。此112WBTC用以清偿Compond债务并取回抵押品5,500ETH，则最终攻击者总共获利为?71WETH+5,500WETH-4,300ETH=1,271ETH，合计大约$355,880。
硬核解析：bZx可规避风险代码逻辑缺陷
通过前面攻击者在合约中实现的步骤可以看出，问题的核心原因是在第三步调用marginTradeFromDeposit()通过借贷的1,300ETH，加5倍杠杆来实现做空ETH/WBTC交易的，于是
我们进一步审查合约代码，发现这是一个「可避免的套利机会」，但因为代码存在的逻辑错误造成可用于规避风险的代码逻辑没有生效。具体代码追踪如下：
首先是marginTradeFromDeposit()调用_borrowTokenAndUse()，此处由于是以存入的资产作杠杆交易，第四个参数为true。
在_borrowTokenAndUse()里，当amountIsADeposit为true时，调用_getBorrowAmountAndRate()并且将borrowAmount存入sentAmounts。
在1,355行，sentAmounts被设置为sentAmounts并且于第1,370行调用_borrowTokenAndUseFinal()
经由IBZxinterface进入bZxContract的takeOrderFromiToken()函数。
bZxContract属于另一个合约?iTokens_loanOpeningFunctions?于是我们我们继续分析合约代码，在函数中发现有一个关键的逻辑判断：
在第148行，bZx事实上尝试利用oracle合约的shouldLiquidate()检查这个杠杆交易的仓位是否健康。然而，因为第一个条件已经为true，则继续执行，而忽略了shouldLiquidate()的逻辑判断。
事实上，在合约?BZxOracle?的shouldLiquidate()中实现了对getCurrentMarginAmount()<=loanOrder.maintenanceMarginAmount判断，如果执行到shouldLiquidate()就可以有效避免这个攻击的发生。
如前所述，这是一次很有意思的攻击，它结合了各种有趣的特性，如贷款、杠杆交易和拉高价格等。之所以可能发生这种攻击，是因为当前项目共享可组合流动性的设计。特别是，5倍杠杆交易允许用户以相对较低的成本借入大量代币，加上DeFi项目间共享的流动性，导致交易价格更容易被操控。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。