CVE-2024-37159

Executive Summary

CVE-2024-37159 is a privilege escalation vulnerability in Evmos, the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. The flaw allows a user to create a validator using vested tokens to deposit the self-bond, bypassing the intended token vesting restrictions. This could enable an attacker to gain undue influence over the network's consensus mechanism. The vulnerability is fixed in Evmos version 18.0.0.

Supply Chain & Package Security

This vulnerability affects the Evmos blockchain software, which is distributed as a Go binary. Users should verify the integrity of their Evmos binaries using checksums provided by the official Evmos releases. The fix is included in version 18.0.0, and all prior versions are considered vulnerable.

CVSS Breakdown & Threat Level

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

The low CVSS score reflects the limited direct impact on confidentiality and availability, but the integrity impact (ability to create a validator with vested tokens) could have cascading effects on network governance.

Deep Dive & Mechanics

The vulnerability resides in the validator creation logic within the Evmos staking module. When a user creates a validator, they must deposit a self-bond of tokens. The code failed to properly check whether the tokens used for the self-bond were vested (i.e., subject to a vesting schedule). Vested tokens are typically locked and cannot be used for staking until they are fully vested. By exploiting this flaw, an attacker could use their vested tokens to create a validator, effectively bypassing the vesting restrictions and gaining voting power in the network's consensus.

The root cause is a missing validation check in the MsgCreateValidator handler. The code should verify that the coins used for the self-bond are not from a vesting account or, if they are, that the vesting period has expired. The fix in version 18.0.0 adds this check.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

func (k Keeper) CreateValidator(ctx sdk.Context, msg types.MsgCreateValidator) (*types.MsgCreateValidatorResponse, error) {
    // No check for vested tokens
    coins := sdk.NewCoins(msg.Value)
    err := k.bankKeeper.SendCoinsFromAccountToModule(ctx, msg.DelegatorAddress, types.ModuleName, coins)
    if err != nil {
        return nil, err
    }
    // ... rest of validator creation
}

Patched Code (simplified):

func (k Keeper) CreateValidator(ctx sdk.Context, msg types.MsgCreateValidator) (*types.MsgCreateValidatorResponse, error) {
    // Check if the delegator has vested tokens
    if k.vestingKeeper.HasVestedCoins(ctx, msg.DelegatorAddress, msg.Value) {
        return nil, sdkerrors.Wrap(sdkerrors.ErrUnauthorized, "cannot use vested tokens for self-bond")
    }
    coins := sdk.NewCoins(msg.Value)
    err := k.bankKeeper.SendCoinsFromAccountToModule(ctx, msg.DelegatorAddress, types.ModuleName, coins)
    if err != nil {
        return nil, err
    }
    // ... rest of validator creation
}

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would need:

1. An Evmos account with vested tokens (e.g., from a team allocation or investor vesting schedule).
2. Access to the Evmos network (mainnet or testnet).

Steps:

1. Identify an account with vested tokens.
2. Create a validator transaction using the vested tokens as the self-bond.
3. The transaction would succeed on vulnerable versions (< 18.0.0), creating a validator with voting power derived from locked tokens.

Proof of Concept (PoC) using Evmos CLI:

# On a vulnerable Evmos node (version < 18.0.0)
evmosd tx staking create-validator \
  --amount=1000000000000000000aevmos \
  --pubkey=$(evmosd tendermint show-validator) \
  --moniker="MaliciousValidator" \
  --chain-id=evmos_9001-2 \
  --from=vested_account \
  --fees=2000000000000000aevmos \
  --yes

Blue Team

Detection and prevention:

1. Monitor validator creation events for accounts with known vesting schedules.
2. Audit staking transactions to ensure self-bond tokens are not from vesting accounts.
3. Upgrade to Evmos v18.0.0 immediately.
4. Use on-chain monitoring tools to alert on suspicious validator creation.

Indicators of Compromise (IOCs)

• Transaction Hashes: Any validator creation transaction from an account with vested tokens.
• Validator Addresses: Validators created with self-bond amounts that match vesting schedules.
• Account Addresses: Accounts that have both vesting schedules and validator creation activity.

Detection Engineering

YARA Rule

rule Detect_Evmos_Vested_Validator_Creation {
    meta:
        description = "Detects Evmos transactions creating validators with vested tokens"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-37159"
    strings:
        $tx_type = "/cosmos.staking.v1beta1.MsgCreateValidator"
        $vested_key = "vesting"
    condition:
        $tx_type and $vested_key
}

Sigma Rule

title: Evmos Validator Creation with Vested Tokens
id: cve-2024-37159
status: experimental
description: Detects attempts to create a validator using vested tokens on Evmos
author: Valters IT
logsource:
    product: evmos
    service: blockchain
detection:
    selection:
        event_type: "MsgCreateValidator"
        account_type: "vesting"
    condition: selection
falsepositives:
    - Legitimate use of fully vested tokens
level: medium

Suricata Rule

alert tcp any any -> any 26656 (msg:"CVE-2024-37159 Evmos Vested Validator Creation"; flow:to_server; content:"/cosmos.staking.v1beta1.MsgCreateValidator"; content:"vesting"; distance:0; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade all Evmos nodes to version 18.0.0 or later.
2. Short-term: Review all existing validators for any created with vested tokens and consider slashing or jailing them.
3. Long-term: Implement additional checks in the staking module to prevent any use of locked tokens for staking.
4. Monitoring: Set up alerts for any validator creation events from accounts with vesting schedules.

Valters IT
Securing the Cosmos, one block at a time.