Home Web3 SecurityCrypto Hacks & Exploits Vee Finance Exploit—Sep 21, 2021—Detailed Analysis

Vee Finance Exploit—Sep 21, 2021—Detailed Analysis

by ImmuneBytes
Vee Finance Exploit—Sep 21, 2021—Detailed Analysis

Overview

Vee Finance, a decentralized finance platform operating on the Avalanche blockchain, was exploited on September 21, 2021, resulting in a significant loss of funds. The attack led to the theft of assets totaling approximately $35 million, comprising 8804.7 ETH and 213.93 BTC. This incident is notable for its substantial impact on the platform and its users, highlighting the vulnerabilities inherent in DeFi protocols.

About Vee Finance

Vee Finance is a DeFi lending protocol, primarily a fork from the Compound Protocol, with added functionalities for leveraged trading.

Launched on the Avalanche network, it enables users to leverage mortgage assets to obtain loan vouchers for trading. Before the attack, Vee Finance boasted a total value locked (TVL) surpassing $300 million.

The platform’s design allows users to borrow funds for trading by creating orders through the VeeProxyController contract, with the swaps executed in the Pangolin pool. However, This innovative approach also exposed the platform to vulnerabilities exploited in the hack.

Root Cause of the Hack

The root cause of the Vee Finance hack can be attributed to several critical vulnerabilities in their DeFi platform, specifically in the design and implementation of their Oracle machine and price feed mechanism.

Core Vulnerability: Oracle Machine’s Dependency on Pangolin Pool

Single Source of Price Feed

The oracle machine, a crucial component for determining the price feeds in the Vee Finance platform, was configured to rely solely on the price of the Pangolin pool. This design decision made the entire system susceptible to price manipulation.

The oracle refreshed its price feed when there was a more than 3% fluctuation in the Pangolin pool’s price. This threshold was exploitable, as it provided a clear target for attackers looking to manipulate the price feed.

Decimals Processing Flaw

Another significant issue was the lack of proper decimals processing in the price acquisition function. When the Oracle fetched prices, the decimal places were not appropriately handled, leading to calculation errors.

This flaw was particularly problematic when dealing with tokens having a significant difference in decimal places.

Oracle Machine’s Price Refresh Mechanism

The reliance on the Pangolin pool’s price as the sole trigger for refreshing the oracle’s price feed created a single point of failure. Attackers could manipulate the Pangolin pool’s token balance to induce a more than 3% price fluctuation, thereby triggering the oracle to refresh and present an inaccurate price.

Lack of Contract Call Checks

Vee Finance’s system lacked robust checks on contract calls, allowing the exploiter to manipulate the system’s normal operational flow.

Absence of Whitelisting for Trading Pairs

The platform did not implement a whitelisting process for its margin trading pairs. This oversight meant that trading could occur with any pair, increasing the vulnerability to exploitation.

How the Exploit Was Executed?

Using these vulnerabilities, the attacker manipulated the number of tokens in the Pangolin pool, influencing the oracle machine to refresh the price with inaccurate data.

The lack of decimal precision in the price calculation allowed the attacker to bypass the expected slippage checks in the smart contract, facilitating the exploitation of funds.

Exploited Contract Address: 0xd1F855ceF146D36CC5851E2139c54524420797f2

Detailed Analysis of the Attack Mechanism

Overview of the Attack Mechanism

In this particular incident, the attacker skillfully exploited a vulnerability in the decimal processing and the reliance on a single source for the price feed from the Oracle machine.

This manipulation led to the bypassing of the contract’s slippage checks, a crucial component designed to ensure fair and secure transactions in margin trading.

Hacker Add:0xeeeE458C3a5eaAfcFd68681D405FB55Ef80595BA

In-Depth Breakdown of the Attack

1. Initial Trigger: Margin Trading Order Creation

Function Call: The createOrderERC20ToERC20 function is invoked for margin trading. This function is responsible for creating a new trading order.

