Internet of Things (IoT) devices are now part of our everyday lives, from smart lights to home security. To get these devices online, manufacturers often use simple, touchless protocols like Espressif’s ESPTouch to make setup easy. However, simplicity can come at the cost of security. Recently, a serious vulnerability was discovered in the ESPTouchV2 protocol, which is widely used in ESP-IDF based devices and applications.

CVE-2024-53845 highlights a critical issue: when using AES encryption in ESPTouchV2 before versions 5.3.2, 5.2.4, 5.1.6, and 5..8, the Initialization Vector (IV) is set to ZERO and never changes — opening the door for attackers to decrypt and predict sensitive data transmissions.

Below, you’ll find a deep dive into how this vulnerability works, why it matters, how to exploit it, and how to patch your systems.

Understanding ESPTouchV2 and Its Encryption

ESPTouch is a smart configuration protocol used to provide Wi-Fi credentials to devices over the air, typically during first-time setup. ESPTouchV2 improved security by adding support for custom AES keys when provisioning data.

However, in versions before the patched releases mentioned above, the Initialisation Vector (IV) for AES in Cipher Block Chaining (CBC) mode was always set to x000... (all zeros), and it remained constant for the life of the product.

What is the IV?

The IV is a random value that should be different each time encryption is performed. In CBC mode, using a unique IV each time prevents attackers from noticing patterns in encrypted data.

Patterns in provisioning data are exposed with each configuration attempt.

- Attackers can use "known plaintext attacks" and replay attacks to deduce or even decrypt sensitive Wi-Fi credentials.

Step-by-Step Exploit Scenario

Let’s say an attacker can listen to the Wi-Fi traffic when someone uses ESPTouchV2 to set up a device:

Replay the Provisioning Process:

Since the same AES key and IV are used every time, initiate provisioning multiple times to collect multiple ciphertexts.

Known-Plaintext Attack:

If the attacker knows or can guess the structure of the plaintext (e.g., “SSID: MyWiFi”), and since the IV is always zero, it’s trivial to match patterns, deduce the key, or just brute-force the credentials.

Suppose we have the following simplified setup using PyCryptodome for demonstration purposes

from Crypto.Cipher import AES

key = b'mysecretkey12345'  # 16 bytes
iv = b'\x00' * 16  # All zeros, identical for every session
plaintext = b'SSID:MyWiFi;PWD:SuperSecret123'

cipher = AES.new(key, AES.MODE_CBC, iv)
ciphertext = cipher.encrypt(plaintext.ljust(32, b'\x00'))  # Pad to 32 bytes

print(ciphertext.hex())

Each time you run this, the output will be exactly the same because iv doesn’t change. If an attacker can get several ciphertexts from different session attempts and knows how the plaintext is structured—like a Wi-Fi SSID and password—they can precompute possible ciphertexts for common SSIDs or even brute-force the whole credential set.

Timeline & Patch Details

Vulnerable Versions:

v5..8

Patched Approach:
Starting with the versions above, a random IV is generated each time the AES key is activated. This IV is then:

Parsed and used by the device during decryption.

All users of the ESPTouchV2 component in ESP-IDF must upgrade to remain secure.

No User-Land Workaround:
Because AES handling—including the now-fixed IV logic—is embedded deep in the ESP Wi-Fi stack, there is no user-level code fix. The only solution is to upgrade device firmware containing the patched ESPTouch library.

References

- Espressif Security Advisory
- Official ESP-IDF GitHub: ESPTouchV2 Releases
- Explanation: Why IV Matters in AES-CBC

Encourage vendors and device makers to patch and push updates to all customers.

Remember:
If your device cannot be updated, consider switching to more secure alternatives. Once a zero-IV AES-CBC is in the wild, there is no way to protect the secrecy of Wi-Fi credentials transferred via the provisioning protocol.

In Summary

CVE-2024-53845 is a stark reminder that "secure" encryption requires both a good key and random, unique IVs every time. The ESPTouchV2 protocol’s failure to handle this left millions of devices open to attack until patched. Firmware updates are the only way to close this loophole — so upgrade today and secure your smart environment!

Timeline

Published on: 12/12/2024 02:15:29 UTC