Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable.

If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.

Espressif has been an almost unique level of open for this space. They've contributed to open source Rust toolchains for their chips. They've even publicly encouraged reverse engineering of their modem stack because it contains licensed code they can't release. I hate to see bad and damaging publicity be the reward for being just a little bit open.

    Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.

With that said, HCI extensions can easily be a security hole. The problem is that HCI mixes attacker-controlled inputs with a complicated interface and a lot of fiddly parsing. It's easy to get wrong, as the BleedingTooth [0] vulnerability demonstrated a few years back.

Having these kinds of things around also makes it easier to pivot a vulnerability elsewhere, though that's low hanging fruit on most systems.

[0] https://google.github.io/security-research/pocs/linux/bleedi...

But let's ignore that web API worst case. Imagine that you have some semi-trusted software and because you don't want to take any risks, you run in nested VMs three layers deep. The software has some plausible excuse to require access to the Bluetooth (perhaps it's a beacon demo?) so you grant an exception. You're not happy with the result (the beacon demo does not work as promised?), you remove the software and you also reset all three VM layers for good measure. Gone for good, nice. Unfortunately, the guest the malware installed on the ESP when it had access is still there...

Yes, undocumented access to your own subdevices can be a really bad thing, in particular when persistence is in the picture.

There are approximately 0 people who have the type of setup you described. Moreover, the chipset in question is only used in IOT devices, so it can't even be used in the way you described. Finally, does the chipset even have writeable memory? Or is it an exploit that only persists until the next reset?

I'm one of those who think NRF when they hear Bluetooth chip and with Nordics it's actually not that uncommon: when you want to make a PC talk ANT+ (r.i.p.) the dongle you put inside a USB port is usually the same Nrf52 you'd also find in a standalone device, only with some of its GPIO connected to the USB pads.

You're hopping through 4 security boundaries and granting direct hardware access. If you don't understand the decisions you're making by doing that, all bets are off.

Better to give a virtualised bluetooth device and let the hypervisor drive the real one. Will hit performance a little, but it's far more secure.

Imagine the ESP32 is being used as a wifi/bluetooth "modem" via a serial link to a host system (rather than the ESP32 used as a standalone SOC.)

In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices. Perhaps this could even be achieved without gaining root on the device which is hosting the esp32.

If you find a device that does it in the wild, then I guess you now gained a nice jailbreaking vector - that is, if it needed jailbreaking at all. Otherwise, it's nothing.

This possibility should be obvious to any software developer that knows how modern IO peripheral stacks are constructed. There is little that can be done to defend against a poorly written OS driver that exposes functions like this, even unintentionally, and it is naive to assume that any class of device will lack them unless clearly documented otherwise. This has been of particular concern to developers of open source Linux kernel drivers for decades at this point.

How's this any different than a laptop getting pwned and attackers being able to run aircrack-ng or whatever on it?

Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.

IIRC, that restriction was removed.

It's an IOT device. Everything's running as root.

So? Device is 0wned. Did you think Bluetooth chip is magic protection device for rest of the network?

How would you stop physical external actor? Do you have "No ESP32 permitted on this property" signs on windows?

Wait until they learn you can rewrite disk drive firmware from inside OS with root access.

> Armed with this new tool, which enables raw access to Bluetooth traffic, Targolic discovered hidden vendor-specific commands (Opcode 0x3F) in the ESP32 Bluetooth firmware that allow low-level control over Bluetooth functions.

The exploit happens over bluetooth. They used a USBC driver to explore the potential attack surface.

Shit like this is what happens when you don’t have good separation between functionality you give QA for production firmware & commands for factory firmware bringup. Almost certainly this is because the vendor used the same image for factory bringup & shipping to end users.

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

> “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.

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.

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?

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/).

Surely thats a risk with buying any of the cheap chinese IoT gadgets on amazon or alibaba and plugging them into your home 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.

Were we not already assuming this was the case?

Calling this a "backdoor" is just pure clickbait.

Yeah this does not sound like a RCE.

Clearly there are unanswered questions like does this malicious firmware exist? and how likely is it that ESP32s in the wild were shipped with it?

But they’re still describing an RCE.

The fact that it might be necessary to execute these commands locally is separate from the effects of executing those commands and the potential implications for hardware in the wild.

A simple example would be a supply chain attack that leverages these commands to compromise what will soon be consumer hardware.

ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.

If someone just discovered nc in the wild and up to that point it had been unknown, people would put that bit of software in a very different category than the one it exists in today.

Quick, before someone posts this to Mastodon and gives presentation at security conference with title:

Living off the Land: the Hidden Threat Within

Malicious firmware is not a RCE. If you install a malicious firmware you can do all kinds of bad stuff without this undocumented behavior.

And "rogue Bluetooth connections" is entirely theoretical. That MIGHT be a RCE, but it is not one. More of a hypothesis.

The headline alludes to much more than they have actually demonstrated. I'll change my tune when they demo the exploit code.

I prefer when devices have these low-level interfaces. Perhaps the problem is the lack of documentation rather than existence?

I used to use the memory read/write commands via USB on Qualcomm radios to unlock and otherwise take ownership of otherwise locked-down devices. Given that was a full OOB read/write I'd consider that maybe not great, but if this is only accessible from flashed code all the better.

Not really a backdoor. I don't know if they called it a backdoor (presentation is in Spanish), or if the journalists are calling it a backdoor to get more clicks.

You'd need to have arbitrary access to send HCI commands to the device to use these commands. That means you're already controlling the device and how it operates. This isn't something that gets remotely exploited over the wireless link. Any exploits would already have to have full control of the device, at which point being able to change the MAC address or send packets isn't really a surprise anyway.

Interesting research, but really groan-inducing to see it spun as a "backdoor". I don't know who's to blame for the wording, though. I'm guessing the journalists?

EDIT: For an analogy that might be more familiar, imagine if someone discovered that the Ethernet controller on a common IOT chip could change its MAC address or send arbitrary packets if the firmware told it to. This is the same thing, but with Bluetooth.

Fun fact: a lot of the extremely cheap USB BT adapters you can find sold online have the same MAC address, probably because they couldn't be bothered to change it to something unique. Hence why things like https://macaddresschanger.com/ (Windows) and bdaddr (Linux) exist. Most of them seem to be clones of a CSR design, and the commands to set its address are well-known. (See https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool... )

https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...

Many devices already allow you to change your MAC if you want. This isn't new, it's been the case since the beginning of ethernet, and subsequently wifi.

Then you have things like device privacy on Windows and Android that use randomized MACs when connecting to new networks.

(In a well-functioning journalism ecosystem, this would require a retraction and would significantly harm the reputation of the outlet that wrote it. Sadly this will not happen.)

Really wonder if something got lost in translation, here. In the past we would have just thought that was cool and looked for a way to turn it into a SDR.

It seems all too plausible, based on my admittedly limited understanding of how these devices work.

e. g. it doesn't make sense to install ESPHome on an ESP32-based drone :)

https://www.reddit.com/r/embedded/comments/wopjw8/how_sure_a...

https://github.com/esp32-open-mac/esp32-open-mac