CVE-2024-32873

Executive Summary

CVE-2024-32873 is a vulnerability in the Evmos blockchain, the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. The flaw resides in the accounting logic for clawback vesting accounts. When a user with a clawback vesting account delegates vested tokens, the spendable balance is not updated correctly. This allows the account to anticipate the release of unvested tokens, effectively spending tokens that should still be locked. The vulnerability has a CVSS score of 3.5 (Low) and is fixed in Evmos version 18.0.0. No public proof-of-concept or exploit code is available at this time.

Supply Chain & Package Security

This vulnerability affects the Evmos blockchain software, which is built using the Cosmos SDK and Go. The fix is included in the official Evmos release v18.0.0. Users should update their nodes to this version to mitigate the risk. The vulnerability does not directly impact NPM, PyPI, or Ruby packages, but it is critical for operators of Evmos validators and nodes to apply the patch.

CVSS Breakdown & Threat Level

• CVSS Score: 3.5 (Low)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) - The attacker needs a valid account with vested tokens.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Unchanged (U) - The vulnerability does not affect other components.
• Confidentiality (C): None (N) - No data is exposed.
• Integrity (I): Low (L) - The attacker can spend unvested tokens, affecting the integrity of the vesting schedule.
• Availability (A): None (N) - No denial of service.

Threat Level: Low. The vulnerability requires an account with vested tokens and only allows the premature spending of those tokens. It does not lead to a total loss of funds or network compromise.

Deep Dive & Mechanics

The vulnerability is in the x/vesting module of the Evmos blockchain, specifically in the logic that handles the delegation of tokens from a clawback vesting account. A clawback vesting account is a type of account where tokens are vested over time, and the original funder can "claw back" unvested tokens if certain conditions are met.

The issue occurs because the spendable balance is not recalculated correctly when a user delegates vested tokens. In a normal vesting account, the spendable balance is the amount of tokens that have vested and are available for spending. When a user delegates tokens, those tokens are locked in the delegation and should be subtracted from the spendable balance. However, due to a bug, the delegation of vested tokens does not properly update the spendable balance, allowing the user to still consider those tokens as spendable.

This means that a user with a clawback vesting account can delegate their vested tokens and then, because the spendable balance is not reduced, they can also spend the same tokens again (or spend tokens that should still be unvested). This effectively allows them to "double-spend" or spend tokens before they are fully vested.

The fix in v18.0.0 corrects the accounting logic to ensure that when vested tokens are delegated, the spendable balance is properly reduced, preventing the premature release of unvested tokens.

Vulnerable vs. Patched Code

The vulnerable code is in the x/vesting module. The exact code is not publicly available, but the logic can be described as follows:

Vulnerable Code (Conceptual):

// In the delegation handler for clawback vesting accounts
func (k Keeper) DelegateVestedTokens(ctx sdk.Context, delegator sdk.AccAddress, validator sdk.ValAddress, amount sdk.Coin) error {
    // ... get the vesting account
    // ... delegate the tokens
    // BUG: The spendable balance is not updated after delegation
    // The account still thinks it has the same spendable balance
    return nil
}

Patched Code (Conceptual):

// In the delegation handler for clawback vesting accounts
func (k Keeper) DelegateVestedTokens(ctx sdk.Context, delegator sdk.AccAddress, validator sdk.ValAddress, amount sdk.Coin) error {
    // ... get the vesting account
    // ... delegate the tokens
    // FIX: Update the spendable balance to reflect the delegation
    vestingAccount.DecreaseSpendableBalance(amount)
    return nil
}

The patch ensures that the DecreaseSpendableBalance method is called after delegation, which correctly reduces the spendable balance by the amount of tokens delegated.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an Evmos node running a vulnerable version (< 18.0.0).
• A clawback vesting account with some vested tokens.

Exploitation Steps:

1. Setup: Create a clawback vesting account on a vulnerable Evmos testnet.
2. Check Balance: Query the spendable balance of the account.

   evmosd query bank balances <your_address>
   

3. Delegate Vested Tokens: Delegate a portion of the vested tokens to a validator.

   evmosd tx staking delegate <validator_address> <amount> --from <your_key> --chain-id <chain_id>
   

4. Check Spendable Balance Again: Query the spendable balance again. Due to the bug, the spendable balance will not have decreased by the delegated amount.

   evmosd query bank balances <your_address>
   

5. Spend Unvested Tokens: Now, attempt to send tokens from the account. Since the spendable balance is still high, you can send tokens that should be unvested.

   evmosd tx bank send <your_address> <recipient_address> <amount> --from <your_key> --chain-id <chain_id>
   

6. Verify: The transaction will succeed, allowing you to spend tokens that are still locked.

Note: This is a conceptual exploit. No public proof-of-concept exists.

Blue Team

Detection:

• Monitor for unusual delegation patterns from clawback vesting accounts.
• Alert on transactions where the spendable balance of a vesting account does not decrease after a delegation.
• Use the detection rules provided in the Detection Engineering section.

Mitigation:

• Immediately upgrade all Evmos nodes to version 18.0.0 or later.
• If an upgrade is not immediately possible, consider temporarily disabling delegation for clawback vesting accounts (if feasible).
• Monitor for any suspicious activity and investigate any anomalies.

Indicators of Compromise (IOCs)

• Blockchain Events: Unusual delegation transactions from clawback vesting accounts followed by large transfers.
• Account Behavior: Clawback vesting accounts with spendable balances that do not decrease after delegation.
• Logs: Node logs showing successful delegation and subsequent transfer from the same account without a corresponding decrease in spendable balance.

Detection Engineering

YARA Rule

rule CVE_2024_32873_Evmos_Vesting_Bug {
    meta:
        description = "Detects potential exploitation of CVE-2024-32873 in Evmos node logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-32873"
    strings:
        $s1 = "delegate" nocase
        $s2 = "vesting" nocase
        $s3 = "spendable" nocase
        $s4 = "balance" nocase
    condition:
        all of ($s*) and #s1 > 1
}

Sigma Rule

title: CVE-2024-32873 - Evmos Vesting Spendable Balance Bug
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of CVE-2024-32873 in Evmos node logs
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-32873
logsource:
    product: evmos
    service: node
detection:
    selection:
        EventID: 'MsgDelegate'
        AccountType: 'ClawbackVestingAccount'
    condition: selection
falsepositives:
    - Legitimate delegation from vesting accounts
level: medium

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-32873 - Evmos Vesting Spendable Balance Exploit"; flow:to_server,established; content:"delegate"; nocase; content:"vesting"; nocase; within:100; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Upgrade all Evmos nodes to version 18.0.0 or later. This is the only complete fix.

   # For Cosmovisor users
   cosmovisor upgrade v18.0.0
   

2. Verify: After upgrade, verify the node is running the patched version.

   evmosd version
   

Long-Term Mitigations:

• Implement monitoring for vesting account behavior to detect any anomalies.
• Regularly review and audit the vesting module code for similar issues.
• Stay informed about security advisories from the Evmos team.

Workarounds (if upgrade is not immediately possible):

• There is no effective workaround other than upgrading. Disabling delegation for clawback vesting accounts may be considered but is not recommended as it breaks core functionality.

Valters IT
Securing the Cosmos, One Block at a Time