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.
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.
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.
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.
>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?
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.
> 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.
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.
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.
> 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.
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.
>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?
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.
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.
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.
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
> 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.
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).
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.
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.
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.
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.
> 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?
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.
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/).
The researchers found undocumented hardware functionality which allows someone who already has code execution a greater-than-expected degree of low-level access to the ESP32 wifi stack.
I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor
> "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."
Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
Are you saying that none of the undocumented commands are capable of putting the device into a remotely exploitable state?
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.
The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes.
ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.
If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state, but that doesn't mean that nc or sh have RCE vulnerabilities, or that operating systems which allow installing nc and sh have RCE vulnerabilities.
nc and sh are well known and documented tools. Their existence on a system and running state can be inspected and the implications of various configurations is well understood.
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.
The exploit here is that you can reprogram new firmware onto the device.
The reason it's not important is that you require a physical connection to the target device. The exact same type of connection you use to program firmware in the first place.
The "backdoor" is just that there's now one additional way to program firmware with a physical connection to the chip. The only issue is it was never documented.
There's no potential for exploitation here. If you have physical access to a real serial port on one of these chips, you cab load your own firmware. That's it. That's the entire exploit.
It's meaningless nothing. It really only matters at all if you care about blocking unauthorized firmware updates over a wired serial connection. If you do care, there are options aplenty.
Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE
In theory you probably should have low-level access to your attached BT radio itself, so this is just kind of expected, isn't it?
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.
TL;DR: They reverse engineered the firmware and found HCI commands to do things like read/write memory, send packets, and set the MAC address.
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... )
Don't you see how a random device with an Ethernet cord being able to change its MAC address and send arbitrary packets is a wormable threat actor?
...and then let it do the same but without the Ethernet cord requirement?
Drive around with a white van that says "Free Candy / BLE Persistent Threats"... pwn devices as you walk through the metal detectors on the way to China.
Wireless, wormable, arbitrary packets, spoofing arbitrary devices and you don't see the issue?
> Don't you see how a random device with an Ethernet cord being able to change its MAC
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.
So everyone's fine installing opaque binary blob drivers which run in kernel space on their desktops and laptops and not even having root access to their own cloud-controlled phones, but some undocumented low-level ESP32 commands which require the device to already be compromised are a news-worthy threat vector.
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.
This is good research, but a bad headline. As an attack vector, this requires physical access and could already be done by other means in almost all cases. So, “undocumented commands found in common Bluetooth chip” would be a better headline.
I was thinking the same thing, maybe for downloading locked firmware. Now that we know we can use LLMs to clean-room just about any code, extracting firmware from devices just because much more valuable.
On most modern micro-controllers you can disable JTAG/SWD in production or gate access behind key verification. You can't disable undocumented commands. The issue here might be allowing persistent malware, like how some malware can hide in hard drive firmware. Unlikely, but still not good or indicative of good security practice.
This headline is a lie. A backdoor in a Bluetooth chip would be something which enabled a wireless attacker to gain code execution on the chip. This article reports on something which allows the device drivers of the attached device to gain code execution on the chip, which does not violate a security boundary.
(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.)
Got me think: it's time to end using binaries of assembler. Just some intermediate bytecode (can be 1:1 to assembly) and private VM that, for starters instruction whitelisting.
I know - 'if' (at minimum) on every asssembly instruction :> But there is no other way then that. Life.
FWIW almost nobody uses ESP32 for Bluetooth alone. This is primarily a Wi-Fi SoC. "Billion devices" is a ridiculous claim if most of them don't use BT features anyway.
One of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode. If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet. This would of course be coordinated with multiple underwater cable cuts.
It seems all too plausible, based on my admittedly limited understanding of how these devices work.
>One of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode.
This is a terrible conspiracy theory. Given how much Chinese IOT devices active in the West right now, the CCP doesn't even need to fly a balloon into the US. They can just pressure its IOT vendors to push a firmware update that broadcasts the DDOS signal.
>If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet.
At best it'll take down 2.4ghz communications, not the entire internet, or even all wifi networks. 5 Ghz/cellular networks will be spared because cheap chinese IOT devices don't operate in those frequency ranges, or the band is too wide for devices to jam. Moreover any important systems/institutions would presumably have hardwired connections, which are completely immune.
No, of course there is no evidence, that's why it's a conspiracy theory. I can't remember if I saw it on a YouTube comment or a Reddit thread. Both are only slightly better than 4chan.
It sounds like more of a conspiracy fantasy to me if I'm being honest. The most attractive conspiracy theories in the US right now have nothing really to do with China but rather Russia instead.
A very far stretch: You have a ESP32 based Bluetooth dongle, that exposes its HCI interface to the host. You have already gained access to the host and can now load code to the dongle.
Not really a vulnerability, and many types of bluetooth dongle firmwares can be updated by the host...
Funny that I just pulled out an ESP32 dev kit a couple days ago and I honestly questioned myself with "how do you even know these things are secure at all?" Glad I know the answer now.
I'm starting to miss the days of being disconnected more and more as time goes on. This constant churn of having to monitor and lockdown everything you own down is becoming a complete negative.
EDIT: My Spanish isn't very good, but reading the slides it doesn't sound like the vulnerability is likely to be remotely exploitable, it sounds like it's only an issue if the chip is in HCI mode and being used as a bluetooth adapter. If someone who speaks Spanish could confirm I would be very appreciative.
With ESP32, always regard the vendor firmware only as proof-of-electrical-functioning. The first thing you should do with any ESP32 device after basic function test, is install ESPHome on it. If that's not possible, buy something different, where you can replace vendor fw.
Oh, I completely agree for IoT devices. When I was first reading the article I feared that the issue was something burned into the bluetooth radio binary blob, or something at the hardware level that would not have mattered whether you were running esphome or not. Upon a little deeper inspection, it doesn't sound like that's the case.
Am I misremembering, or wasn't there some hubbub ca. 2010 where someone was going to do a presentation at CCC about how Bluetooth is basically swiss cheese in terms of security, and someone got all huffy about it and it was all hush-hush'd and the presentation cancelled?
Can any app running on an Android device with an ESP32 save code permanently to flash memory? Would an app have that level of access to send arbitrary low-level commands to the hardware?
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.
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.
[dead]
HCI commands aren't remotely accessible without further flaws. The key line from the article is:
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...
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.
>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?
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.
> 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.
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.
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.
> 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.
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.
>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?
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.
If it is USB, you should be able to do it directly in JS via Chrome.
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.
> WebUSB requires the device to opt in via it's USB descriptors.
IIRC, that restriction was removed.
>It might be easier than your average "pwn" and might not require root access
It's an IOT device. Everything's running as root.
> How's this any different
It's undocumented.
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.
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
> 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?
I'm not arguing that this is a big f'in deal. Seems like it's not much of a deal at all actually.
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.
So it can peek your Bluetooth crypto. How is it not a backdoor?
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.
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).
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.
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.
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.
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.
> 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?
"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/).
> "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.
Only buy ESP32 products, where you can access the pins for reflashing with ESPHome.
100% agree. ESPHome is by far the best use for ESP32s that I've found.
> “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?
> “Buy this super cheap home automation product” turns into installing an APT in your network.
Were we not already assuming this was the case?
The researchers found undocumented hardware functionality which allows someone who already has code execution a greater-than-expected degree of low-level access to the ESP32 wifi stack.
Calling this a "backdoor" is just pure clickbait.
I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor
> "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."
Yeah this does not sound like a RCE.
In what way is what you quoted not describing an 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.
Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
Are you saying that none of the undocumented commands are capable of putting the device into a remotely exploitable state?
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.
The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes.
ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.
If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state, but that doesn't mean that nc or sh have RCE vulnerabilities, or that operating systems which allow installing nc and sh have RCE vulnerabilities.
nc and sh are well known and documented tools. Their existence on a system and running state can be inspected and the implications of various configurations is well understood.
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.
> If I run `nc -l 31337 | sh` that puts my system into a remotely exploitable state
Quick, before someone posts this to Mastodon and gives presentation at security conference with title:
Living off the Land: the Hidden Threat Within
If you need local access to enable remote access, it's not a RCE.
The exploit here is that you can reprogram new firmware onto the device.
The reason it's not important is that you require a physical connection to the target device. The exact same type of connection you use to program firmware in the first place.
The "backdoor" is just that there's now one additional way to program firmware with a physical connection to the chip. The only issue is it was never documented.
There's no potential for exploitation here. If you have physical access to a real serial port on one of these chips, you cab load your own firmware. That's it. That's the entire exploit.
It's meaningless nothing. It really only matters at all if you care about blocking unauthorized firmware updates over a wired serial connection. If you do care, there are options aplenty.
They say "backdoor might be possible via malicious firmware or rogue Bluetooth connections."
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.
Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE
In theory you probably should have low-level access to your attached BT radio itself, so this is just kind of expected, isn't it?
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.
Their slides in Spanish: https://www.documentcloud.org/documents/25554812-2025-rooted...
TL;DR: They reverse engineered the firmware and found HCI commands to do things like read/write memory, send packets, and set the MAC address.
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.
It's the researchers itself call it a backdoor. Here's the announce on their website, in English
https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
and set the MAC address
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... )
Don't you see how a random device with an Ethernet cord being able to change its MAC address and send arbitrary packets is a wormable threat actor?
...and then let it do the same but without the Ethernet cord requirement?
Drive around with a white van that says "Free Candy / BLE Persistent Threats"... pwn devices as you walk through the metal detectors on the way to China.
Wireless, wormable, arbitrary packets, spoofing arbitrary devices and you don't see the issue?
> Don't you see how a random device with an Ethernet cord being able to change its MAC
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.
It doesn't sound like it is wormable -- it doesn't allow any new attacks on external devices.
Your phone probably generates a random MAC every time you connect to WiFi.
Guess I'll see you in hacker jail
So everyone's fine installing opaque binary blob drivers which run in kernel space on their desktops and laptops and not even having root access to their own cloud-controlled phones, but some undocumented low-level ESP32 commands which require the device to already be compromised are a news-worthy threat vector.
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.
Someone's just living off the hype again. Scaring the uneducated masses and hurting the reverse-engineer community.
This is good research, but a bad headline. As an attack vector, this requires physical access and could already be done by other means in almost all cases. So, “undocumented commands found in common Bluetooth chip” would be a better headline.
I take this stuff might be interesting in hardware hackery way. Like legitimate way to get extra things out of existing hardware.
I was thinking the same thing, maybe for downloading locked firmware. Now that we know we can use LLMs to clean-room just about any code, extracting firmware from devices just because much more valuable.
I hate sensational stories like this. Now Espressif is gonna feel pressured to be even more closed.
It'd never have been an issue if this was documented.
because it was never supposed for user to use it. Do you document every private macro, every private function in your library to user ?
I feel like people that are concerned about this have never heard of a JTAG access port.
On most modern micro-controllers you can disable JTAG/SWD in production or gate access behind key verification. You can't disable undocumented commands. The issue here might be allowing persistent malware, like how some malware can hide in hard drive firmware. Unlikely, but still not good or indicative of good security practice.
Is JTAG undocumented?
This headline is a lie. A backdoor in a Bluetooth chip would be something which enabled a wireless attacker to gain code execution on the chip. This article reports on something which allows the device drivers of the attached device to gain code execution on the chip, which does not violate a security boundary.
(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.)
Got me think: it's time to end using binaries of assembler. Just some intermediate bytecode (can be 1:1 to assembly) and private VM that, for starters instruction whitelisting.
I know - 'if' (at minimum) on every asssembly instruction :> But there is no other way then that. Life.
FWIW almost nobody uses ESP32 for Bluetooth alone. This is primarily a Wi-Fi SoC. "Billion devices" is a ridiculous claim if most of them don't use BT features anyway.
The next world war seems like it’ll be about five minutes long. Nukes won’t be required to send us back to the Stone Age.
You mean all our devices refusing to work for us at a switch of a button?
One of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode. If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet. This would of course be coordinated with multiple underwater cable cuts.
It seems all too plausible, based on my admittedly limited understanding of how these devices work.
>One of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode.
This is a terrible conspiracy theory. Given how much Chinese IOT devices active in the West right now, the CCP doesn't even need to fly a balloon into the US. They can just pressure its IOT vendors to push a firmware update that broadcasts the DDOS signal.
>If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet.
At best it'll take down 2.4ghz communications, not the entire internet, or even all wifi networks. 5 Ghz/cellular networks will be spared because cheap chinese IOT devices don't operate in those frequency ranges, or the band is too wide for devices to jam. Moreover any important systems/institutions would presumably have hardwired connections, which are completely immune.
This is hilarious. Is there any evidence that such a "DDOS mode" has ever existed in any device?
wasn’t vo1d something which could potentially deliver in this?
No, of course there is no evidence, that's why it's a conspiracy theory. I can't remember if I saw it on a YouTube comment or a Reddit thread. Both are only slightly better than 4chan.
It sounds like more of a conspiracy fantasy to me if I'm being honest. The most attractive conspiracy theories in the US right now have nothing really to do with China but rather Russia instead.
No plausible attack described for a reason.
https://www.documentcloud.org/documents/25554812-2025-rooted...
It's unclear to me what a practical vulnerability/attack scenario would look like here.
A very far stretch: You have a ESP32 based Bluetooth dongle, that exposes its HCI interface to the host. You have already gained access to the host and can now load code to the dongle.
Not really a vulnerability, and many types of bluetooth dongle firmwares can be updated by the host...
Is this vuln. fixable via firmware or is the vulnerability inherent in the chip architecture?
It isn't really a vulnerability. You have to already have full access to the device to use the undocumented commands reported in the article.
Anyone want to start a Faraday cage laptop case company
Funny that I just pulled out an ESP32 dev kit a couple days ago and I honestly questioned myself with "how do you even know these things are secure at all?" Glad I know the answer now.
I'm starting to miss the days of being disconnected more and more as time goes on. This constant churn of having to monitor and lockdown everything you own down is becoming a complete negative.
EDIT: My Spanish isn't very good, but reading the slides it doesn't sound like the vulnerability is likely to be remotely exploitable, it sounds like it's only an issue if the chip is in HCI mode and being used as a bluetooth adapter. If someone who speaks Spanish could confirm I would be very appreciative.
With ESP32, always regard the vendor firmware only as proof-of-electrical-functioning. The first thing you should do with any ESP32 device after basic function test, is install ESPHome on it. If that's not possible, buy something different, where you can replace vendor fw.
Oh, I completely agree for IoT devices. When I was first reading the article I feared that the issue was something burned into the bluetooth radio binary blob, or something at the hardware level that would not have mattered whether you were running esphome or not. Upon a little deeper inspection, it doesn't sound like that's the case.
Espressif chips such as the ESP32 family are used for so many more applications than just smart home devices, which ESPHome targets.
e. g. it doesn't make sense to install ESPHome on an ESP32-based drone :)
Am I misremembering, or wasn't there some hubbub ca. 2010 where someone was going to do a presentation at CCC about how Bluetooth is basically swiss cheese in terms of security, and someone got all huffy about it and it was all hush-hush'd and the presentation cancelled?
Again, the hardware kill switch in my Librem 5 looks like a necessary feature.
So, what's next? Declare having "sudo" or "runas" a vulnerability?
Oh, wait, it's been already do... NO CARRIER
Can we please put "ESP32" in the title somewhere, so many people are going to miss this headline because it's so generic clickbait sounding.
Can we also take out "backdoor" from the title, because that word is very misleading.
Can any app running on an Android device with an ESP32 save code permanently to flash memory? Would an app have that level of access to send arbitrary low-level commands to the hardware?
No, unless the Android is already rooted, it is not possible to send vendor HCI commands.
Thanks!
garbage.
Someone on Reddit suspected this 3 years ago.
https://www.reddit.com/r/embedded/comments/wopjw8/how_sure_a...
Gotta say I expected this to be the wifi system. Most of the code on the ESP-32 is given as source, but the wifi driver is not.
https://github.com/esp32-open-mac/esp32-open-mac
the lower layers of both Wifi and Bluetooth on ESP32 family devices are closed as of this writing.
That doesn't match the article at all.
Anyone who has thought critically for a few seconds has suspected this. The question is whether you're right and if you can prove that.