Avalanche 生态借贷项目 Vee Finance 因「杠杆借贷」功能不完善而遭价格操纵攻击,损失或超过 3500 万美元。本次攻击原理与 2020 年初发生的 bZx 安全事件第一次攻击原理非常相似。
北京时间 2021 年 9 月 21 日,Avalanche 链上的借贷项目 Vee Finance 的合约遭受攻击,造成数千万美金的损失(8804.7ETH 和 213.93 BTC)。
通过对相关合约和攻击交易的分析,我们发现这是一起由于该项目提供的「杠杆借贷」功能不完善导致的价格操纵攻击(即 price manipulation attack,我们的 论文 对此做了系统的阐述)。以下我们将对合约漏洞和攻击流程进行完整的分析。
相关背景简介
Vee Finance 是基于 Compound 的一个借贷项目,在 Compound 的基础上做了一些优化和功能更新。而此次被攻击的函数正是在这些新功能的一部分。
首先需要知道的是,Compound 是一个借贷平台,通过超额抵押进行借贷。Vee 在此基础上提供了一个和攻击有关的新功能:杠杆借贷。
超额借贷的意义在于,抵押价值 100 美元的 Ether 可以借出 80 美元的 USDC,当借贷者无法偿还的时候可以没收抵押物以偿还债务,而只要市场波动在一定范围内,抵押品的总价值一定大于贷出的价值,这样就避免了现实世界中借贷需要依赖信誉这个问题。
但是这样显然不够「刺激」。Vee 提供的杠杆借贷原理很简单:使用者可以指定杠杆倍数,假如杠杆为 3,那么抵押价值 100 美元的 Ether 可以借出 80*3=240 美元的 USDC。
当然,Vee 不会让用户直接拿走这笔钱(这样贷出价值就大于抵押品价值,用户可以直接违约),而是允许用户做一笔交易。
这个逻辑在合约的 borrowAndCall 函数中实现:

函数实现首先调用 borrowLeverageInternal 函数进行杠杆借贷,杠杆比率由参数 leverage 指定。然后调用 callOrderProxyInternal 执行用户指定的交易(Order)。
下面首先来看 borrowLeverageInternal (内部会调用逻辑实现 borrowFresh)的实现。大部分代码与 Compound 相同,只有处理 leverage 的时候存在不同:

当用户指定的杠杆为 0 时,执行正常的借贷逻辑,把资金直接转给借贷人;当存在杠杆时,将杠杆记录在状态变量中,然后调用 doDeposit 函数将资金转移到某个固定的位置(防止用户直接取走)。
需要注意的是,borrowLeverageInternal 的实现除了上述对 leverage 的处理之外,和原版 Compound 并没有任何不同。也就是说,对于这一笔杠杆借贷,系统只会记录单倍杠杆的借贷额。也就是说,虽然用户用 100 美元抵押借出了 240 美元,但系统记录的用户借款仍然只有 80 美元。
doDeposit 函数的实现很简单,将资金转入 orderProxy 合约中。

