北京时间2021年9月21日，Avalanche链上的贷款项目Vee Finance的合同遭到攻击，损失数千万美元(8804.7ETH和213.93 BTC )。
分析了关联合同和攻击交易，发现这是由于该项目提供的“杠杆”功能不健全而导致的价格操纵攻击(即价格管理攻击，本文对此进行了系统的说明)。 下文将对合同漏洞和攻击过程进行全面分析。
相关背景概述
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函数将资金移动到某个位置(防止用户直接获取)
需要注意的是，除了上述leverage处理之外，borrowLeverageInternal的实现与原始的Compound没有任何区别。 也就是说，对于这个杠杆作用，系统只记录杠杆作用两倍的贷款额。 也就是说，用户用100美元的抵押借了240美元，而系统记录的用户借款只有80美元。
doDeposit函数的实现很简单，就是将资金转入orderProxy合同。
callOrderProxyInternal函数的实现也很简单，就是将用户指定的订单发送到订单代理执行。
总结一下，用户可以进行抵押贷款。 使用住房贷款时，资金不会交给用户，而是交给执行用户指定订单的Vee管理的orderProxy合同。
脆弱性的原因分析
让我们回顾一下正常举债交易的订单是如何操作的。
如果我们有一个Ether，想通过杠杆化来增加利润，那么Vee正好提供了杠杆化交易的功能。
我们可以抵押一个Ether，根据超额抵押的原则，可以租0.5个Ether； 再加上杠杆3倍，总共可以租1.5个Ether。
但是，此时项目方不能把这些Ether交给我们。 因为我们还不能保证归还。 因此，Vee将这些借款困在代理合同中，由代理合同代理交易。
假设您看到了LINK令牌，想通过杠杆扩大利润。 此时，市场价格为1 LINK=0.01 Ether。
为了从“我们对市场的观点”中获益，我们现在将1.5个Ether更换为150个link (第一次更换)，请Vee制作价格限制列表，在1 LINK=0.02 Ether时，将所有的link都变更为enk 这些功能是Vee对Compound的创新。
假设我们是对的，过了一会儿，LINK的价格上涨了。 这时，我们在Vee的限价清单上运行，把150个LINK换成了3个Ether。 订单已完成。 我们得到了1.5Ether的利益。
假设我们错了，一段时间后，LINK的价格下跌后，Vee将继续监测流动性状况，如果有可能发生不履行债务，Vee将主动取消限价清单，抛售所有LINK清算我们的所有账户。
据悉，该逻辑的正常执行，应立即检查Vee在杠杆交易开始时，最初交换的资金是否具有相同价值(去除正常的转折点等因素后)，持续监测用户流动性，并在流动性不足时及时清算在上述步骤4中，1.5个Ether和150个LINK的价值大致等价。 否则，假设150个LINK的价值只有0.5个Ether，则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注册。 例如，用一个LINK制作可以交换100个Ether的交易对p。
呼叫borrowAndCall，加上杠杆，出借大量的Ether。 指定的订单内容是客户p将Ether更换为LINK。
执行订单，交易增加了很多向p借的Ether，只有非常少量的LINK返还了Vee的代理合同。 现在，攻击者成功地“嵌入”了Vee的Ether。
用交易对p进行交易，用少量的USDT交换上一步设定的Ether，得到大量的利益。
总结一下，对于杠杆交易的实现，项目方必须从杠杆交易开始时就检查第一次交换的前后价值。 如果发生了很大的错误等，此时用户的流动性已经出现赤字的情况下，应该直接使呼叫失败，避免进一步的损失。
攻击交易分析
以下以攻击交易0x4fb 222908 BD 87 CDA 0336776 A6D 78D 35E F77 B0A4Bad 866 C4530 B9 F0D 2616 AF 005为例介绍攻击的主要流程。 如图所示。 (图中省略了影响较小的合同呼叫。
在图中的步骤1中，攻击合同1首先为了攻击合同2，可以向VeeFinance的cToken地址(合同名称为CErc20Immutable )存入约0.96WETH，合同2为抵押贷款)借贷约0.52WETH
图中的步骤2，合同1通过制作合同2，省略isContract ()对msg.sender的检查，constructor ) )函数进行攻击调用。
图中的步骤3~5，合同2是CErc20Immutable的borrowAndCall (调用函数，如前面代码分析，该函数在设定leverage倍数后进行杠杆交易，然后进行VeeProxyController， 请注意，该池是攻击者在攻击前创建的交易对。 因此，池子的滑点受攻击者控制，VeeFinance的合同通过增加杠杆的约1.55个WETH返回约0.27个LINK，造成大量损失。
图中的步骤6~8，合同2又进行借贷，取出图中的1个抵押物，传递给合同1。 在上一个代码分析中，攻击者通过抵押杠杆进行了远远超过抵押额度的赤字交易，但他指出，系统记录的用户借款只有举债前的贷款量。 因此，在合同2中，只要返还约0.52的WETH，就可以取出图中1中存入的0.96WETH。
在图中的步骤9中，如果合同用少量(约0.27个)的LINK交换约1.55个WETH，则得到步骤6~8中的Vee合同的损失，攻击利益。
在我们分析的这笔交易中，攻击者的这种操作共进行了五次。 通过反复利用漏洞连续攻击，攻击者的最终利益相当大。
总结
对DeFi项目的攻击已经多次出现，不断给项目和投资者造成严重损失。 值得注意的是，这次攻击的原理与2020年初发生的bZx安全事件最初的攻击原理很相似。 同样的攻击一再发生，表明过去的经验和教训还没有得到重视，离德芙的安全还有很长的路要走。
关注微信
