Flash-Loan Oracle Manipulations
PreviousNewly Registered Assets Skew Consultation ResultsNextRelying Only On Chainlink: PriceOracle Does Not Filter Price Feed Outliers
Last updated
Last updated
Triggering an update to the price feed is accessible to anyone through the PriceAware.getCurrentPriceInPeg(token, inAmount, forceCurBlock=true) call. When the update window elapses, price computation is carried out by executing a simulation of a trade akin to those occurring on Uniswap, employing the specified amounts.
However, it’s crucial to note that the reserves of Uniswap pairs, which are instrumental in this simulation, are susceptible to substantial modifications through flash loans. Such alterations can generate almost arbitrary output amounts and, consequently, prices, due to the volatile nature of these reserves.
Incorrect pricing fundamentally undermines the contract’s core operations, including but not limited to margin borrowing and liquidations.
Refrain from relying on Uniswap’s spot price as a reflection of the actual price. Even Uniswap advises against this practice due to its inherent risk and unreliability.
As an alternative, consider implementing a Time-Weighted Average Price (TWAP) oracle. This approach, recommended by Uniswap, utilizes the price*CumulativeLast variables to yield more accurate and dependable pricing data, minimizing the risk associated with price inaccuracies and providing a more stable foundation for contract functionalities.
This vulnerability could lead to a significant loss of funds from VaderPool.
Refer to the VaderPool.mintSynth function through the following link: .
The pool's reserves, similar to those in UniswapV2, are susceptible to manipulation via flash loans. A malicious actor might exploit this vulnerability, adjusting the exchange rate between the nativeAsset and synths (determined based on the reserves) to their advantage, subsequently draining funds from VaderPool.
Initiate Flash Loan & Sell: The attacker initiates a flash loan and sells a substantial amount of foreignAsset to VaderPool, making the pool perceive nativeAsset as highly valuable.
Mint Synths: Using a relatively small amount of nativeAsset, the attacker mints an excessive amount of synths through VaderPool.mintSynth, exploiting the pool's inflated valuation of nativeAsset.
Manipulate Exchange Rate: The attacker repurchases the foreignAsset previously sold, either restoring its price to normal levels or further depreciating it, depending on their strategy.
Burn Synths: When the attacker burns the synths, the devalued nativeAsset is required in larger quantities to compensate for the burned synths, allowing the attacker to extract significant amounts of nativeAsset from the pool at a low cost.
For the expense of a flash loan and swap fees, the attacker could repeatedly execute this process as long as it remains profitable, extracting considerable funds from VaderPool each time.
The _calculateMaltRequiredForExit function within AuctionEscapeHatch presently relies on the spot price of Malt to determine the amount to be returned to a user initiating an exit. However, this spot price is inherently insecure as it merely mirrors the reserves of the Uniswap pool. Given this design, it's vulnerable to manipulation through flash loan attacks, which can be executed to illegitimately siphon funds from the protocol. These attacks exploit the reliance on spot prices, allowing malicious actors to extract value with ease, thereby undermining the integrity and financial stability of the protocol.
Impact
This vulnerability allows malicious actors to extract and distribute all rewardToken from a specific AMM pool as LP rewards.
Proof of Concept
Attack Sequence:
Monitor Price: The attacker waits until the TWAP rises above the stabilization threshold.
Manipulate Pool: Using a flash loan, the attacker removes all but a minimal amount of Malt from the pool.
Trigger Stabilization: A call to stabilize is made. Given the low pool amount, _distributeSupply function determines that a large portion of rewardToken must be extracted to rebalance the price.
Mint and Distribute: Malt is minted to facilitate the removal of a significant amount of rewardToken, which is then distributed as rewards. While the attacker directly receives a small fraction (0.3%), the remaining amount is distributed as LP rewards, causing disruption and confusion within the protocol.
Although the amount directly siphoned off by an attacker might be limited, the overall impact on the protocol is significant and detrimental, creating chaos in the pool and confusion regarding the reward distributions.
Mitigation Recommendations
TWAP Implementation: To calculate trade size, implement a short period TWAP instead of directly interacting with the pool, mitigating the risk of flash loan attacks.
The burnAsset function within LimboDAO's LP pricing formula is exposed to potential exploitation due to its vulnerability to flash loan manipulations. Specifically, a threat actor can maliciously inflate the value of LP tokens by injecting a substantial number of EYE tokens into the underlying pool. This action allows the attacker to acquire more Fate tokens than legitimately entitled, at a minimal cost.
This disproportionate acquisition of Fate tokens not only provides the attacker with amplified voting power, facilitating undue influence over system decisions, but also offers an opportunity for direct financial gain. The attacker can conveniently convert the illegitimately obtained Fate tokens into Flan tokens, generating immediate profits while compromising the system's integrity and fairness.
Within the StabilizerNode contract, the stabilize method initially uses a short period Time-Weighted Average Price (TWAP) to check if Malt's price requires stabilization.
However, there's a catch: If the price is above the stabilization threshold, the calculation of the trade size required for stabilization is done directly through the AMM pool, which is susceptible to flash loan manipulation.