前言

2021 年 12 月 31 日，Vesper Finance 说自己又被黑了，但是这次被黑的是自己5个月前发布的 beta 版本的合约。然后说了一大堆，最后还说这是因为是预言机的问题。那么既然是预言机的问题，那问题就大概清楚了，无非是价格操纵三件套–深度低、闪电贷、喂价地址私钥泄漏导致被操控。接下来看看具体是什么原因。

技术分析

本次的攻击交易为 https://etherscan.io/tx/0xc116526aad6e66c2729133a1caf4d195bcd9335726cce7ab64fcb0d092bb46c2 我们把交易放到 ethtx.info 中看看是什么问题

通过查看交易内的信息，不难发现这是一次没有任何闪电贷痕迹的的一次攻击，那么根据刚才的三件套理论，剩下的可能无非是深度低和喂价地址的私钥泄漏问题了。而 Vesper 采用的是 Compound 的架构，在这个架构里面，如果是预言机被黑的话，用到预言机的模块就只有借贷模块，那么如果是借贷模块的话，肯定就是因为价格过高导致的少量抵押品借出大量资产的问题，类似的案例有很多，我都不记得了，所以这里就不列举了 😀

既然吗定位到了是借贷模块的问题，我们就需要去看借贷过程中的价格获取，看看是否是异常的

通过查看在借贷过程种的价格，是一个16进制的数字 0xb2ab602f204d254b529fc3d8，转换过来就是 55295512279860408360034616280 可见这是一个非常大的价格，这个价格是很明显可以借空项目资产是没什么问题的。那这个异常的价格不是闪电贷造成的，会是什么原因呢？我们深入 MasterPriceOracle 合约中的  getUnderlyingPrice 中寻找答案

function getUnderlyingPrice(CToken cToken) external override view returns (uint) {
        // Get underlying ERC20 token address
        address underlying = address(CErc20(address(cToken)).underlying());

        // Return 1e18 for WETH
        if (underlying == 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) return 1e18;

        // Get underlying price from assigned oracle
        PriceOracle oracle = oracles[underlying];
        if (address(oracle) != address(0)) return oracle.getUnderlyingPrice(cToken);
        if (address(defaultOracle) != address(0)) return defaultOracle.getUnderlyingPrice(cToken);
        revert("Price oracle not found for this underlying token address.");
    }

通过观察代码来看，这边获取价格，是通过 oracle 合约来获取价格的，那么有没有可能是对应 oracle 的喂价地址私钥泄漏呢？我们需要深入对应的 oracle (0x29490a6f5b4a999601378547fe681d04d877d29b)代码

通过查看代码，发现这是一个用于计算 UniswapV3 延时价格的合约，然后看函数实现也是通过 V3 池本身的价格来作为主要逻辑的。所以，是不可能存在私钥泄漏的问题的，那么剩下的唯一种可能，就是池本身的深度太低了为了验证这个想法，我们需要看对应的V3(0x8dde0a1481b4a14bc1015a5a8b260ef059e9fd89)池，看看深度情况。

看了这个深度，还有这个比例之后，懂得都懂了，怎么可能会没问题 😀

总结

目前看来，这次攻击者并没有采用很高端的操作，仅仅是因为 Vesper beta 池的 VUSD 深度实在是太低了，导致攻击者直接通过 Miner 合约获得 VUSD 后就一路高歌，满载而归，在我看来，也算是套利吧。。。但钱是真没了。。

原文始发于微信公众号（蛋蛋的区块链笔记）：是被黑，也不是被黑 — Vesper Finance 被黑分析