PeckShield：bZx协议再遭黑客“二连击”背后的技术命门

PeckShield 团队在上一篇文章《 PeckShield：硬核技术解析，bZx协议遭黑客漏洞攻击始末 》中分析了 bZx 于02月15日遭到黑客一次可组合资产流动性攻击， 那是由于  bZx 合约 对抵押品状态判断不完善导致的。

02月18日，bZx 再次遭遇了类似的攻击，这一次的攻击从技术原理与上一次不同，此次黑客是通过操纵 Oracle 价格对 bZx 合约进行了“蒙骗”。

从攻击流程上来看，这一次与上次刚好相反，但 整体上的套利手段还是一致的，根本原因主要是由于平台间共享流动性过小以及价格机制设计缺陷导致的。

Figure: Five Exploitation Steps With Oracle Manipulation

本文的初衷是希望通过分析此漏洞的一些攻击细节让大家能够更直观的了解此次攻击事件，并希望可以引起更深入的讨论。我们相信，这些讨论将对 DeFi 社区的完善和发展是十分有益的，特别是项目方在开发下一代的 DeFi 类产品时，可以有助于设计出更安全，更可靠的流动性共享模型。

漏洞的攻击细节如下：

此攻击事件发生在北京时间 2020-02-18 11:18:58（块高度＃9504627 ）。攻击者的交易信息可以在 etherscan 上查到。此攻击过程可以分为以下五个步骤：

第一步：闪贷获取可用资产

bZx 合约有一个 flashBorrowToken() 接口，允许调用者可以“零成本”从 bZx 平台上借出资产参与 DeFi 活动，之后在完成这一笔交易的时候偿还这部分资产。且调用者在借出资产的同时，可以指定资产的接收方地址。

Figure1: Flashloan Borrowing From bZx

本次攻击者向 bZx 平台借出 7,500 ETH，并指定攻击者的合约（此前已经部署）为资产接收方地址，这部分是基本的借贷功能，此处不做进一步解释。

当这一步操作过后，如下表中所示系统资产分布：

第二步：拉升 sUSD

第三步：吸纳更多筹码

攻击者希望将手里的 6,000 ETH 通过 Synthetix exchangeEtherForSynths() 接口全部换成 sUSD。而 Synthetix 这边也没有足额的 sUSD 来促成这笔交易，只交换了其中的 3,518 枚 ETH，并将剩余的 2,482 枚 ETH 返还给攻击者，攻击者获得了 943,837 枚 sUSD。

Figure3：Hoarding From Synthetix

到此为止， 攻击者手里已经拥有的 sUSD 总量为 1,099,841 枚，占总发行量的  19.7%。

当前系统中的账本数据如下：

第四步：抵押借款

攻击者将手里拥有的 1,099,841 枚 sUSD 通过 bZx 的 borrowTokenFromDeposit() 接口全部抵押到 bZx 合约之中，按照 sUSD/ETH 正常价格的话，bZx 应当借给攻击者 3,928 ETH，但是 bZx 从 Oracle Kyber 这边获取的价格偏高，使得借出了 6,796 枚 ETH，多借了 2,868 ETH。

Figure4: Collateralized Borrowing From bZx

到此为止，系统的账本信息如下：

第五步：闪贷还款

攻击者利用从 bZx 借到的 6,796 枚 ETH 以及手中剩余的资产一起还给之前从 bZx 借出来的 7,500 ETH，然后退场离开，完成闪贷操作。

Figure5: Repay The Flashloan To bZx

完成整个闪电贷流程之后，当前资产情况：

1）bZx 平台对攻击者借出的 6,796 ETH；
2）bZx 平台持有 1,099,841 枚 sUSD；
3）攻击者手上还持有 2,378 枚 ETH。

最终攻击者手中持有的 2,378 ETH 部分为其获利，合计 $665,840（当前 ETH 价格$280）；而 bZx 平台负债为 2,868 ETH（6,796 - 1,099,841/280），即 $803,040。

总结

这一次的攻击事件中，我们能看出 DeFi 产品在设计过程中几个明显的问题点：

1）当引入第三方 Token 的时候，需要考察第三方 Token 的安全性，有没有可能被单方面市场操纵，从而引起价格波动；
2）DeFi 平台自身应当有价格容错与检验机制，使用第三方 Oracle 获取价格的时候，对他方的数据有尽可能多的验证；
3）平台自身对于价格也应当设立止水阀机制。

从第一次 bZx 被攻击损失 1,271 枚 ETH，这一次又损失 2,378 枚，且这两次攻击之间只相差了 3 天时间，可见 DeFi 特别项目的安全问题非常严峻。

由于各项目由不同团队开发，对各自产品的设计与实现理解有限，集成的产品很可能在与第三方平台交互的过程中出现安全问题，进而腹背受敌。PeckShield 在此建议，DeFi 项目方在上线之前，应当尽可能寻找对 DeFi 各环节产品设计有深入研究的团队做一次完整的安全审计，以避免潜在存在的安全隐患。