Future Beige Mole - Not following CEI pattern in mint function

[sherlock-admin2]

Future Beige Mole

High

Not following CEI pattern in mint function

Summary

https://github.com/sherlock-audit/2024-11-autonomint/blob/main/Blockchain/Blockchian/contracts/Token/Abond_Token.sol#L84-L107
The ABONDToken.sol contract might be vulnerable to reentrancy attacks due to the failure to strictly follow the Check-Effects-Interactions (CEI) pattern in certain functions like mint.

Vulnerability Details:

CEI Pattern Violation

The CEI pattern is a common best practice to prevent reentrancy attacks. It suggests the following order:
Check: Perform validation and checks before state-changing operations.
Effects: Update all internal state variables (such as balances or mappings) before making external calls.
Interactions: Make any external calls (e.g., transfers, token mints, or calling other contracts).
In the mint function, the pattern is partially violated. Specifically, after calculating the new states (fromState and toState) based on the minting amount, external actions like token minting (_mint) are performed before updating state variables in some cases, especially if new external calls are added or if minting logic changes. This can open the door for attackers to re-enter the contract and manipulate state variables before they are updated.

Potential for Reentrancy Attack:

If an external contract (or an attacker) can interact with the contract while the minting process is not fully completed (i.e., before the internal states are updated), the attacker could potentially call the function again, leading to unexpected changes to the contract's state.

Impact

Financial Loss
State Manipulationmappings, leading to erroneous token balances and potentially draining funds from the contract.
Token Inflation

PoC

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

interface IABONDToken {
    function mint(address to, uint64 index, uint256 amount) external returns (bool);
    function setBorrowingContract(address _address) external;
}

contract Attacker {
    IABONDToken public abondToken;
    address public victim;

    constructor(address _abondToken, address _victim) {
        abondToken = IABONDToken(_abondToken);
        victim = _victim;
    }

    // Function to perform a reentrancy attack
    function attack(uint64 index, uint256 amount) external {
        // Call the mint function, which will trigger a reentrancy attempt
        abondToken.mint(address(this), index, amount);
    }

    // Fallback function to be called when minting process triggers external call
    receive() external payable {
        // Re-enter the mint function (recursive call)
        abondToken.mint(address(this), 0, 1); // Example of re-entrancy, minting 1 more token each time
    }
}

Explanation:

The Attacker Contract:

The attacker contract has a mint function that interacts with the vulnerable ABONDToken contract.
When the attack() function is called, it triggers the mint() function in the ABONDToken contract, passing the attacker's address and minting parameters.

Reentrancy Trigger:

The ABONDToken contract, when minting tokens, does so before updating the state variables. This allows the attacker to exploit the reentrancy.
In the receive() function, the attacker’s contract recursively calls the mint() function again, causing additional tokens to be minted each time, exploiting the vulnerability.

Effect:

The attacker could mint tokens multiple times (based on the number of times the receive() function is triggered) without proper state updates, resulting in a potential drain of tokens and manipulation of the userStates mappings.

Execution Flow:

The attacker calls attack() on the attacker contract.
The attacker's contract triggers the minting function in the ABONDToken contract.
The mint function in the ABONDToken contract mints tokens but doesn't update the state first, leaving it open for a recursive call via the receive() function in the attacker’s contract.
The recursive call re-enters the mint() function, minting additional tokens for the attacker.

Recommendation

Ensure all internal state changes (like user balances and critical variables) are completed before interacting with any external addresses or making token transfers.