bZx协议再遭黑客“二连击”背后的技术命门_BZX:USD

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

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

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

Figure: Five Exploitation Steps With Oracle Manipulation

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

DeFi借贷平台bZx:私钥泄露导致bZx智能合约在Polygon和BSC上的部署受影响:11月5日消息,DeFi借贷平台bZx发推表示,一个小时前,控制Polygon和BSC上bZx智能合约部署的私钥似乎已被泄露,导致资金损失。以太坊部署受DAO控制,不受影响。bZx将进行社区投票,以使用金库作为支持,使BSC和Polygon上的部署变得完整。如果用户在Polygon或BSC上批准了bZx合约的任何代币,尽快撤销批准。以太坊上的部署、治理和DAO金库均未受此事件影响。bZx智能合约本身没有受到损害。此事件仅通过泄露的密钥影响了Polygon和BSC上的部署。[2021/11/5 21:28:35]

漏洞的攻击细节如下:

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

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

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

DeFi借贷协议bZx将于9月1日开启流动性挖矿:8月31日,DeFi借贷协议bZx官方宣布,将于9月1日开启流动性挖矿。此前消息,在bZx协议的通证经济生态中,分为iToken、pToken和GovernanceToken(BZRX)三种。iToken是用于累积利息的通证,它代表了借贷池中的份额,随着借方向其中支付利息,借贷池中的份额会不断增加。iToken可以交易,用作抵押品,或是由开发人员组合成结构化产品。pToken是用于加杠杆的通证,它代表了某标的资产特定倍数的多头或空头头寸。BZRX则是治理通证,为中继节点收集交易手续费,有点像中心化交易平台中有权益属性的平台币。[2020/8/31]

Figure1: Flashloan Borrowing From bZx

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

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

DeFi贷款协议bZx公布BZRX地址,代币将于7月13日开始释放:7月12日消息,DeFi贷款协议bZx在推特表示,其代币BZRX地址已经确定为0x56d811088235F11C8920698a204A5010a788f4b3,目前正在等待更新代币logo。

此前报道,bZx团队决定将分配给众筹所用的代币置于一个为期4年的锁定合约,最短生效期(cliff)为6个月,BZRX代币释放的时间为美东时间7月13日10时,即北京时间7月13日22时开始计算。不过,目前团队并没有公布更多信息,包括可购买该代币的交易平台以及代币价格等。[2020/7/12]

第二步:拉升 sUSD

首先,我们介绍一下今天攻击者的最佳配角:sUSD,sUSD 是由 Synthetix 项目方发行的稳定币,其币价正常情况下与 1 美元持平,总发行量为 5,563,037 枚(统计于 2020年02月18日)。

声音 | Compound 创始人:bZx平台应该立刻关闭业务:以太坊去中心化借贷协议Compound创始人Robert Leshner表示,bZx团队最近的表现已经多次证明他们并不能保管好用户的资产,他们应该立刻暂停业务,好好审核一下平台。 据此前消息,bZx平台已经出现第二起闪电贷Flash Loan攻击事件,攻击者获利2,388个 ETH,约合64万美金。(The Block Crypto)[2020/2/18]

通过第一步闪贷获得 ETH 后,攻击者分两批共 900 ETH 通过 KyberNetwork DEX 换取成 sUSD。其中第一次 使用 540 ETH 换取,(KyberNetwork 内部查询得到 KyberUniswap 的价格是最优的)攻击者得到 92,419 枚 sUSD;第二批分 18 次,每次 20 ETH 换取,(KyberNetwork 查询之后确认 Kyber-sUSD 的价格是最合适的),攻击者获得 63,584 枚 sUSD,总共获得了 156,003 枚 sUSD。 

动态 | bZx再次暂停贷款协议 官方称不会影响Synthetix系统:去中心化金融(DeFi)贷款协议bZx官方刚刚发布消息称,鉴于使用快速贷款和在Synthetix上进行的可疑交易,bZx再次点击了协议上的暂停按钮。尽管确实涉及sUSD,但它不会影响Synthetix系统。今日早间消息,经历被操纵导致以太坊损失后,bZx表示已部署合同升级,使系统提升对抗攻击的抵抗力。此外,Synthetix官方早间发布消息称,将于本周升级数项协议,期间无法进行SNX转账。[2020/2/18]

Figure2: Pumping With Kyber (and Uniswap)

这两步骤也是正常的 DEX 币币交换的过程,在这两个批次操作之后 sUSD 对 ETH 的价格疯涨到了 0.00899,是市场价的 2.5 倍。

在这一步之后,使得 sUSD 价格被抬高了 1.5 倍,攻击者手里的资产还是正常与 KyberNetwork 交互,并没有实质性的攻击发生。然而,KybrNetwork 内部通过 Uniswap 完成 sUSD 与 ETH 转换,这使得那些将 Uniswap 作为 sUSD/ETH Oracle 的其它平台(比如说 bZx)误认为当前 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 各环节产品设计有深入研究的团队做一次完整的安全审计,以避免潜在存在的安全隐患。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

水星链

[0:46ms0-0:961ms