Undocumented 'Backdoor' Found In Chinese Bluetooth Chip Used By a Billion Devices (bleepingcomputer.com) 127
"The ubiquitous ESP32 microchip made by Chinese manufacturer Espressif and used by over 1 billion units as of 2023 contains an undocumented 'backdoor' that could be leveraged for attacks," writes BleepingComputer.
"The undocumented commands allow spoofing of trusted devices, unauthorized data access, pivoting to other devices on the network, and potentially establishing long-term persistence." This was discovered by Spanish researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco of Tarlogic Security, who presented their findings yesterday at RootedCON in Madrid. "Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices," reads a Tarlogic announcement shared with BleepingComputer. "Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls...."
Tarlogic developed a new C-based USB Bluetooth driver that is hardware-independent and cross-platform, allowing direct access to the hardware without relying on OS-specific APIs. 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. In total, they found 29 undocumented commands, collectively characterized as a "backdoor," that could be used for memory manipulation (read/write RAM and Flash), MAC address spoofing (device impersonation), and LMP/LLCP packet injection.
Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake.
Thanks to Slashdot reader ZipNada for sharing the news.
"The undocumented commands allow spoofing of trusted devices, unauthorized data access, pivoting to other devices on the network, and potentially establishing long-term persistence." This was discovered by Spanish researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco of Tarlogic Security, who presented their findings yesterday at RootedCON in Madrid. "Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices," reads a Tarlogic announcement shared with BleepingComputer. "Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls...."
Tarlogic developed a new C-based USB Bluetooth driver that is hardware-independent and cross-platform, allowing direct access to the hardware without relying on OS-specific APIs. 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. In total, they found 29 undocumented commands, collectively characterized as a "backdoor," that could be used for memory manipulation (read/write RAM and Flash), MAC address spoofing (device impersonation), and LMP/LLCP packet injection.
Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake.
Thanks to Slashdot reader ZipNada for sharing the news.
Huh? (Score:2, Insightful)
Re:Huh? (Score:5, Interesting)
This is just silly, it is not a remote exploit, you have to load code on the device to do it. It's an MCU! If you can load code you can do anything you please.
Re:Huh? (Score:4, Insightful)
all code running on an ESP32 uses Espressif's BT MAC layer.
This means every ESP32 is vulnerable to these commands being issued by any BT speaker within range of it.
It very much is a remote exploit.
You are correct, that if you don't use Espressif's binary blob to run your Wifi and BT (and therefor don't have Wifi and BT), then it's not exploitable.
Not really sure what your point there was though.
Re:Huh? (Score:4, Insightful)
Their verbiage strongly indicates remote vulnerability- after all, they're talking about their project for vuln testing using C# (which notable does not run on an ESP32**), but non-Tarlogic reporting does seem to specifically mention ocpode 0x3f, which is the HCI vendor-specific opcode.
That being said, BLE also uses opcodes, and allows connection-less interaction, which is why it seemed like this all lined up as a remote exploit.
i.e., firmware accepts BLE packets with certain opcode set, operates on device.
We need technical details.
Re: (Score:3)
I think the telling factor here is that there is a lot of flowery language in this whole thing and no actual details. There is not even a clear "can be exploited remotely". It seems there are some undocumented BT commands in the _local_ API and that would not even be a "backdoor".
Re: (Score:2)
I think the telling factor here is that there is a lot of flowery language in this whole thing and no actual details.
Ya. Guys who do this are weird, though. I've learned not to judge too much.
There is not even a clear "can be exploited remotely".
There isn't, I agree.
It seems there are some undocumented BT commands in the _local_ API and that would not even be a "backdoor".
Oh, I couldn't disagree with you more.
After spending the better part of the evening ripping apart the firmware, these commands are in the software implementation of the BT controller in the mask ROM. When client software that has been programmed to the device (Arduino, ESP-IDF, whatever-) are talking HCI to the BT "controller", they're actually talking to code running on the mask ROM.
This code has unfettered ac
Re: (Score:2)
It seems there are some undocumented BT commands in the _local_ API and that would not even be a "backdoor".
Oh, I couldn't disagree with you more.
Only on terminology. A "backdoor" can be accessed from outside (and is delivered with the system). There may well be malware in the ROM that cannot be accessed from outside, but can be triggered by having the user program do a call with specific data, for example and then opens a backdoor later. This still needs help form the user code and that makes it in itself not a backdoor. It can still be a massive security problem, obviously.
But my take as to why the BT controller has full memory access is just lazy
Re: (Score:2)
Only on terminology. A "backdoor" can be accessed from outside (and is delivered with the system). There may well be malware in the ROM that cannot be accessed from outside, but can be triggered by having the user program do a call with specific data, for example and then opens a backdoor later. This still needs help form the user code and that makes it in itself not a backdoor. It can still be a massive security problem, obviously.
Well, the "wtf HCI" commands are definitely delivered with the system. They're literally burnt into the CPU.
As for whether or not any of it can be triggered from the outside is an open question. One I'm not willing discount given the nature of the strange HCI commands.
Even in the case where it can't be triggered directly remotely, that doesn't leave out the possibility for a combined attack.
For example,
A BLE PDU is forward to the BT user stack, which due to a bug in it, or malicious code, then forwards
Re: (Score:2)
So, in light of the... frankly fucking weird HCI commands in the command table, assuming that the EVT side doesn't have "extra" processing, would be a mistake.
What commands are so weird?
How about this one: 0xFC0A Write NVDS Parameter
Or maybe: 0xFC12 Read memory info
Here's a list of TI's CC13x2 Vendor Specific Commands: https://software-dl.ti.com/sim... [ti.com]
TI has better documentation than Espressif.
And in that list we see 0xFE82 UTIL_NV_Write and 0xFE87 UTIL_GetMemStats
I fail to see what is so strange about these vendor specific HCI commands. TI has some of the same ones in their controller.
Re: (Score:2)
What commands are so weird?
How about this one: 0xFC0A Write NVDS Parameter
Or maybe: 0xFC12 Read memory info
Oooh, we're lazy, aren't we?
How about this one, 0xFC02: Write memory.
Or this one, 0xFC07: Write flash.
And in that list we see 0xFE82 UTIL_NV_Write and 0xFE87 UTIL_GetMemStats
Those directly alter settings on the BT controller. For example, putting the radio to sleep.
But you know that, because you read the docs, right?
And ya- getting the status of the heap of the BT controller is totally the same as reading and writing memory unbounded across the entire SoC.
ESP32 Write flash and write memory aren't talking about BT hardware in this instance- they're talking about your ESP32.
Re: (Score:2)
Oooh, we're lazy, aren't we?
How about this one, 0xFC02: Write memory.
Or this one, 0xFC07: Write flash.
You mean like command 0x0003 in Analog Devices BLE controller? https://analog-devices-msdk.gi... [github.io]
That's a write memory command. They gave it the wrong name. Must be part of a backdoor, being so weird and hidden with the wrong name. You should go write a click-bait article on it full of your made up crap.
And TI's 0xFC0A command is a Non-Volatile write. That means to flash.
If you had any experience actually using HCI commands or writing a BLE host, you'd know all BLE controllers have commands like this.
Re: (Score:3)
We're discussing a backdoor on a device with an enabled radio. Why is it you think one needs to get into your network to trigger it?
Re: (Score:2)
lol. Did you, now.
We're discussing a backdoor on a device with an enabled radio. Why is it you think one needs to get into your network to trigger it?
Because what they described is a set of undocumented proprietary commands in the HCI interface, not the wireless interface.
Re: (Score:3)
I began my career with my fresh bachelor's degree in embedded software design.
So,
You have a device.
On this device runs some code that you cannot verify.
This code controls the radio on the device (BT, wifi)
Your interface to said radio is via 2 layers of abstraction.
And you think someone needs to be connected to the same network as you to interact with the lower layers?
Re: (Score:2)
>And you think someone needs to be connected to the same network as you to interact with the lower layers?
No. I think that is a prerequisite. You have to break a bunch of other things too. In the case of my network, that would be home-assistant, which probably has holes but I make it more difficult than a default install.
Then you would need to use residence on HA to mess with the code on the attached devices which would be easy because HA updates firmware on the devices all the time.
A resourceful hacker
Re: (Score:2)
If there is, indeed, a backdoor in the radio, you don't need your network at all. You just need a way to interact with the radio. You use the radio in the context of a "network", but the radio itself deals only in packets.
If there is, indeed, a backdoor in the radio, your network does not matter to it. It would be triggered by something like a BLE PDU, or an 802.11 control frame.
From there on forward, the ESP would be considered compromised, and the depth of that compromise w
Re: (Score:2)
The published attack is not an attack via the radio interface.
If it were, then it would be a big problem for anyone.
Since I had a hand in the design of the security protocols of 802.11, 802.16 and Bluetooth, I'm familiar with how a vendor might put in a backdoor on the wireless side. A competent one could do it without it being easy to detect. It's a good thing I didn't put a backdoor in the products I've been involved in.
Re: (Score:2)
Their verbiage strongly indicates remote vulnerability
You quoted that, and then said:
To get at the ESP32s in my house you would first have to get into my network. I happen to have worked in security and cryptography for many years, so good luck with that.
If it were, then it would be a big problem for anyone.
I'm glad you understand, now.
Since I had a hand in the design of the security protocols of 802.11, 802.16 and Bluetooth
No, you didn't.
Fuck off, now.
Re: (Score:2)
Since I had a hand in the design of the security protocols of 802.11, 802.16 and Bluetooth
No, you didn't.
Fuck off, now.
Read the 802.11 spec and the 802.16 spec and you will see my name there in the list of contributors. It was several years of my career working on wireless communication protocols followed by several years solving the problems with randomness in those protocols.
The verbiage was on a slide presentation where the 'security' company were claiming they found a back door with remote access. They did not. I saw the headline, read the slides, then it took a couple of days for to dig in
Re:Huh? (Score:5, Interesting)
False. Expressif's BT layer doesn't have the ability to issue arbitrary commands by itself. You'd need to discover an additional exploit for that to work.
This isn't a remote execution here, this is a potential supply chain attack. It literally relies on programming the device with the malicious code.
Re:Huh? (Score:4, Insightful)
False. Expressif's BT layer doesn't have the ability to issue arbitrary commands by itself. You'd need to discover an additional exploit for that to work.
Huh?
It's a blackbox BLE MAC.
It's *perfectly* plausible that it's capable of issuing commands by itself, particularly in response to specific BLE packets. You frankly have no fucking idea what it's capable of.
I've gone over their presentation, and this is weird as fucking hell. Suspicious as fucking hell. The firmware has HCI commands to read and write memory and flash, and to query the running FreeRTOS kernel.
Re: (Score:2)
It's certainly possible for the binary BLE controller to do things on its own. But the controller receives HCI commands from the host. That's what HCI stands for, host controller interface.
The host has full source. It's not even written by Espressif. You can use bluedroid or nimble.
So what would be the point of adding commands to let the host tell the controller to do things as part of a backdoor hidden in the controller? The controller doesn't use the HCI commands to do things. It acts on them when t
Re:Huh? (Score:4, Insightful)
It's certainly possible for the binary BLE controller to do things on its own. But the controller receives HCI commands from the host. That's what HCI stands for, host controller interface.
It's not quite that simple, and that's why this is so strange.
These HCI commands are in the FreeRTOS binary blob.
The controller, in this instance, is an block on the SoC.
The host has full source. It's not even written by Espressif. You can use bluedroid or nimble.
Bluedroid and Nimble talk to the binary blob running in FreeRTOS. That's the controller for them- not the hardware.
So what would be the point of adding commands to let the host tell the controller to do things as part of a backdoor hidden in the controller? The controller doesn't use the HCI commands to do things. It acts on them when the host tells it to.
The controller is part software, part hardware- it's a SoftMAC.
And that SoftMAC is an opaque blob. I've started tearing it apart (I have an extensive history in reverse engineering).
We'll see wtf is going on here, but it's very strange that the HCI command table includes these encodings.
It's perfectly possible that HCI EVTs coming from the actual hardware controller can also trigger these commands.
Re: (Score:2)
Better identified.
The "controller" (from the HCI perspective) is actually in mask rom. Below FreeRTOS. So these HCI commands (still investigating if anything in the EVT chain calls back to them) are literally not optional, and a part of every single ESP32 part.
Re: (Score:2)
Hmm...opaque? So no original 'source' code but the binary can be reverse-engineered with well some (probably a lot but that's nothing for OSS) of effort but opaque it is not. Not impossible, It took me 2 weeks to trace a race condition in mutex code on an rtos to which I had no code, just binary blob. So anything is possible.
Re: (Score:2)
Hmm...opaque? So no original 'source' code but the binary can be reverse-engineered with well some (probably a lot but that's nothing for OSS) of effort but opaque it is not.
Good job redefining that word to the point where literally nothing applies to it anymore.
Not impossible, It took me 2 weeks to trace a race condition in mutex code on an rtos to which I had no code, just binary blob. So anything is possible.
It is of course possible to trace opaque references in code. And yet they're still opaque.
Re: (Score:2)
Fine. You are technically correct, "opaque" as you can see the light though but not much more...
Point being, the way it's used here was as if it was impossible to decipher what the code is doing.
So I did not redefined this, the summery did.
Re: (Score:2)
Regardless, compiled code is not generally referred to as easily readable, understandable, or transparent.
There is, after all, a reason it's distributed as a binary rather than as source.
Re: (Score:2)
It's not quite that simple, and that's why this is so strange.
These HCI commands are in the FreeRTOS binary blob.
That's not true. I've actually developed products that use ESP32s. I've even done some reverse engineering on those binary blobs to implement RF coexistence between BLE and another RF system, since none of the documented APIs support any of the necessary features.
FreeRTOS is open source and part of the code included in ESP-IDF. The controller is a task that runs under FreeRTOS. Though I think there is a mode where one dedicates a CPU core to the controller, on those ESP32 devices with two cores, and Fre
Re: (Score:2)
That's not true. I've actually developed products that use ESP32s. I've even done some reverse engineering on those binary blobs to implement RF coexistence between BLE and another RF system, since none of the documented APIs support any of the necessary features.
If you had literally read one more message down, you would have seen that I had identified it as being in the mask ROM.
FreeRTOS is open source and part of the code included in ESP-IDF. The controller is a task that runs under FreeRTOS. Though I think there is a mode where one dedicates a CPU core to the controller, on those ESP32 devices with two cores, and FreeRTOS doesn't manage the controller.
That adds up with what I've seen.
There's a performance issue with code in flash memory (which a library compiled into the FW would be), since the ESP doesn't have built in flash on the processor's data bus. It's an external SPI flash chip in all cases, which means possible long latencies when a cache miss causes the flash controller to need to read a block over SPI. Not something a timing critical part of the BLE controller can tolerate. The way around this is to copy the code that can't tolerate flash cache misses from flash into RAM, but there is very little RAM, especially on the OG ESP32. So they add ROM that doesn't have a cache miss issues to hold some of the code. ROM is much cheaper than RAM in a microcontroller.
This is mask ROM on the CPU. It's not connected via SPI. It's directly attached to the address bus.
It is always zero-cycle. There's nothing faster than it.
You seem to be confusing it with Flash.
Depending on the ESP32 device, the controller code is either in the mask ROM and/or as a binary library file shipped with ESP-IDF. The older ESP32 appears to have more in the ROM while the newer chips like the ESP32-C6 have less ROM and use more libraries.
No. It's in the ROM there as well.
No, bluedroid or nimble run as a task under the open source FreeRTOS kernel. They talk to the binary blob using a virtual HCI interface. It's not even a binary blob. They ship .a libraries that don't even have symbols stripped for the non-open-source code.
The client libraries are libraries.
Yes, they talk via VHCI... to the binary blob... what teh fuck is your point?
That's literally
Re: Huh? (Score:2)
You aren't nearly as knowledgeable as you think you are. I doubt you've ever programmed any microcontroller on your own outside of a class room. Maybe, if you thought about what those with experience said instead of attacking them for not parroting your fantasy, you would learn something.
Re: (Score:2)
No, the host won't do that. Unless the person who wrote it has chosen to do that. What you're missing is that the host is entirely open source. ESP-IDF has two choices, Bluedroid or NimBLE, neither of which is written by Espressif. When you make something with an esp32, you compile it from source.
Re: (Score:2)
Everything is plausible when you make up additional hitherto unknown vulnerabilities to make your case possible. As it stands nothing in this presentation points to a remote attack over bluetooth being possible.
Re: (Score:2)
Indeed. Grandstanding on nothing. They probably want to push their product and are not above lying. Incidentally, on an e1000 Intel card, for example, I can change the MAC-address easily via software on Linux. Found this out after I changed it in hardware for a demo to a customer 10 years ago or so. (EEPROM replacement, a few hours work because it needed to look pretty.)
Re: (Score:2)
Not necessarily as different from your average server as one might like(even on linux systems with mainline compatible hardware it's totally unremarkable for there to be several DMA-capable peripherals, often ones with external network connectivity, running big chunks of blackbox firmware); but much of the wifi and BT behavior is basically off doing its own thing
bruh (Score:2, Insightful)
We're not talking about the existence or non-existence of a vendor blob and I don't need a hyperlink to tell me what a vendor blob is. The point is, as a manufacturer of IoT you put an ESP32 into a device to do something like turn a light on and off or make a lock work. The entire device is under the control of the light/lock manufacturer. There is no method for someone else to log into the device and upload code and thereby do anything the light/lock manufacturer does not want to be done.
While there are ce
Re: (Score:2)
My point of view is more like, so the ESP32 doesn't cryptographically lock down the device and someone could write new firmware to use the device in new and different ways? GOOD.
It can be configured for a secure boot system both at startup and for firmware updates, with the key set at Espressif's manufacturing.
The OTA system can also require a signature even without the secure boot system, but that approach still allows firmware updates through wired connections and chip proframmers.
That is why this is mostly a supply chain attack. It is not about reprogramming a random unsecured chip, which is trivial with physical hardware access, and very nearly trivial through unsecured OTA u
Re: (Score:2)
It's also not as big a deal as the headlines make all. To a good approximation, all BT devices/IP blocks are full of implementation bugs and holes. Try fuzzing one some time, it's very, very difficult to actually get to an exploit because almost anything out-of-spec you send it simply crashes or hangs the device. This doesn't make them safe, you can probably turn a lot of those crashes into exploits if you look hard enough, but is merely pointing out how bad this stuff is.
Cellular basebands are another
Re: (Score:2)
Try fuzzing one some time, it's very, very difficult to actually get to an exploit because almost anything out-of-spec you send it simply crashes or hangs the device. This doesn't make them safe, you can probably turn a lot of those crashes into exploits if you look hard enough, but is merely pointing out how bad this stuff is.
On one hand, it might take jillions of tries to find an exploitable failure. On the other hand, you can get devices for next to nothing in quantity and they use next to no power, so you can reasonably make many attempts at once...
But forget fuzzing, because the real concern is that none of that is necessary, and a hypothetical attacker would be working in concert with the party who inserted the back door. This functionality being in the bluetooth firmware part of the binary blob on the device means that th
Re: (Score:2)
Re: (Score:2)
If it's an ESP32 specifically you don't presume to own the whole device. Most of the RF stuff is a vendor blob [ugent.be] talking to undocumented hardware.
While this is entirely true, it's also true for most or all other BT devices. I've developed products with Nordic and ST chips that have BLE, in addition to Espressif, and both those companies' products also ship the BLE controller as a binary only component of the software stack. They are actually more obfuscated than Espressif's binary code. ST's is fully encrypted so you can't even disassemble it. Espressif's isn't encrypted and even has an unobfuscated symbol table in the library.
I'm not aware of an
wat (Score:5, Insightful)
Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake.
A back door is meant to be accessible, you're just not meant to know about it.
Re: A back door is meant to be accessible (Score:2, Funny)
That's what your mom said!
(Sorry.)
Re: (Score:2)
Yes, and then there's this quote:
"Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls...."
Exploitation of such an interface could allow an attacker with bluetooth access to an ESP32 device to gain control of that device. The rest of this is inflammatory horseshit. Computers and mobile phones do not use ESP32, IoT devices do, and
Re: (Score:2)
The article is a word salad, but it sounds like some guys wanted to hype their presentation at a hacker conference.
Re: (Score:2)
Clearly they want to promote the capabilities of their product, but it does seem like a previously unknown vulnerability.
Re: (Score:2)
Well, they found unknown features. They might be a vulnerability. Calling it a backdoor seems quite a stretch, and I don't think I'd worry about it "permanently infecting" my medical equipment "by bypassing code audit controls."
Re: (Score:3)
The claim was that it would "would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls."
Their presentation is in Spanish (you did look at it, right?) but they include Python code snippets that illustrate their findings.
Re:wat (Score:5, Informative)
>> Computers and mobile phones do not use ESP32, IoT devices do, and many of those do not enable bluetooth
I've done a fair amount of work with the ESP32. The device comes with an embedded RTOS, some black box firmware that runs all of the peripherals. You write code that interfaces with the RTOS via a set of 'documented' entry points, and that is how you indirectly access the Wifi and bluetooth functionality. These guys have discovered that there are a lot of undocumented commands that would presumably let a malicious programmer do the things that were described in the article.
So the 'smart switch' you bought on Amazon that you plug into a wall socket and lets you control a lamp with Alexa or your cellphone could have shipped with some additional hidden functionality that sniffs out Bluetooth clients and masquerades as something it isn't. According to them it could then be "carrying out attacks of identity theft of devices" and "infer personal data such as names, addresses or telephone numbers".
Re: (Score:2)
You could do most, if not all that stuff without this hack. Flipper Zero can do things like spoofing other devices.
The reason the ESP32 is that way is because it's the only way to get WiFi/Bluetooth certification and be legal to sell in most countries. The software stack has to enforce things like legal limits on duty cycle and transmit power.
Re: (Score:2)
No doubt there are other ways to do it but as the article says, the ESP32 is "used by over 1 billion units as of 2023". Some of them may be in your house and attached to your WiFi network.
Re: (Score:2)
Okay but this hack does nothing to affect the ones in your home already. The only way anyone could make use of it is to replace the firmware with their own, at which point it's already game over.
Re: (Score:3)
The danger here is that the people who made the devices in your home were aware of the undocumented entry points and included code to exploit them. Or they became aware of the exploits later and implemented snooper code in a software update.
For example, you buy some cheap 'smart' wall socket outlets on Amazon like the ones below, "trusted by over 5 Million users worldwide". You give them WiFi access to your home network and can turn lamps on and off with Alexa or your smartphone. Unbeknownst to you they als
Re: (Score:2)
Nordic's Bluetooth chips have a powerful Bluetooth capture mode that gives you all the detail you could possible extract. The ESP32 actually lets you capture most of it with the normal APIs anyway. So there very likely isn't any real benefit as far as data capture goes.
Ditto for exploits. If they exist in other devices, the public APIs are enough to exploit the, and again Nordic basically lets you send arbitrary packets anyway.
The only use these APIs have is to gain more control over the Bluetooth stack, al
Re: (Score:2)
>> there very likely isn't any real benefit as far as data capture goes
It is more than that; "memory manipulation (read/write RAM and Flash), MAC address spoofing (device impersonation), and LMP/LLCP packet injection". And while there may very well be other devices that can perform attacks, are they present in more than 1 billion units?
"In a context where you can compromise an IOT device with as ESP32 you will be able to hide an APT inside the ESP memory and perform Bluetooth (or Wi-Fi) attacks agains
Re: (Score:2)
Memory manipulation? You have to control the firmware before you can exploit those things anyway, so the only additional functionality it brings it to modify the closed source Bluetooth/WiFi stack memories. Which again, doesn't get you any more than Nordic offers freely anyway.
For persistence, that only matters if the user is likely to reflash the firmware in an attempt to remove malware, which is vanishingly unlikely. Most users will have no clue about that, and will just use the product as it came from th
Opaque drivers (Score:2)
Mista Puhtayduh Head! (Score:2, Funny)
Re: (Score:2)
A back door is meant to be accessible, you're just not meant to know about it.
Honestly calling this a back door is just silly. You need to have access to program the device in order to do anything. Supply chain attacks are not usually classed as back doors.
Re: (Score:2)
Actually, a "backdoor" not accessible from _outside_ of the system is not a backdoor. Seems somebody is lying by misdirection here to push their product.
Re: (Score:2)
Seems somebody is lying by misdirection here to push their product.
I take it then that you've reviewed their work, and have determined that none of this functionality is accessible from off device via bluetooth? Could you provide a link to some materials which show that? The article doesn't do so, nor does their press release.
Re: (Score:2)
Oh, I have seen enough people lying in this fashion that I place the onus of proof completely on them. And, incidentally, so would any self-respecting scientific venue.
People that do not clearly state things in this space are typically a) lying and b) want to sell you something.
Re: (Score:2)
Now that I've had the opportunity to review the released materials, I agree.
However, certification is exactly what I'm thinking of when I think this is either a spectacular screwup or in fact is an intentional part of a back door.
Having these undocumented functions in the Bluetooth radio code is surely a no-no in terms of certification approval, especially as they could be used for nefarious purposes by someone who successfully attacks the bluetooth driver.
Leaving them in there if you're not using them is o
or perhaps another explanation (Score:3)
"Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake."
If they're going to call this a backdoor, they're already saying that it was neither a mistake nor not meant to be accessible.
But we need to call it a backdoor because it's a Chinese company.
Re: or perhaps another explanation (Score:2)
CVE? (Score:5, Insightful)
Re: (Score:2)
They don't appear to claim that the undocumented features are actively being used in exploits, just that they could be.
Re: (Score:2)
I’m not claiming that you are planning to murder your neighbor but you could be.
Re: (Score:2)
The latter it seems, and to be fair the actual talk doesn't seem out pitch it as a vulnerability, just a useful bit of exploration that opens up new functionality.
Re:CVE? (Score:5, Informative)
Re: (Score:2)
Looks like "nothing-burger". Looks like not even a backdoor. Just some locally usable undocumented commands. Hence not even a security problem.
No other explanation (Score:5, Interesting)
It's intentionally placed.
Bluetooth circuits are usually licensed for pennies per million by the same companies that sold you the EDA tools (Cadence, Synopsys, etc).
So then why?
Sell at a loss, get placed in all the cheap phones, tablets, PCs in Asia, have instant backdoor access with a simple "knock-knock' packet.
Re:No other explanation (Score:4, Interesting)
Yeah, except given that it's not remotely executable without making up "knock-knock" in your head (the story mentions nothing about such an exploit), it doesn't track.
When I make up all sorts of things I also make sure there's no other explanation. But back in reality the big risk here is a supply chain attack. That is actually incredibly boring since if you can execute a supply chain attack it really doesn't matter if you use an undocumented API or not. It's like a vulnerability which requires you to already have root access. As it stands you can already replace the entire OS the ESP32 ships with, so an equally risky supply chain attack would be writing your own OS that mimics the behaviour of the one the ESP32 ships with and put something malicious in there. In any case you need device access to load some firmware onto it.
Think you're seeing data where noise exists. (Score:2)
Or claimed data because of a lack of imagination.
When creating a product you often put in methods to access data. Test support plumbing that might not be easily removed at the end (how can you test the final product if you're missing required parts?).
My guess is they found something like that. Sometimes security is 'by obscurity'. A poor policy choice, but not uncommon.
Or yeah, maybe it's a backdoor used by someone else (heck I'll bet the US and EU would frame China).
Re: (Score:2)
Only problem: On closer inspection, this is not a backdoor and not even really a vulnerability at all. All you can apparently do is give the ESP32 locally some undocumented commands.
I'm not surprised. (Score:3)
I think this requires rouge software on the device (Score:3)
Summary is misleading by giving the impression that devices that are not already compromised by malicious software are vulnerably to Bluetooth attack when this is probably not the case.
From the https://reg.rootedcon.com/cfp/... [rootedcon.com] article
"
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.
This is especially the case if an attacker already has root access, planted malware, or pushed a malicious update on the device that opens up low-level access.
In general, though, physical access to the device's USB or UART interface would be far riskier and a more realistic attack scenario.
"
So these chips are probably not vulnerable to Bluetooth attacks unless the device is already infected with rogue software.
There may be a vulnerability to local USB attacks which I guess would most likely be from police(or government intelligence agencies) trying to unlock/compromise a suspects phone.
Re:I think this requires rouge software on the dev (Score:4, Interesting)
So these chips are probably not vulnerable to Bluetooth attacks unless the device is already infected with rogue software.
That's how I read this. However, the article states "remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections." Without at least the slides, let alone a proper paper, it's hard to comment intelligently on this reporting. If it's possible to gain access to some of this functionality via malformed packets which can be generated with some of these undocumented commands, then it could be used to add a persistent threat to the firmware of esp32 devices. If you had just one compromised device in your home, it could spread an infection to all of the other esp32 devices.
Re: (Score:2)
You think someone's going to write a bluetooth morris worm...?
Re: (Score:2)
You think someone's going to write a bluetooth morris worm...?
As I stated above, there's not enough information here to know how difficult it would be, so guessing at the plausibility is futile. However, that's a lot of devices, so it might be worth it to spend some effort. And the barrier to entry is very very low, you can get a whole pile of devices to experiment with for very very little money and the development tools are free.
Re: (Score:2)
I see someone posted the CVE# (CVE-2025-27840 [nist.gov]) in another comment, there are some links there including the link to the slides [github.com] (and then some useless stuff.)
I've only given them a skim so far, as I haven't translated the pdf yet and I only know about enough Spanish to order food.
Re: (Score:2)
Having now read the slides (After taking a lengthy detour through installing LibreTranslate and Linguist bc why not) I can say that there was no evidence presented therein that this functionality includes a means of accessing these functions via bluetooth.
Therefore I agree with those who have stated that this functionality by itself does not constitute a back door.
However, these functions being available in the bluetooth firmware is extremely suspicious because it means that with access to no other part of
Re: (Score:2)
Yep. Not a backdoor. A compromised device can compromise a connected ESP32 _locally_. That is not even interesting. That is _expected_ behavior.
Shocked (Score:4, Funny)
Unclear (Score:5, Informative)
It's not that this is a backdoor at all. There are undocumented functions, but you need to have some malicious software already running to make use of them. That's true of the documented functions too. The linked article reads more like an advertisement.
Re: (Score:2)
Indeed. And undocumented commands in the ESP would only be a backdoor if they can be called from _outside_ directly. Otherwise this is local functionality and does not allow you to break in and hence is not a backdoor.
I think the lack of detail information is telling. These people are probably trying to push their company by what is essentially lies.
I hope Expressif responds by suing these failures (Score:2)
2. After looking at it, it doesn't do 1/1000th of what they say, so they're either liars, or in marketing. Either way they should be used as ballast on the next Starship launch.
3. If this is this amazing, where's the CVE?
4. Who's independently confirmed this?
5. Who cares?
6. I hope Expressif responds with an IBM of lawyers. These people disgust me.
Yes, an IBM is a quantity of la
Re: (Score:2)
I hereby officially claim that you intend to murder your neighbor. Nothing you can do, it is free speech.
Re: I hope Expressif responds by suing these failu (Score:2)
You mean test mode? (Score:2)
Seems like a bug in flashing or test mode.
To be clear... (Score:2)
Seems like a bug in flashing...
I meant a mistake in creating the firmware flags answer for their exact device, maybe (like by whoever used the ESP32, or the researcher looking for problems to report).
Good Grief (Score:2)
The quality of security alerts has gone WAY down.
This appears to be (after removing the panicy crud) a report that the CPU (in the micro-controller) can issue undocumented commands to the softMAC built in to the micro-controller.
The wild panic is apparently that *I* might be able to load firmware on my own device that could potentially attack OTHER vulnerable devices, and NOT that other devices might use those commands against me.
That's like sayong OH NOES, root might be able to do this complicated dance wi
Re: (Score:2)
Yep, my impression as well. If so, this is a total non-story. Even the "backdoor" claim would be a lie, because a backdoor must, by definition, be accessible from outside the security perimeter of the affected device.
this is clickbait FUD (Score:2)
Now, if it would have been a "documented backdoor" (Score:2)
Who writes these deranged headlines? Backdoors are _always_ undocumented.
As to the actual story: Is this commands that can be sent to an ESP32 over Bluetooth or are these local commands? The referenced story does not tell, which is very suspicious. My guess would be these are local commands and then the whole thing does not matter and is just one company trying to generate business by misdirection and FUD.
Does anybody have more info?
Clickbait article (Score:2)
Useful feature, not a bug (Score:2)
These commands are executed from HCI pipe, not radio end. There are no exploit scenarios, as the HCI host has full control in any case. It's about as much of a "backdoor" like a wifi radio with hacked (or similarly permissive) firmware to inject raw frames. If anything it makes the chip moderately more useful now.
Re: (Score:2)
How does one do that on an integrated circuit?
JFC Slashdot has declined....
Re: (Score:2)
Oops, took the fucking summary too seriously ... not remotely exploitable, not a backdoor at all.
Re: (Score:2)
There's nothing preventing you from having multiple wifi networks in your home these days, now that there are all these different bands and routers are cheap, it's fairly convenient. You can have a 2.4GHz network for your IoT crap and some other network keeping it segregated from your other equipment. You could even do it on the same router, though as cheap as they are now, I would opt for more separation.