CVE-2024-39696

Executive Summary

CVE-2024-39696 is a critical authorization bypass vulnerability in the Evmos blockchain, a decentralized Ethereum Virtual Machine (EVM) chain on the Cosmos Network. The flaw allows an attacker to create a vesting account using a third-party address as the funder without that party's permission. By exploiting this, an attacker can drain any account on the chain by specifying it as the funder in a vesting account creation message. The vulnerability has a CVSS score of 8.8 (High) and affects all versions prior to 19.0.0. The patch is available in version 19.0.0, which enforces proper authorization checks on the funder address.

Supply Chain & Package Security

Evmos is a Go-based blockchain project. The vulnerability exists in the core chain logic, not in a package manager dependency. However, node operators and validators must ensure they are running the patched version (19.0.0 or later) to prevent exploitation. No supply chain compromise is involved, but the impact on the network's integrity is severe.

CVSS Breakdown & Threat Level

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

The vulnerability is remotely exploitable without authentication, making it a critical threat to all Evmos nodes. An attacker can drain funds from any account, leading to total loss of assets and network trust.

Deep Dive & Mechanics

The vulnerability lies in the vesting account creation mechanism. In Evmos, a vesting account can be created with a funder address that provides the initial funds. The code checks authorization against contract.CallerAddress, but the funds are actually taken from the funder address provided in the message. This mismatch allows an attacker to specify any address as the funder, including addresses they do not control. The authorization check is bypassed because it only verifies the caller's address, not the funder's consent.

Attack Flow:

1. Attacker creates a vesting account with a target address (e.g., a rich wallet) as the funder.
2. The system checks authorization for the attacker's address (which is valid), but deducts funds from the target address.
3. The attacker can repeat this for any account on the chain, draining all funds.

The vulnerability is in the MsgCreateVestingAccount handler, where the funder address is not validated against the authorized caller.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-19.0.0):

func (k Keeper) CreateVestingAccount(ctx sdk.Context, msg *types.MsgCreateVestingAccount) (*types.MsgCreateVestingAccountResponse, error) {
    // Authorization check only on caller
    if err := k.CheckAuthorization(ctx, msg.CallerAddress); err != nil {
        return nil, err
    }
    // Funds taken from funder address without validation
    err := k.bankKeeper.SendCoins(ctx, msg.FunderAddress, msg.VestingAddress, msg.Amount)
    // ...
}

Patched Code (19.0.0):

func (k Keeper) CreateVestingAccount(ctx sdk.Context, msg *types.MsgCreateVestingAccount) (*types.MsgCreateVestingAccountResponse, error) {
    // Authorization check on the funder address
    if err := k.CheckAuthorization(ctx, msg.FunderAddress); err != nil {
        return nil, err
    }
    // Funds taken from the authorized funder
    err := k.bankKeeper.SendCoins(ctx, msg.FunderAddress, msg.VestingAddress, msg.Amount)
    // ...
}

The fix ensures that the authorization check is performed on the FunderAddress instead of the CallerAddress, preventing unauthorized fund transfers.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an Evmos node (RPC endpoint)
• Ability to sign transactions (e.g., using evmosd CLI or a wallet)

Exploit Steps:

1. Identify a target account with significant funds (e.g., a known whale address).
2. Create a vesting account transaction with the target as the funder:

   evmosd tx vesting create-vesting-account \
     --from attacker-wallet \
     --funder TARGET_ADDRESS \
     --vesting-address NEW_VESTING_ADDRESS \
     --amount 1000aevmos \
     --end-time 1234567890 \
     --chain-id evmos_9001-2 \
     --fees 2000000000000000aevmos
   

3. The transaction will succeed, draining funds from TARGET_ADDRESS to NEW_VESTING_ADDRESS.
4. Repeat for all desired targets.

Note: No public exploit code is available, but the attack is straightforward due to the logic flaw.

Blue Team (Defense & Detection)

Immediate Actions:

• Upgrade all Evmos nodes to version 19.0.0 or later.
• Monitor for unusual vesting account creation transactions where the funder address is not the signer.
• Implement network-level monitoring for anomalous transaction patterns.

Detection Rules:

• Alert on any MsgCreateVestingAccount where FunderAddress differs from the transaction signer.
• Monitor for rapid creation of vesting accounts from a single address.

Indicators of Compromise (IOCs)

• Transaction Patterns: Multiple MsgCreateVestingAccount transactions from a single address with different funder addresses.
• On-Chain Activity: Sudden creation of vesting accounts with large amounts from high-value addresses.
• Logs: Node logs showing CreateVestingAccount calls with mismatched funder and caller addresses.

Detection Engineering

YARA Rule

rule Detect_Evmos_Vesting_Exploit {
    meta:
        description = "Detects Evmos vesting account creation with unauthorized funder"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-39696"
    strings:
        $msg_type = "MsgCreateVestingAccount"
        $funder_field = "funder_address"
        $caller_field = "caller_address"
    condition:
        $msg_type and $funder_field and $caller_field
}

Sigma Rule

title: Evmos Unauthorized Vesting Account Creation
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects attempts to create vesting accounts with unauthorized funder addresses
author: Valters IT
logsource:
    product: evmos
    service: node
detection:
    selection:
        event: "MsgCreateVestingAccount"
        funder_address|re: "0x[a-fA-F0-9]{40}"
        caller_address|re: "0x[a-fA-F0-9]{40}"
    condition: selection and funder_address != caller_address
falsepositives:
    - Legitimate multi-sig operations (rare)
level: high

Suricata Rule

alert tcp any any -> any 26657 (msg:"Evmos Vesting Exploit - Unauthorized Funder"; flow:to_server; content:"MsgCreateVestingAccount"; content:"funder_address"; distance:0; content:"caller_address"; distance:0; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade all Evmos nodes to version 19.0.0 or later.
• If upgrade is not possible, disable vesting account creation via governance or node configuration.

Long-term:

• Implement additional authorization checks for all fund transfers.
• Conduct a security audit of the vesting module.
• Monitor for similar authorization bypass patterns in other modules.

Workaround:

• Use a firewall to restrict access to the RPC endpoint to trusted parties only.
• Implement transaction filtering to block suspicious vesting account creation.

Valters IT
Securing Blockchain Infrastructure