Full Report
Vee Finance is a lending protocol that is mainly forked from Compound Protocol but adds a little bit more functionality. Slippage is the cost between attempted buying price and the real buying price. Veefi attempts to validate the slippage but failed at this. When doing the trading, it uses the Pangolin Price Oracle. If the number of TokenB tokens that can be exchanged in the pool is greater than or equal to the expected number of TokenB that can be exchanged using the oracle, then it can be judged that the pool price is correct and not controlled. The slippage check had a validation flaw in the handling of ERC20 tokens. When doing the comparisons for slippage, it did NOT take into consideration the decimals of a token. Because of this, the actual value and the slippage check are WAYYY different, allowing for oracle manipulation. This directly caused the contract to obtain the wrong price from the oracle during the slippage check, which caused the slippage check to be bypassed. This allowed for transactions that should have been rejected to be accepted from oracle manipulation attacks, losing 34 million from the protocol. Price Oracle manipulation is an extremely complicated attack that is becoming more and more relevant. To stop this attack, the authors removed functionality from specific classes of tokens.
Analysis Summary
# Incident Report: Vee Finance Oracle Manipulation and Loss
## Executive Summary
On September 20, 2021, the DeFi lending protocol Vee Finance suffered a significant loss of $34 million due to an oracle manipulation attack leveraged by a critical vulnerability in their slippage validation logic, specifically related to ERC20 token decimal handling. The flaw allowed attackers to bypass expected security checks and execute unauthorized leveraged trades against manipulated pool prices. The response involved removing problematic functionality and implementing stricter controls, including whitelisting and uniform decimal processing.
## Incident Details
- **Discovery Date:** September 20, 2021 (Inferred from attack date)
- **Incident Date:** September 20, 2021
- **Affected Organization:** Vee Finance
- **Sector:** Decentralized Finance (DeFi) / Lending Protocol
- **Geography:** Avalanche Ecosystem (Inferred)
## Timeline of Events
### Initial Access
- **Date/Time:** September 20, 2021 (Inferred start)
- **Vector:** Oracle Manipulation via Flash Loan or Price Impact (Inferred)
- **Details:** The attacker manipulated the token reserves in the *Pangolin* liquidity pool, triggering the Vee Finance Price Oracle mechanism to refresh based on a pre-defined 3% fluctuation threshold.
### Lateral Movement
- Attackers executed transactions via the `createOrderERC20ToERC20` function within the `VeeProxyController` contract, utilizing the compromised oracle pricing to proceed with leveraging trades.
### Data Exfiltration/Impact
- **Impact:** The attacker successfully executed leveraged trades that should have been blocked by the slippage check. The protocol ultimately lost $34 million in contract funds.
### Detection & Response
- **Detection:** Attack transactions were observed on-chain, revealing the bypass of the slippage check.
- **Response Actions:** The development team investigated and confirmed the validation flaw regarding token decimals. Remediation steps involved code fixes, including removing functionality related to specific token classes, restricting trading pairs via whitelisting, and ensuring uniform decimal handling for oracle prices.
## Attack Methodology
- **Initial Access:** Attacker manipulated external dependency (Pangolin pool reserves) to force an oracle price refresh.
- **Persistence:** Not applicable (Smart contract exploit).
- **Privilege Escalation:** Not applicable.
- **Defense Evasion:** The core defense mechanism—the slippage check in `getAmountOutMin`—was evaded because the calculation did not account for the differing decimals between exchanged tokens (TokenA vs TokenB). This resulted in an artificially low calculated expected output (`amountFromOracle`), causing the comparison against the actual pool amount to pass validation when it should have failed.
- **Credential Access:** Not applicable (No traditional credentials involved).
- **Discovery:** Not applicable (Exploitation of known mathematical flaw).
- **Lateral Movement:** Execution of unauthorized token swaps/trades through recursive contract calls initiated by the flawed slippage check bypass.
- **Collection:** Not applicable.
- **Exfiltration:** Stealing protocol funds via exploiting the unchecked leveraged trading mechanism.
- **Impact:** Financial loss of $34 million.
## Impact Assessment
- **Financial:** $34 million lost from the protocol's contracts.
- **Data Breach:** None (No PII or customer data compromised, but protocol assets were drained).
- **Operational:** Severe short-term disruption requiring immediate patching and emergency controls implementation.
- **Reputational:** Significant negative impact, highlighting critical security vulnerabilities relating to token standards and oracle integration.
## Indicators of Compromise
- **Network Indicators:** N/A (Blockchain transactions are public ledger events).
- **File Indicators:** N/A.
- **Behavioral Indicators:** Transactions repeatedly calling `createOrderERC20ToERC20` where the resulting swap amount severely deviated from the expected price relative to the pool without triggering the intended slippage rejection condition. Observing oracle prices being obtained where `priceA` and `priceB` were suspiciously equal despite differing token values.
## Response Actions
- **Containment Measures:** Immediate investigation into the faulty comparison logic within the slippage check.
- **Eradication Steps:** Implemented fixes to ensure uniform decimal processing for all tokens when calculating oracle-derived amounts. Addressed flaws in contract call checking (`require(msg.sender == tx.origin)` modification).
- **Recovery Actions:** Implemented whitelisting for target margin trading pairs and for oracle price feeding permissions to restrict malicious actions moving forward. Removed functionality tied to classes of tokens that were susceptible due to single-source price feeds.
## Lessons Learned
- **Key Takeaways:** Relying on external price oracles derived from a single source (Pangolin pool) introduces concentration risk, especially if pool manipulation can trigger price updates. Failure to properly normalize token standards (specifically handling ERC20 decimals) during mathematical comparisons renders critical security checks useless.
- **What could have been done better:** The slippage check validation should have incorporated comprehensive token metadata verification, including decimal normalization, before performing comparisons against potential exchange amounts. Margin trading pairs should have been restricted from the outset.
## Recommendations
- Implement robust, multi-source price feeding oracles that utilize time- and reserve-weighted averages rather than simple lookups susceptible to single-pool manipulation.
- Mandate that all calculations involving token quantities or prices that cross different token types must first normalize these values based on their standardized decimal representations.
- Enforce strict whitelisting for all sensitive operations, including which trading assets are allowed for margin trading and which addresses are permitted to update oracle prices.