Full Report
The Thermomix TM5 is a multifunctional kitchen appliance. In previous research, Jean-Michel Besnard found a directory traversal flaw in BusyBox's tar implementation. This article describes a lot of reverse engineering of the device and a firmware downgrade vulnerability they found in the process. The device contained a strangely formatted NAND flash; after considerable effort, they found a tool to decode it. There are cook sticks that hold recipes for use with the Thermomix. Upon looking at the UDP flash drives, they find out they are encrypted. Upon examining the NAND flash firmware, a file named /opt/cookey.txt is found to contain the encryption key. After some reviewing of a customized kernel driver, they are able to decrypt locally, but cannot modify it because the data is signed. The Cook Key is a special device that enables users to connect the Thermonix to WiFi, download firmware updates, and access additional recipes from a cloud service. It contains a WLAN module, an LED controller, and a UDP flash drive for the file system. The first partition contains a cs.tar and the second partition contains recipes, cloud settings, and a recovery firmware image. The author wanted to emulate the Cook Key completely. Therefore, they created a custom board with all the pre-signed information. This isn't an issue by itself but it allows for a larger attack surface. The version section is what we're after. This contains three values: date, comment and force_flag, with the first two being arrays. The original usage of this contained a security issue: the firmware could be downgraded by swapping firmware update file sections between versions. A classic replay issue, but this was the past, and we needed a new vulnerability by swapping these individual sections around. When verifying the firmware update file, each section is encrypted using the AES-EAX mode. This combines AES-CTR for encryption and OMAC-based tag for integrity. Each section is RSA-signed, but the nonce and tag are excluded from the signature so that they can be tampered with. We know the encryption algorithm in this case, but we're unable to modify anything because of the signature. Or can we? In AES-EAX decryption, the keystream is generated from the nonce N and the AES key K. PT = C0 XOR K0 in most cases. This can be rearranged to K0' = C0 XOR P0'. If we XOR our plaintext with the ciphertext, we can know what key (nonce starting value) it can be generated with. Since we control the nonce and know the key, we can reverse the encryption process to find a nonce that will match this. Neat! In practice, we control the first date string but everything else will be a garbled mess. The force_flag is something that we want to be set to 1 though. By brute forcing enough keys, it's possible to set this to 1. All of this works because A) the nonce is not verified and B) the header information with the date, comment, and force_flag is a singular encrypted piece of data with nothing else in it. I find it weird that the signature is unique per section, personally. Cryptography, particularly AES-CTR mode, is hard to use properly. With both encryption and signatures, this scheme looked perfect but it gave the author just enough room to workaround it. Awesome post!
Analysis Summary
# Vulnerability: Thermomix TM5 Firmware Downgrade via Flawed AES-EAX Implementation in Update Sections
## CVE Details
- CVE ID: Not explicitly listed in the provided summary. (Research suggests this finding might lead to future CVEs based on the severity described.)
- CVSS Score: Not explicitly listed in the provided summary. Severity is described as allowing arbitrary code execution in some versions.
- CWE: CWE-327 (Use of a Broken Cryptographic Algorithm) or CWE-384 (Authentication Bypass by Capture-Replay Attack - related to the downgrade aspect).
## Affected Systems
- Products: Thermomix TM5 multifunctional kitchen appliance.
- Versions: Unspecified vulnerable versions that utilize the described firmware update verification mechanism.
- Configurations: Devices utilizing the Cook Key for WiFi connectivity and firmware updates leveraging encrypted and signed update sections.
## Vulnerability Description
The vulnerability lies within the device's firmware update verification process. Firmware update files are composed of sections, each encrypted using AES-EAX mode and individually RSA-signed. Crucially, the 96-bit **nonce** and the **integrity tag** are excluded from the RSA signature calculation.
1. **AES-EAX Weakness:** Since the controlling device dictates the nonce ($N$) used for AES-CTR encryption and the nonce is not validated, an attacker can use the equation $K_0' = C_0 \oplus P_0'$ (where $C_0$ is the first block of ciphertext and $P_0'$ is the desired first block of plaintext) to determine the required keystream starting value.
2. **Forced Flag Manipulation:** The header information (containing `date`, `comment`, and `force_flag`) is a singular encrypted data block. By manipulating the known plaintext/ciphertext relationship, the attacker can brute-force nonces until the resulting decrypted data block yields a desired state, specifically setting the `force_flag` (which needs to be 1) to 1.
3. **Downgrade Prone:** This manipulation, coupled with previous findings (replay issues), allows an attacker to effectively force the installation of vulnerable or older firmware versions by swapping sections between different firmware update files. The ability to set `force_flag` to 1 bypasses necessary checks related to versioning constraints.
## Exploitation
- Status: The description implies successful proof-of-concept development ("we can reverse the encryption process," "By brute forcing enough keys, it's possible to set this to 1").
- Complexity: **Medium** (Requires deep reverse engineering of the device, understanding the custom NAND flash format, key extraction, and cryptanalytic manipulation of AES-EAX without destroying the signature).
- Attack Vector: Likely **Network** (via Cook Key/WiFi update mechanism) or **Physical** (by injecting malicious data onto storage/update medium, depending on the specific attack vector chosen for delivery).
## Impact
- Confidentiality: **Negligible** (Primary impact is on Integrity/Control).
- Integrity: **High** (Allows for installation of malicious or custom firmware, potentially leading to arbitrary code execution).
- Availability: **High** (Device can be bricked or put into a state dictated by an attacker's firmware).
## Remediation
### Patches
- Specific patch versions are not provided in the summary. The vendor (Vorwerk) should release updates addressing the non-validated nonce handling in the firmware update process (specifically within the header encryption verification).
### Workarounds
- **If applicable:** Disable automatic firmware updates or restrict update sources if possible until a verified patch is applied.
- **Hardware Control:** Ensure physical access to the device is restricted and that update sources are trusted.
## Detection
- **Indicators of Compromise:** Anomalous firmware version changes, unexpected device behavior post-update attempt, or log entries indicating unusual nonce or integrity tag failures during update verification.
- **Detection Methods and Tools:** Analyzing network traffic during legitimate update processes to baseline expected key/nonce/tag behavior. Deep inspection of the firmware update file structure to identify manually tampered sections.
## References
- Vendor Advisory: Not provided.
- Relevant links: hxxps://www.synacktiv.com/en/publications/let-me-cook-you-a-vulnerability-exploiting-the-thermomix-tm5