Code Block Analysis:

 function createOrderERC20ToERC20(address orderOwner,CreateParams memory createParams) external veeLock(uint8(VeeLockState.LOCK_CREATE)) payable returns (bytes32 orderId){


address tokenA = CErc20Interface(createParams.ctokenA).underlying();


address tokenB = CErc20Interface(createParams.ctokenB).underlying();


commonCheck(orderOwner,createParams.stopHighPairPrice,createParams.stopLowPairPrice,createParams.amountA,createParams.expiryDate,createParams.leverage,createParams.ctokenA,tokenA,tokenB);


uint256[] memory amounts = swapERC20ToERC20(tokenA,tokenB,calcSwapAmount(createParams.amountA,createParams.leverage),getAmountOutMin(createParams));


orderId = onOrderCreate(orderOwner,createParams,amounts,tokenA,tokenB);

}
- The function takes in the order parameters and performs a series of checks and operations to create a margin trading order.
2. Token Exchange Process
  • Execution Line: The token exchange is executed at line 5 of the createOrderERC20ToERC20 function.
  • Core Functionality: This line is pivotal in the exchange of TokenA for TokenB, based on the parameters provided in the trading order.
3. Slippage Check Before Exchange
  • Function Implementation: The getAmountOutMin function, called at line 9, is responsible for determining the minimum acceptable amount of TokenB that can be received in exchange for TokenA.
  • Slippage Check Mechanism:
 function getAmountOutMin(CreateParams memory createParams) internal returns(uint256 amountOutMin) {

address tokenA = getUnderlying(createParams.ctokenA);

address tokenB = getUnderlying(createParams.ctokenB);

uint256 priceA = IPriceOracle(oracle).getUnderlyingPrice(createParams.ctokenA);

uint256 priceB = IPriceOracle(oracle).getUnderlyingPrice(createParams.ctokenB);

uint256 swapAmountA = calcSwapAmount(createParams.amountA,createParams.leverage);

uint256 amountFromOracle = priceA  swapAmountA / priceB;

uint256 amountOut = getAmountOut(tokenA,tokenB,swapAmountA);

amountOutMin = amountFromOracle  95 / 100;

bool isRightPrice = amountOut >= amountOutMin;

require(isRightPrice,”price error”);

}
- This function plays a crucial role in checking the expected slippage and ensuring the exchange rate is within acceptable limits.
4. Price Quotation and Calculation
  • Oracle Price Retrieval: At lines 12 and 13, the function retrieves the current prices (PriceA and PriceB) for the tokens from Oracle.
  • Exchange Calculation: Line 15 calculates the number of TokenA that can be exchanged for TokenB at the current Oracle prices.
  • Comparison with Pangolin Pool: The calculated amount is then compared with the actual number of tokens available in the Pangolin pool. This comparison is vital to verify that the pool price is accurate and not under the control of an attacker.
5. Issue with Decimal Processing
  • Decimal Discrepancy: The on-chain records revealed that the oracle price’s decimal processing was flawed. Particularly, if TokenB’s decimals significantly outnumber TokenA’s, the calculation of the expected exchangeable amount of TokenB becomes inaccurate.
  • Impact of Decimal Issue: The miscalculation leads to a lower-than-expected value for amountFromOracle = priceA swapAmountA / priceB.
6. Observations of Oracle Price Equalization in Attacks
  • Oracle Price Anomaly: In many instances of the attack, the prices of TokenA and TokenB obtained from the oracle were identical, indicating an incorrect price feed from the oracle.
7. Single Source Price Feed Vulnerability

Oracle Machine’s Price Feed Source: The project team confirmed that the Oracle machine’s price feed relied solely on the Pangolin pool’s price.

Price Feed Refresh Condition: A more than 3% fluctuation in the pool’s price triggers a refresh of the Oracle machine’s price.

8. Exploitation by the Attacker
  • Manipulation of Pangolin’s Token Numbers: The attacker manipulated the number of tokens in the Pangolin pool, influencing the Vee Finance oracle machine to refresh the price.
  • Bypassing Slippage Check: This manipulation led to the contract retrieving an incorrect price from the oracle during the slippage check, effectively bypassing this critical security measure.

Stolen Fund Details

The details of the stolen funds are as follows:

  • Amount and Composition: The attack resulted in the theft of 8804.7 ETH (approximately $26 million) and 213.93 BTC (around $9 million). This totaled over $35 million, marking a significant financial impact on the platform.
  • Location of Funds: After the attack, the stolen assets were consolidated in the attacker’s address. Vee Finance publicly highlighted this address, where the funds remained at the time of the report.
  • Stability of Other Assets: It was noted that the stablecoin section of Vee Finance was not affected by this attack. Thus, assets like USDT.e, USDC.e, and DAI.e holdings remained secure.

Hack Aftermath

