[haswell]

What I took away from this was that malicious actors using ESP32 chips in their products could potentially leverage these commands to deliver essentially a Trojan horse.

“Buy this super cheap home automation product” turns into installing an APT in your network.

[Aurornis]

That's not an accurate interpretation. At best, they're saying that a device using an ESP32 radio could send arbitrary packets, change its MAC address, or read/write the memory and registers on the radio.

> “Buy this super cheap home automation product” turns into installing an APT in your network.

That doesn't make any sense. If you buy a device with a radio, it's reasonable to assume that a malicious firmware could send/receive arbitrary things. That doesn't mean they have control of your network.

EDIT: It's like if you plugged an ethernet IoT device into your network and then someone told you the Ethernet chip on the device was capable of sending arbitrary packets or changing its MAC address if the device chooses to do so.

[seba_dos1]

That's why the article is misleading, because what you took away doesn't make any slightest sense.

If a malicious actor can leverage these commands, it means they already have control over your device and can use its Bluetooth radio however they want.

The only security problem that this causes is when your firmware gives someone else ability to use ESP's Bluetooth via HCI over UART without validating their inputs, not expecting it to allow them to take over the device. This is a rather uncommon scenario though - the user of such interface would usually be still you, just from a different chip.

[haswell]

> If a malicious actor can leverage these commands, it means they already have control

Have control, or had control at some point in the device’s lifecycle?

e.g. if an upstream supplier leverages these commands to put the device in a vulnerable state (either intentionally or because of a supply chain compromise) prior to incorporation into some product, is this not still an issue?

[seba_dos1]

"Have control".

These commands let you do what a ROM bootloader does as well. They just do so over an unexpected vector (HCI interface), which could be a problem if you exposed it outside while not exposing the bootloader.

Are you actually trying to come up with a plausible case, or are just guessing without knowing what this "backdoor" is about?

Just for the record, the researches themselves described these command in their talk's abstract in this way:

> The tools will be complemented by the use of undocumented manufacturer commands on ESP32 devices that allow to increase the versatility of these devices when implementing attacks or conducting audits.

Source: https://reg.rootedcon.com/cfp/schedule/talk/5

The same could have been achieved by implementing an open-source replacement for the blob, by the way (just like it's already happening with ESP32's Wi-Fi peripheral: https://esp32-open-mac.be/).

[huang_chung]

> "Buy this super cheap home automation product” turns into installing an APT in your network.

If that was intention, no need to hide code in the Bluetooth, just write it in the firmware. The device itself it the trojan horse.

[stragies]

Only buy ESP32 products, where you can access the pins for reflashing with ESPHome.

[20after4]

100% agree. ESPHome is by far the best use for ESP32s that I've found.

[alt227]

> “Buy this super cheap home automation product”

Surely thats a risk with buying any of the cheap chinese IoT gadgets on amazon or alibaba and plugging them into your home network?

[excalibur]

> “Buy this super cheap home automation product” turns into installing an APT in your network.

Were we not already assuming this was the case?