01.DEFI ATTACKS - Kein Slippage Parameter

Slippage bezieht sich auf den Preisunterschied zwischen dem Zeitpunkt, an dem ein Marktteilnehmer einen DeFi-Tauschhandel einreicht, und dem tatsächlichen Preis, wenn der Handel ausgeführt wird. Dieser Unterschied ist normalerweise vernachlässigbar, kann jedoch in Zeiten hoher Volatilität und bei Tokens mit geringer Liquidität erheblich sein. Slippage kann dazu führen, dass der Benutzer mehr oder (häufig) weniger Tokens erhält, als er erhalten hätte, wenn der Handel sofort abgewickelt worden wäre.

DeFi-Plattformen sollten den Benutzern die Möglichkeit geben, einen Slippage-Parameter "minTokensOut" festzulegen – also die Mindestanzahl an ausgegebenen Tokens, die vom Tausch erhalten werden sollen. Der Tausch wird zurückgesetzt, wenn die vom Benutzer angegebene Mindestanzahl an Tokens nicht erreicht wird. Es gibt mehrere häufige Implementierungsfehler in DeFi-Systemen, auf die Entwickler und Prüfer achten sollten.

Kein Slippage-Parameter
DeFi-Plattformen müssen den Nutzern die Möglichkeit bieten, einen Slippage-Parameter festzulegen: die Mindestanzahl an Tokens, die sie von einem Swap zurückerhalten möchten. Prüfer sollten immer auf Swaps achten, bei denen der Slippage-Wert auf 0 gesetzt ist.

// 1. Beispiel:
IUniswapRouterV2(SUSHI_ROUTER).swapExactTokensForTokens(
    toSwap,
    0, // @audit min return 0 tokens; no slippage => user loss of funds
    path,
    address(this),
    now
);

//2. Beispiel: 
function _swapLidoForWETH(uint256 amountToSwap) internal {
    IUniswapSwapRouter.ExactInputSingleParams
        memory params = IUniswapSwapRouter.ExactInputSingleParams({
            tokenIn: address(ldo),
            tokenOut: address(weth),
            fee: UNISWAP_FEE,
            recipient: address(this),
            deadline: block.timestamp,
            amountIn: amountToSwap,
            amountOutMinimum: 0,
            sqrtPriceLimitX96: 0
        });
    uniswapRouter.exactInputSingle(params);
}

Dieser Code gibt an, dass der Benutzer bereit ist, eine Mindestmenge von 0 Tokens aus dem Swap zu akzeptieren, was den Benutzer einem katastrophalen Verlust von Mitteln durch MEV-Bot-Sandwich-Angriffe aussetzt. Plattformen sollten auch einen sinnvollen Standardwert festlegen, falls der Benutzer keinen Wert angibt. Benutzerdefinierte Slippage-Parameter müssen jedoch immer die Standardeinstellungen der Plattform überschreiben.

Weitere Beispiele:
1 - [H-07] RubiconRouter.swapEntireBalance() doesn’t handle the slippage check properly,
2 - [H-31] Unused slippage params,
3,
4 - [H-12] feePool is vulnerable to sandwich attack.,
5 - [H-07] Missing slippage checks,
6 - MainVault.rebalanceXChain doesn't check that savedTotalUnderlying,
7 - Withdrawals from IchiVaultSpell have no slippage protection,
8,
9 - rebalanceLite should provide a slippage protection,
10,
11,
12,
13 - [M-04] YearnTokenAdapter allows a maximum loss of 100% when withdrawing,
14 - [M-20] In reimburseLiquidityFees() of SponserVault contract swaps tokens without slippage limit so its possible to perform sandwich attack and it create MEV,
15 - [M-01] _harvest has no slippage protection when swapping auraBAL for AURA,
16 - [M-12] Sandwich attacks are possible as there is no slippage control option in Marketplace and in Lender yield swaps,
17 - [M-01] VaderPoolV2.mintFungible exposes users to unlimited slippage,
18 - [M-02] sNOTE.sol#_mintFromAssets() Lack of slippage control,
19 - [M-14] UniswapHelper.buyFlanAndBurn is a subject to sandwich attacks,
20 - [M-04] CvxCrvRewardsLocker implements a swap without a slippage check that can result in a loss of funds through MEV,
21 - 5.5 Harvester.harvest swaps have no slippage parameters,
22 - [M-02] regerralFeePool is vulnerable to MEV searcher,
23,
24,
25 - [M-05] No slippage control on deposit of IbbtcVaultZap.sol,
26 - [M-01] Improper implementation of slippage check,
27 - [M-02] Frontrunning in UniswapHandler calls to UniswapV2Router,
28,
29 - 0x52 - ConvexSpell#closePositionFarm removes liquidity without any slippage protection,
30 - User-supplied slippage for decrease orders is ignored,
31 - Collateral tokens that cannot be automatically swapped to the PnL token, cannot have slippage applied to them,
32 - Slippage is not respected if PnL swap associated with a decrease order fails.