Undocumented 'Backdoor' Found In Chinese Bluetooth Chip Used By a Billion Devices (bleepingcomputer.com)
- Reference: 0176653479
- News link: https://hardware.slashdot.org/story/25/03/08/2027216/undocumented-backdoor-found-in-chinese-bluetooth-chip-used-by-a-billion-devices
- Source link: https://www.bleepingcomputer.com/news/security/undocumented-backdoor-found-in-bluetooth-chip-used-by-a-billion-devices/
"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 [2]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 [3]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 [4]ZipNada for sharing the news.
[1] https://www.bleepingcomputer.com/news/security/undocumented-backdoor-found-in-bluetooth-chip-used-by-a-billion-devices/
[2] https://reg.rootedcon.com/cfp/schedule/talk/5
[3] https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-devices/
[4] https://www.slashdot.org/~ZipNada
So before all you a merkins jump in claiming they (Score:1)
stole it from you Please answer one question - was the back door already in when they stole it or placed in later ?
wat (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.
A back door is meant to be accessible, you're just not meant to know about it.
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)
> 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. ...
> In general, though, physical access to the device's USB or UART interface would be far riskier and a more realistic attack scenario.
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:3)
> 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 presumabl
Opaque drivers (Score:2)
My concern is that the drivers are provided as blobs, and so there may be equivalent back doors in the WiFi PHY/stack. I think that there is a lot more visibility on WiFi, so it would be hard to hide a command and control system for years, but the CCP has a lot of patience.
Mista Puhtayduh Head! (Score:3)
Mista Puhtayduh Head! Backdoors are NOT secrets!
or perhaps another explanation (Score:2)
"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)
It's also not uncommon for chips to have undocumented circuits used for diagnostics at the factory either.
CVE? (Score:5, Insightful)
Is there actually a CVE, or is this just an advertisement for a nothing-burger?
Re: (Score:2)
They don't appear to claim that the undocumented features are actively being used in exploits, just that they could be.
No other explanation (Score:3)
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.
I'm not surprised. (Score:2)
While they're at it, I suspect there are backdoor commands on the ESP 8266, or Teensy, or other microchips made in the same country. Maybe still OK to use for game controllers, toy robots, music generators, but I'd be extremely wary about using them for anything mission critical like door locks, or anything that can connect to your network.
I think this requires rouge software on the device (Score:2)
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 [1]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 ma
[1] https://reg.rootedcon.com/cfp/schedule/talk/5
Re: (Score:2)
> 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
Shocked (Score:2)
I'm [1]shocked, shocked [youtu.be] to find out that spying is going on in here.
[1] https://youtu.be/vxnpY0owPkA?t=26
Huh? (Score:1, Insightful)
It's not a fucking server chip. If you're running code on the chip the presumption is that you control the whole device. You can impersonate MAC addresses? Who the fuck cares. If the device ain't paired you aren't getting access to the data (subject to the strength of the encryption of course which is not unique to the ESP32).
Re:Huh? (Score:4, Insightful)
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:2)
If it's an ESP32 specifically you don't presume to own the whole device. Most of the RF stuff [1]is a vendor blob [ugent.be] talking to undocumented hardware.
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
[1] https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/
bruh (Score:1)
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