Undocumented 'Backdoor' Found In Chinese Bluetooth Chip Used By a Billion Devices (bleepingcomputer.com) 71
"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.
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: (Score:3, 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)
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)
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:Huh? (Score:4, 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)
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)
How does one do that on an integrated circuit?
JFC Slashdot has declined....
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:1)
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.
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.
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: (Score:3)
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: (Score:3)
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 alrea
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: (Score:3)
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 h
Re: (Score:2)
You think someone's going to write a bluetooth morris worm...?
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:2, Funny)
Unclear (Score:4, 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:1)
I wouldn't be too sure about that. A backdoor implies that these rogue commands can be sent over Bluetooth. We're not simply talking undocumented API calls here.
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.
So how old is this? (Score:2)
It would be interesting to see when their CCP handler told them to put this in, obviously not in time to put it in hardware ... sloppy job.
Re: (Score:2)
Oops, took the fucking summary too seriously ... not remotely exploitable, not a backdoor at all.
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.
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?
Headphones (Score:1)
Of course it does. (Score:2)
Every Chinese product is going to have a backdoor so they can float a large balloon over their target and see if they can exploit their planted backdoors somehow.
I saw this day coming a mile off and found an alternative non-Chinese products to use. When does this behavior on China's part become unacceptable?
And people still want to install TikTok on their phones??
who cares...not important (Score:1)