[iracigt]

I think the title is a bit misleading. If I'm reading correctly, the "backdoor" allows a computer to peek and poke memory and other low-level functions of its own USB Bluetooth adapter. I don't this this is usable over the air?

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.

[iracigt]

Oh, and from the perspective of open hardware, these alarmist headlines are a real disservice. The natural reaction to debugging interfaces and firmware updates being "backdoors" and "security vulnerabilities" is to lock it all down.

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.

[AlotOfReading]

HCI commands aren't remotely accessible without further flaws. The key line from the article is:

    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.

The short answer is that if you have a secure driver stack and you trust all the local code, HCI vendor extensions aren't problematic.

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

[usrusr]

What if the computer peeking and poking memory of its own Bluetooth adapter might be doing so with software running on top of the Web Bluetooth API? I sure hope that it isn't that bad, but if it was, it would still be eerily consistent with your description.

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.

[gruez]

>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, nice. Unfortunately the guest the malware installed on the ESP when it has 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?

[usrusr]

Thanks. That thought "no PC uses an ESP as its wireless, ESP are used as devices that do their own wireless" was rummaging around in the back of my mind, but failed to really make itself heard.

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.

[laurowyn]

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

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.

[20after4]

It sounds like it might be very useful for an attacker who already attained access via some other exploit.

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.

[iracigt]

Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. "Backdoor" isn't wrong, but it is misleading. The threat here is persistence from context that wasn't expected to have this capability.

[throwaway5574]

> Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace.

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.

[seba_dos1]

That's right, but... who exposes ESP32's HCI to external world (and not just to another trusted chip) in actual projects? This is the kind of feature you see popping up as a Hackaday article titled "Your ESP32 As A USB Bluetooth Dongle" - you say "neat" and then proceed to forget about it.

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.

[gruez]

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

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

[20after4]

It's not that different. It might be easier than your average "pwn" and might not require root access, but this is only my hypothesis based on what's written in TFA.

[sitkack]

If it is USB, you should be able to do it directly in JS via Chrome.

[iracigt]

WebUSB requires the device to opt in via it's USB descriptors. Otherwise any USB device with firmware updates would have this problem.

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.

[monocasa]

> WebUSB requires the device to opt in via it's USB descriptors.

IIRC, that restriction was removed.

[gruez]

>It might be easier than your average "pwn" and might not require root access

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

[megadata]

> How's this any different

It's undocumented.

[gruez]

My laptop came with a 10 page quick start guide that mentions nothing about this "vulnerability". The only way to figure out whether a wifi chip can enter promiscuous mode or inject packets is by checking a wiki page maintained by volunteers.

[tru3_power]

So why couldn’t one make a malicious iot device/tool to do just that? I’m kinda confused on the need for access via some other exploit. (I have little domain knowledge on Bluetooth) - when you say scan/spoof/attack any near by device, is it ones that the target is already connected to? Sorry for dumb question

[huang_chung]

> In theory, the attacker could then use the undocumented commands to scan, spoof, or otherwise attack any near by bluetooth devices.

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?

[20after4]

I'm not arguing that this is a big f'in deal. Seems like it's not much of a deal at all actually.

[huang_chung]

After reading it really seems much ado about nothing.

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

[2OEH8eoCRo0]

So it can peek your Bluetooth crypto. How is it not a backdoor?

[vaxman]

@iracigt: There were many thousands of people who were unsurprised (but irritated and then outraged) when Mr. Snowden revealed such disturbing confidential information that they already knew or expected, but who also had known to keep secret and only speak about in general terms among those with whom they had already established credibility to know or understand such difficult to conceive matters.

The proof that you clearly seek of the "backdoor" can come one of three ways, another Snowden-like leak from inside the CCP-controlled Chinese chip fabricators, or more of this inexpensive novice-level probing/jailbreaking of such devices through their digital interfaces and protocol implementations, or via expensive and time consuming analog analysis (eg, TEMPEST, etc.) that study the device's radiology across the whole spectrum. (But even with imaging of the die, there is now a published technique that allows for the FAB to hide new or altered functionality until a sequence of opcodes are executed --in the field!) Nobody outside of government is going to spend much on trying to "(de)certify the integrity" of incredibly cheap ($7!) Chinese SoCs that suspiciously began "flooding the market" during the Pandemic-induced chip "shortage" simply because the circumstantial evidence and technical feasibility of their threat is so overwhelming. Just ask the manufacturer if they included a backdoor: If they know you are a credible questioner and/or may already have the answer, they will typically respond with something like "the other party does the same thing" or "its for debug purposes and will be removed." If they don't believe you to be credible, they will simply not answer you or may, as required by their law, lie. So, until there is another Snowden-like data dump involving CCP-controlled Chinese chip fabrication, you probably won't have access to any proof.

Bottom line: Master computer scientists warn that it is likely modern CCP-controlled Chinese SoC manufacturers are producing products that are vulnerable to RF-side exploitation (think of the signal that the Greeks used to know when to jump out of the Trojan Horse and start killing Romans). I would not ever trust these devices to critical infrastructure or even in many in-home scenarios, like boiler/water/gas operations, cameras/telemetry or automotive. A recommended Western alternative is the Raspberry Pi PICO 2 W. Perhaps one day Apple will be run by a new generation of executives that see another way to Change The World by entering this market.

https://youtu.be/ZO9M4zi4uGw

[vlovich123]

You’ve misread then:

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

[seba_dos1]

Nothing you quoted implies that there's an exploit that happens over Bluetooth. It actually implies otherwise, so you'll have to find a better quote if that's actually true (I couldn't, FWIW).

[justsid]

Not just that but it’s also not a USBC driver but a USB driver written in C. Everything about this was wrong. The original article is really upsetting because this just isn’t a big deal at all, at least given the current information.

[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?