The aftermath of the Vee Finance hack had several significant implications:

  • Immediate Response: In response to the attack, Vee Finance suspended all its services to protect the safety of its users’ assets. This was a preventive measure to curb further losses.
  • Impact on VEE Token: The platform’s native coin, VEE token, witnessed a drastic price decline. The value plummeted from over $0.25 to $0.085, as per data from CoinGecko. Although there was a slight recovery to nearly $0.11, the decline represented a significant loss of trust and value.
  • Collaborative Recovery Efforts: The team behind Vee Finance engaged with contract auditors and various exchanges to assist in the recovery of the stolen assets. They were also working closely with code review agencies and trading platforms for this purpose.
  • Communication and Bounty Program: Following the incident, Vee Finance released a series of FAQs and official statements to address the concerns of their users and the public. Notably, they announced a bounty program, appealing to the attacker to return the stolen funds in exchange for a reward.

Similar Hacks in the DeFi Space

Comparing the Vee Finance hack to other recent incidents in the DeFi space:

Zabu Finance Hack: Earlier in that month, Zabu Finance, another Avalanche-based DeFi protocol, was exploited for $3.2 million. This was considered the first significant exploit on the Avalanche blockchain.

pNetwork Exploit: Around the same period, pNetwork, a multi-chain bridging protocol, suffered a hack resulting in the theft of 277 Bitcoin (worth approximately $12 million). In response, pNetwork offered a bounty for the return of the stolen assets, reminiscent of the strategy used by Poly Network.

Poly Network Incident: This hack was notable for being the largest DeFi hack in history at that time, with over $600 million in cryptocurrencies stolen. The Poly Network offered a bounty and even a job to the hacker for the return of the assets, which were eventually returned along with the paid bounty.

Comparison with Vee Finance

Like these incidents, Vee Finance faced a substantial financial loss and responded with a suspension of services, a bounty program, and collaborative efforts for recovery. However, the unique aspect of Vee Finance’s situation was its recent mainnet launch on Avalanche and the significant value locked in its platform, which had surpassed $300 million.

Mitigation Steps to Avoid Such Hacks

The Vee Finance hack offers several critical lessons and highlights the importance of robust security measures in DeFi platforms. Based on the insights gained from this incident, the following mitigation steps are recommended to prevent similar vulnerabilities and enhance overall security:

  1. Uniform Decimal Processing for Oracle Prices
    Issue Identified: In the Vee Finance hack, one of the primary issues was the improper handling of decimal places when the oracle machine obtained token prices.
    Solution: Implement a uniform approach to decimal processing after the oracle fetches token prices. This ensures that calculations involving different tokens are accurate and consistent, regardless of the number of decimal places in each token.
  2. Diversifying Price Feed Sources for Tokens
    Issue Identified: Relying on a single source for Oracle’s price feed created a significant vulnerability.
    Solution: Avoid using tokens that rely on a single source for their price feed. Implementing a multi-source approach for price feeds can provide a more robust and tamper-resistant mechanism, reducing the risk of price manipulation.
  3. Enhanced Contract Call Checks
    Issue Identified: The lack of stringent checks on contract calls allowed the attacker to exploit the system.
    Solution: Modify the contract call checks to include conditions like require(msg.sender == tx.origin). This helps distinguish between direct interactions (from EOAs) and contract-based calls, adding an extra layer of security against certain types of exploits.
  4. Whitelisting for Margin Trading Pairs
    Issue Identified: The absence of restrictions on margin trading pairs contributed to the exploit.
    Solution: Implement whitelisting restrictions for margin trading pairs. This ensures that only vetted and secure token pairs are used in trading operations, reducing the likelihood of exploitation through lesser-known or less secure tokens.
  5. Restricted Oracle Price Feeding Permissions
    Issue Identified: The oracle’s unrestricted access to price feeds was a critical flaw.
    Solution: Enforce whitelisting restrictions on Oracle price feeding permissions. By controlling which sources the oracle can access for price information, platforms can significantly reduce the risk of oracle manipulation.

Conclusion

The attack was orchestrated by exploiting a decimal processing flaw and the vulnerability arising from relying on a single source for the Oracle machine’s price feed.

By manipulating the Pangolin pool’s token numbers, the attacker could deceive the system into accepting an incorrect price, bypassing the slippage check and compromising the integrity of the margin trading operation.

The Vee Finance hack underlines the importance of robust oracle mechanisms and contract security in DeFi platforms. Preventative measures and diligent monitoring are key to averting such exploits. ImmuneBytes specializes in blockchain security and smart contract audit solutions, which could provide essential audit services to identify and mitigate such vulnerabilities in blockchain projects.

You may also like