The smart contract contains a critical vulnerability in the calculateMinimumAmountOut
function, which is used to determine the minimum acceptable amount of output tokens in a swap transaction.
This vulnerability, when combined with the collateral check logic, can lead to every swap being susceptible to sandwich attacks by MEV bots.
The core issue lies in the logic used to calculate minimumAmountOut
in the calculateMinimumAmountOut
function.
The function returns zero as the minimum amount of output tokens if the post-swap collateral value is deemed sufficient (i.e., collateralValueMinusSwapValue >= requiredCollateralValue).
With or without minting collateral a allowed test will always be potentially attacked by an MEV bot as minimumAmountOut
will always be 0.
While this might appear to be a measure to allow swaps that don't jeopardize the collateral's health, it inadvertently exposes every allowed swap to potential sandwich attacks.
In a sandwich attack, an MEV bot can observe a pending swap transaction with zero slippage protection (as minimumAmountOut is set to zero).
The bot can then execute trades that manipulate the market price, leading to the initial swap transaction being executed at a highly unfavorable rate. After the victim's swap is executed, the attacker reverses their trade to profit from the artificially created price slippage.
We can verify the minimumAmountOut by running this POC.
To be able to run the test in this finding follow the following recommendation
Follow the following tutorial to install foundry in your local repo
https://hardhat.org/hardhat-runner/docs/advanced/hardhat-and-foundry
When hardhat-foundry
is installed, rename the current test folder to hardhat_test
so forge won't look at it.
Create/Update the foundry.toml fil with the current setup, to allow compilation with viaIR
Create a new test
folder, with the following file test contract in it, this contract deploy the whole contract stack.
The smartVaultManager is deployed with the proxy.
NFTMetadataGenerator is replaced by a Dummy address to lower the compilation time.
2 helpers are used in all the pocs:
_deployVault: Used to deploy the user Vault and retrieve the vault address
_send: Is used to send ETH
First add console2.log to the SmartVaultV3
contract:
Then add the following log in the swap method:
Now add the following test to your test file and run forge t --mt 'testSwapIssue' -vvvvvv
Logs
If the pair chosen have a low liquidity, the user could end loosing 0.99999999 BTC.
This vulnerability can lead to substantial financial losses for users initiating swap transactions. In a sandwich attack scenario, the user's transaction is executed at a manipulated and unfavorable rate, resulting in the loss of asset value. Since every swap allowed by the collateral check is susceptible, the overall integrity and trust in the smart contract are severely compromised.
Manual code analysis.
To mitigate this vulnerability, the following steps should be considered:
Implement Slippage Protection: Modify the calculateMinimumAmountOut function to include a realistic and protective slippage threshold for every swap. This involves setting a nonzero minimumAmountOut that reflects acceptable market conditions and slippage rates.
Dynamic Slippage Calculation: Introduce a dynamic mechanism to calculate minimumAmountOut based on current liquidity conditions, token volatility, and other market factors.
MEV Protection Strategies: Explore and implement advanced strategies to protect against MEV, such as transaction bundling or using MEV-resistant DeFi protocols like cowSwap.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.