Hidden feature in ESP32. Security. Bluetooth.

[runout-at]

Port, board and/or hardware

esp32

MicroPython version

No response

Issue Report

There is a recent report from Tarlogic about undocumented commands on the ESP32. At first they did call it backdoor but changed to feature - possibly for legal reasons:

https://www.tarlogic.com/news/hidden-feature-esp32-chip-infect-ot-devices/

• How does this effect Micropython firmware?
• Did somebody investigate this already?
• What can we do against it?

Code of Conduct

Yes, I agree

[DvdGiessen]

See Espressif's response here as well as the technical blog post they link in that response here.

In short, what I gather from those responses this doesn't seem to be a backdoor or big security issue, merely a few undocumented debugging commands in the BLE stack that can be called by code already running on the ESP32 (which means in case of MicroPython usually your own code), nothing that can be triggered remotely.

[sosi-deadeye]

It's like complaining that a modem offers the ability to dial.

So they have found out that you can execute proprietary commands via HCI. This assumes that the hacker already has access to the ESP32. This cannot be abused via OTA.

This sensationalism is getting worse and worse.

[Josverl]

I suggest to change this to a Discussion

[runout-at]

Thx for the links and for looking into it!

Feel free to change it to a discussion.

[projectgus]

At first they did call it backdoor but changed to feature - possibly for legal reasons:

The original researcher's presentation slides don't call it a backdoor, only the press release called it this and they've since corrected it. But calling it a backdoor did get them a lot of attention...

For the technical details, suggest reading the links @DvdGiessen posted above. If you want to read something written by a third party expert, then suggest https://darkmentor.com/blog/esp32_non-backdoor/ .

• How does this effect Micropython firmware?

This doesn't pose any security risk for any of the common uses of MicroPython on ESP32, including writing Bluetooth code in Python. The only case where it could be a security risk is if someone does all the following things:

1. Disable the REPL.
2. Write custom Python code that exposes an external Bluetooth HCI command interface on a serial port or some other interface, with a wired connection to another host (like a PC). Where the MicroPython code relays the commands it receives to the ESP32 Bluetooth stack. I don't think there's any example code for this as it's not something people generally do, and I've never heard of anyone doing it. However, it's probably technically possible to do it.
3. Have the attached host unable to already update the MicroPython firmware (i.e. no ESP32 UART bootloader, or enable flash encryption, etc.)

If all these conditions are true and an attacker gains control of the attached host somehow, they can use the exposed wired HCI command interface to also modify the ESP32 in a way that's not otherwise possible.

I assume this will be patched in the next ESP-IDF release, which MicroPython will then support.

For everyone else using MicroPython on ESP32 in any other way, this security research doesn't change anything.

[runout-at]

From the researchers article (https://www.tarlogic.com/news/hidden-feature-esp32-chip-infect-ot-devices/):

If we can execute code on an IoT device that uses the ESP32 as its communications module—due to a security flaw compromising the device—then, using HCI commands, code can be stored in the ESP32 memory and executed without the main processor’s knowledge. Moreover, this modification can be persistent. This means that by gaining legitimate access to an IOT device that uses the ESP32 as a communications module via HCI, it is possible to achieve persistence, execute code, perform Bluetooth attacks, track devices and exfiltrate information via Bluetooth or WiFi.

While this is not a remote Bluetooth vulnerability, these hidden firmware functionalities can be used to inject persistent code that carries out malicious activities on any device using the ESP32 as its HCI communications chip.

It seems the press release did shoot too far.