Report #33929

Report ID

#33929

Report type

Smart Contract

Has PoC?

Yes

Target

https://etherscan.io/address/0xBA51AAAA95aeEFc1292515b36D86C51dC7877773

Impacts

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

An attacker may essentially be able to grief the reserves of the token which can impact the users who've contributed to the pool overall, by obtaing an AmountOut that is greater than the Reserve amount, leading to negative reserves from calling another function.

Vulnerability Details

In Well.sol, there isn't any checks to make sure the AmountOut can't exceed the Reserve Amount, With logic denoting AmountOut from user transfers.

Lines 207-217

function swapFrom( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline ) external nonReentrant expire(deadline) returns (uint256 amountOut) { fromToken.safeTransferFrom(msg.sender, address(this), amountIn); amountOut = _swapFrom(fromToken, toToken, amountIn, minAmountOut, recipient); }

Now since AmountOut is set via Swapfrom, an attacker can initiate (assuming that the amountout is far more than the reserve) the function SwapIn.

on Lines 336-348

function getSwapIn( IERC20 fromToken, IERC20 toToken, uint256 amountOut ) external view readOnlyNonReentrant returns (uint256 amountIn) { IERC20[] memory _tokens = tokens(); (uint256 i, uint256 j) = _getIJ(_tokens, fromToken, toToken); uint256[] memory reserves = _getReserves(_tokens.length);

    reserves[j] -= amountOut;

    amountIn = _calcReserve(wellFunction(), reserves, i, totalSupply()) - reserves[i];
}

This has no checks for AmountOut, and amountOut can be freely called from its initialization from Swapfrom. Called again, the AmountOut which > Reserves and be subtracted from reserves from 2nd function (SwapIn) without any checks to make sure reserves aren't negative, which can impact the other users who contribute to the protocol to the reserves.

Impact Details

This would lead to potential griefing on behalf of the attacker which would negatively impact the users of the reserve who're providing liquidity, but there wouldn't really be any benefit to the attacker by doing so, besides the damage

References

https://etherscan.io/address/0xBA51AAAA95aeEFc1292515b36D86C51dC7877773?utm_source=immunefi#code

Proof of concept

Attacker.Sol

// SPDX-License-Identifier: MIT pragma solidity ^0.8.4;

pragma solidity ^8.20;

//Where an attackers AmountOut > Reserve.

interface Well {

//attacker obtains an AmountOut greater than the reserves

function swapFromFeeOnTransfer( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline) external nonReentrant expire(deadline) returns (uint256 amountOut);

// Attacker utilizes this function to cause reserve damages. function getSwapIn( IERC20 fromToken, IERC20 toToken, uint256 amountOut ) external view readOnlyNonReentrant returns (uint256 amountIn);

}

contract Well { address immutable Well2 = 0xBA51AAAA95aeEFc1292515b36D86C51dC7877773;

Well2 Well = Well2(Well);

Well2.swapFromFeeOnTransfer( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline)

Well2.getSwapIn( IERC20 tokenOut, uint256 minAmountOut, address recipient ) external nonReentrant returns (uint256 amountOut);

}