callOrderProxyInternal 函数的实现也很简单,就是将用户指定的 order 发给 orderProxy 进行执行。
总结一下:用户可以进行抵押借贷。当使用抵押借贷时,资金不会转给用户,而是转给 Vee 控制的 orderProxy 合约,后者会执行一个用户指定的订单。
漏洞成因分析
我们回顾一下一个正常的杠杆交易订单是怎样操作的:
假设我们拥有 1 个 Ether,想用杠杆来增加获利,Vee 正好提供了杠杆交易的功能。
我们抵押了 1 个 Ether,根据超额抵押原则,能借出 0.5 个 Ether;再加上三倍杠杆,总共可以借出 1.5 个 Ether。
但此时项目方不能把这些 Ether 转给我们,因为我们不能保证能够还得上。因此 Vee 将这些借款锁在一个代理(Proxy)合约中,由代理合约代为交易。
假设我们看好 LINK 代币,想用杠杆放大获利。假设此时市场价 1 LINK = 0.01 Ether。
为了(从我们对市场的观点)中获益,我们现在将 1.5 个 Ether 换为 150 个 LINK (第一笔交换),并让 Vee 帮我创建一个限价单,当 1 LINK = 0.02 Ether 时将所有的 LINK 换回 Ether (第二笔交换)。
这些功能正是 Vee 相对 Compound 的创新。
假设我们是正确的,一段时间后 LINK 的价格上涨。此时我们在 Vee 中的限价单执行,150 个 LINK 换到 3 个 Ether。订单完成,我们获利 1.5Ether。
假设我们是错误的,一段时间后 LINK 的价格下跌,Vee 会持续监控流动性情况,当可能产生资不抵债时,Vee 会主动将限价单取消并将所有的 LINK 卖出以清算我们的所有账户。
这个逻辑的正常执行基于以下条件:Vee 在杠杆交易开始时,必须立刻检查第一笔交换的资金是否具有相同价值(在去除正常的滑点等因素之后),并持续监控用户的流动性,在流动性不足时及时清算。在上述第 4 步中,1.5 个 Ether 和 150 个 LINK 的价值是基本等价的。否则,假设 150 个 LINK 的价值只有 0.5Ether,相当于 Vee 用 1.5 个 Ether 换到了价值只有 0.5 个 Ether 的代币,会导致项目方严重亏损。
然而,我们在仔细分析了 Vee 项目的代码之后,发现整个发起杠杆交易的 borrowAndCall 调用并没有对第一笔交换的价值进行判断。同样以上面的例子为例,在调用 borrowAndCall 时,由于交易对不平衡等因素,1.5 个 Ether 只换回了 50 个 LINK (价值只有 0.5 个 Ether)。此时 Vee 项目方应该检查这笔交换的价值,判定该调用失败:因为兑换的两种代币价值不对等,此时用户已经处于亏空状态,项目方已经受损。遗憾的是,由于缺乏检查,此次调用成功执行,此时项目方已经处于无法挽回的亏损状态。
按道理来说,只要交易量足够大,不平衡的交易对会由于套利等因素逐渐平衡。对于正常的 Pangolin 交易池来说也是如此,小额交易只会产生少量滑点,因此代理合约使用用户的借出额进行交易,确实是将资金池内的某种代币换成了价值相等的另一种代币。
然而我们发现,作为 Vee 官方支持的 LINK 代币,在其依赖的 Pangolin 交易池中竟然没有交易对! Pangolin 项目的代码和 Uniswap 基本一致,相同的代币对只能创建一个资金池,而攻击者利用的 ETH-LINK 资金池,正是由攻击者自行创建的。当然,即使攻击者没有创建恶意的不平衡交易对,也可以用 Flash Loan 的方式使交易对不平衡。
综上,可以推断出下面的攻击流程:
创造一个不平衡的交易对并在 Pangolin 上注册。举例来说,创造一个用 1 个 LINK 就可以换出 100 个 Ether 的交易对 P。
调用 borrowAndCall,加上杠杆,借出大量的 Ether。指定的订单内容是在交易对 P 上将 Ether 换成 LINK。
订单执行,交易对 P 中多了很多借出来的 Ether,还给 Vee 的代理合约的只是非常少量的 LINK。至此,攻击者成功地「套」出了 Vee 的 Ether。
在交易对 P 上进行交易,用少量 USDT 换出前一步中套出的 Ether,获得大量获利。
总结来说,对于杠杆交易的实现,项目方应当在杠杆交易的开始就检查第一笔交换的前后价值,如果严重不对等,此时用户的流动性已经出现亏空,则应该直接使调用失败,避免进一步的损失。
攻击交易分析
以下,我们将以攻击交易
0x4fb222908bd87cda0336776a6d78d35ef77b0a4bad866c4530b9f0d2616af005
为例介绍攻击的主要流程。如图所示(图中省略了一些影响不大的合约调用)。

图中步骤 1,攻击合约一先为攻击合约二往 VeeFinance 的 cToken 地址(合约名称为 CErc20Immutable)存入了约 0.96WETH,从而使得合约二可以进行抵押借贷(可以借出约 0.52WETH)及杠杆交易。
图中步骤 2,合约一通过创建合约二的方式绕过了 isContract() 对 msg.sender 的检查,并在 constructor() 函数中进行攻击调用。
图中步骤 3~5,合约二调用 CErc20Immutable 的 borrowAndCall() 函数,正如前面代码分析的,该函数在设置 leverage 倍数之后将进行杠杆交易,通过调用 VeeProxyController 去 Pangolin (类似于 UniswapV2)的池子中进行交易。注意,该池子是攻击者在攻击之前创建的交易对,所以池子的滑点受到攻击者的控制,导致 VeeFinance 的合约用加了杠杆后的约 1.55 个 WETH 只换回了约 0.27 个 LINK,造成了大量亏损。
图中步骤 6~8,合约二还上借贷,取出图中 1 的抵押物并 transfer 给合约一。前面代码分析中指出,虽然攻击者通过抵押杠杆进行了远超抵押额的亏本交易,但是系统记录的用户借款却仍然只有加了杠杆之前的借贷量。因此合约二仅需还上约 0.52 的 WETH,就能取出图中 1 存入的 0.96WETH。
图中步骤 9,合约一以少量(约 0.27 个) LINK 换出了约 1.55 个 WETH,从而获得了步骤 6~8 中 Vee 合约的亏损,从而攻击获利。
在我们分析的这笔交易中,攻击者这样的操作共进行了 5 次。而通过反复利用漏洞连续攻击,攻击者的最终获利颇为可观。
总结
针对 DeFi 项目的攻击已出现多次,不断地给项目方和投资者带来严重的损失。值得注意的是,本次攻击的原理与 2020 年初发生的 bZx 安全事件第一次攻击的原理非常相似。而相似的攻击不断重复表明,过往的经验和教训尚未得到应有的重视,DeFi 安全还有很长的路要走。

发表评论 已发布 0

还可以输入 800 个字
 
 
评论 打印