Undocumented 'Backdoor' Found In Chinese Bluetooth Chip Used By a Billion Devices (bleepingcomputer.com) 95
"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:1, 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)
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:1)
You're obviously clueless about this stuff (I don't think you even bothered to google that stuff properly -- much less learn how to program an ESP32).
Aren't you ashamed to keep posting garbage and upvoting yourself with sockpuppets?
Re: (Score:2)
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)
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 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: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: (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: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.)
No BACKOOR UPDATE (Score:1)
https://darkmentor.com/blog/es... [darkmentor.com]
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)
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: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:2)
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
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:1)
This is the most ridiculous claim the "researchers" made.
The control opcodes and registers the researchers found were neither meant to be inaccessible nor left in by mistake. They were just undocumented, because Espressif expects integrators to use the provided protocol stacks. Building half of a radio in software is Chad-level engineering, presents numerous challenges for certification, and would be a nightmare to provide tech support for. Nobody bothered reverse-engineering the provided protocol stacks be
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: (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: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:3, 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: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:1)
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.
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?
Headphones (Score:1)
Of course it does. (Score:1)
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)
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.
Refutation of backdoor claim by a Bluetooth expert (Score:1)
Both Tarlogic and BleepingComputer have subsequently updated their press release / article to say it's not a backdoor, it's "hidden commands", which is accurate (but common in the field.)
Clickbait article (Score:2)
Update: no backdoor (Score:1)
Not a backdoor, but bad design, common to most BT chip manufacturers.
Not a problem for cheap IOT design, but on systems with multiple trust levels.
https://darkmentor.com/blog/es... [darkmentor.com]