8 ms·
Undocumented backdoor found in Bluetooth chip used by a billion devices
- nikisweeting 2y agoCan we please put "ESP32" in the title somewhere, so many people are going to miss this headline because it's so generic clickbait sounding.
- leptons 2y agoCan we also take out "backdoor" from the title, because that word is very misleading.
- rurban 2y agoTheir slides in Spanish: https://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/ https://www.documentcloud.org/documents/25554812-2025-rooted...
- deleted 2y ago[deleted]
- asdfologist 2y agoSomeone on Reddit suspected this 3 years ago. https://www.reddit.com/r/embedded/comments/wopjw8/how_sure_are_you_the_esp32_is_not_a_trojan_horse/ https://www.reddit.com/r/embedded/comments/wopjw8/how_sure_a...
- MarkMarine 2y agoGotta say I expected this to be the wifi system. Most of the code on the ESP-32 is given as source, but the wifi driver is not. https://github.com/esp32-open-mac/esp32-open-mac https://github.com/esp32-open-mac/esp32-open-mac
- Eduard 2y agothe lower layers of both Wifi and Bluetooth on ESP32 family devices are closed as of this writing.
- Aurornis 2y agoThat doesn't match the article at all.
- jillyboel 2y agoAnyone who has thought critically for a few seconds has suspected this. The question is whether you're right and if you can prove that.
- millerm 2y agoFunny that I just pulled out an ESP32 dev kit a couple days ago and I honestly questioned myself with "how do you even know these things are secure at all?" Glad I know the answer now. I'm starting to miss the days of being disconnected more and more as time goes on. This constant churn of having to monitor and lockdown everything you own down is becoming a complete negative.
- millerm 2y agoWell, after reading, perhaps it's not a "backdoor". I can say, most of us do not like undocumented APIs floating around as they do seem suspicious. I'm still going have my fun, but as I stated I do miss simply being disconnected as a default. Not sure why I was down-voted for my opinion.
- ceejayoz 2y agoThe next world war seems like it’ll be about five minutes long. Nukes won’t be required to send us back to the Stone Age.
- onemoresoop 2y agoYou mean all our devices refusing to work for us at a switch of a button?
- 20after4 2y agoOne of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode. If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet. This would of course be coordinated with multiple underwater cable cuts. It seems all too plausible, based on my admittedly limited understanding of how these devices work.
- gruez 2y ago>One of the best conspiracy theories I have heard recently is that the CCP can use one of their reconnaissance balloons to instantly switch every device that has a Chinese radio chip into DDOS mode. This is a terrible conspiracy theory. Given how much Chinese IOT devices active in the West right now, the CCP doesn't even need to fly a balloon into the US. They can just pressure its IOT vendors to push a firmware update that broadcasts the DDOS signal. >If that were to happen it could plausibly generate enough congestion to seriously degrade a significant portion of the public Internet. At best it'll take down 2.4ghz communications, not the entire internet, or even all wifi networks. 5 Ghz/cellular networks will be spared because cheap chinese IOT devices don't operate in those frequency ranges, or the band is too wide for devices to jam. Moreover any important systems/institutions would presumably have hardwired connections, which are completely immune.
- LoganDark 2y agoThis is hilarious. Is there any evidence that such a "DDOS mode" has ever existed in any device?
- noodlesUK 2y agoEDIT: My Spanish isn't very good, but reading the slides it doesn't sound like the vulnerability is likely to be remotely exploitable, it sounds like it's only an issue if the chip is in HCI mode and being used as a bluetooth adapter. If someone who speaks Spanish could confirm I would be very appreciative.
- stragies 2y agoWith ESP32, always regard the vendor firmware only as proof-of-electrical-functioning. The first thing you should do with any ESP32 device after basic function test, is install ESPHome on it. If that's not possible, buy something different, where you can replace vendor fw.
- noodlesUK 2y agoOh, I completely agree for IoT devices. When I was first reading the article I feared that the issue was something burned into the bluetooth radio binary blob, or something at the hardware level that would not have mattered whether you were running esphome or not. Upon a little deeper inspection, it doesn't sound like that's the case.
- Eduard 2y agoEspressif chips such as the ESP32 family are used for so many more applications than just smart home devices, which ESPHome targets. e. g. it doesn't make sense to install ESPHome on an ESP32-based drone :)
- Palomides 2y agoI'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor
- 20after4 2y ago> "Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections." Yeah this does not sound like a RCE.
- haswell 2y agoIn what way is what you quoted not describing an RCE? Clearly there are unanswered questions like does this malicious firmware exist? and how likely is it that ESP32s in the wild were shipped with it? But they’re still describing an RCE.
- iracigt 2y agoBecause it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
- haswell 2y agoAre you saying that none of the undocumented commands are capable of putting the device into a remotely exploitable state? The fact that it might be necessary to execute these commands locally is separate from the effects of executing those commands and the potential implications for hardware in the wild. A simple example would be a supply chain attack that leverages these commands to compromise what will soon be consumer hardware.
- realitysballs 2y agoIs this vuln. fixable via firmware or is the vulnerability inherent in the chip architecture?
- leptons 2y agoIt isn't really a vulnerability. You have to already have full access to the device to use the undocumented commands reported in the article.
- iracigt 2y agoI think the title is a bit misleading. If I'm reading correctly, the "backdoor" allows a computer to peek and poke memory and other low-level functions of its own USB Bluetooth adapter. I don't this this is usable over the air? Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable. If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.
- deleted 2y ago[deleted]
- haswell 2y agoWhat I took away from this was that malicious actors using ESP32 chips in their products could potentially leverage these commands to deliver essentially a Trojan horse. “Buy this super cheap home automation product” turns into installing an APT in your network.
- huang_chung 2y ago> "Buy this super cheap home automation product” turns into installing an APT in your network. If that was intention, no need to hide code in the Bluetooth, just write it in the firmware. The device itself it the trojan horse.
- stragies 2y agoOnly buy ESP32 products, where you can access the pins for reflashing with ESPHome.
- 20after4 2y ago100% agree. ESPHome is by far the best use for ESP32s that I've found.
- 2y ago
- RicoElectrico 2y agoFWIW almost nobody uses ESP32 for Bluetooth alone. This is primarily a Wi-Fi SoC. "Billion devices" is a ridiculous claim if most of them don't use BT features anyway.
- Retr0id 2y agoIt's unclear to me what a practical vulnerability/attack scenario would look like here.
- BertoldVdb 2y agoA very far stretch: You have a ESP32 based Bluetooth dongle, that exposes its HCI interface to the host. You have already gained access to the host and can now load code to the dongle. Not really a vulnerability, and many types of bluetooth dongle firmwares can be updated by the host...
- lima 2y agoThe researchers found undocumented hardware functionality which allows someone who already has code execution a greater-than-expected degree of low-level access to the ESP32 wifi stack. Calling this a "backdoor" is just pure clickbait.
- deleted 2y ago[deleted]
- mmastrac 2y agoIn theory you probably should have low-level access to your attached BT radio itself, so this is just kind of expected, isn't it? I prefer when devices have these low-level interfaces. Perhaps the problem is the lack of documentation rather than existence? I used to use the memory read/write commands via USB on Qualcomm radios to unlock and otherwise take ownership of otherwise locked-down devices. Given that was a full OOB read/write I'd consider that maybe not great, but if this is only accessible from flashed code all the better.
- almosthere 2y agoAnyone want to start a Faraday cage laptop case company
- fsflover 2y agoAgain, the hardware kill switch in my Librem 5 looks like a necessary feature.
- roger_ 2y agoI hate sensational stories like this. Now Espressif is gonna feel pressured to be even more closed.
- megadata 2y agoIt'd never have been an issue if this was documented.
- ratg13 2y agoI feel like people that are concerned about this have never heard of a JTAG access port.
- janice1999 2y agoOn most modern micro-controllers you can disable JTAG/SWD in production or gate access behind key verification. You can't disable undocumented commands. The issue here might be allowing persistent malware, like how some malware can hide in hard drive firmware. Unlikely, but still not good or indicative of good security practice.
- deleted 2y ago[deleted]
- megadata 2y agoIs JTAG undocumented?
- mrheosuper 2y agobecause it was never supposed for user to use it. Do you document every private macro, every private function in your library to user ?
- Aurornis 2y agoTL;DR: They reverse engineered the firmware and found HCI commands to do things like read/write memory, send packets, and set the MAC address. Not really a backdoor. I don't know if they called it a backdoor (presentation is in Spanish), or if the journalists are calling it a backdoor to get more clicks. You'd need to have arbitrary access to send HCI commands to the device to use these commands. That means you're already controlling the device and how it operates. This isn't something that gets remotely exploited over the wireless link. Any exploits would already have to have full control of the device, at which point being able to change the MAC address or send packets isn't really a surprise anyway. Interesting research, but really groan-inducing to see it spun as a "backdoor". I don't know who's to blame for the wording, though. I'm guessing the journalists? EDIT: For an analogy that might be more familiar, imagine if someone discovered that the Ethernet controller on a common IOT chip could change its MAC address or send arbitrary packets if the firmware told it to. This is the same thing, but with Bluetooth.
- ramses0 2y agoDon't you see how a random device with an Ethernet cord being able to change its MAC address and send arbitrary packets is a wormable threat actor? ...and then let it do the same but without the Ethernet cord requirement? Drive around with a white van that says "Free Candy / BLE Persistent Threats"... pwn devices as you walk through the metal detectors on the way to China. Wireless, wormable, arbitrary packets, spoofing arbitrary devices and you don't see the issue?
- awwaiid 2y agoIt doesn't sound like it is wormable -- it doesn't allow any new attacks on external devices.
- tredre3 2y ago> Don't you see how a random device with an Ethernet cord being able to change its MAC Many devices already allow you to change your MAC if you want. This isn't new, it's been the case since the beginning of ethernet, and subsequently wifi. Then you have things like device privacy on Windows and Android that use randomized MACs when connecting to new networks.
- ddtaylor 2y agoNo plausible attack described for a reason.
- abetancort 2y ago[flagged]
- slater 2y agoAm I misremembering, or wasn't there some hubbub ca. 2010 where someone was going to do a presentation at CCC about how Bluetooth is basically swiss cheese in terms of security, and someone got all huffy about it and it was all hush-hush'd and the presentation cancelled?
- deleted 2y ago[deleted]
- K0balt 2y agoThis is good research, but a bad headline. As an attack vector, this requires physical access and could already be done by other means in almost all cases. So, “undocumented commands found in common Bluetooth chip” would be a better headline.
- Ekaros 2y agoI take this stuff might be interesting in hardware hackery way. Like legitimate way to get extra things out of existing hardware.
- K0balt 2y agoI was thinking the same thing, maybe for downloading locked firmware. Now that we know we can use LLMs to clean-room just about any code, extracting firmware from devices just because much more valuable.
- russellbeattie 2y agoCan any app running on an Android device with an ESP32 save code permanently to flash memory? Would an app have that level of access to send arbitrary low-level commands to the hardware?
- BertoldVdb 2y agoNo, unless the Android is already rooted, it is not possible to send vendor HCI commands.
- russellbeattie 2y agoThanks!
- raydiak 2y agoSo everyone's fine installing opaque binary blob drivers which run in kernel space on their desktops and laptops and not even having root access to their own cloud-controlled phones, but some undocumented low-level ESP32 commands which require the device to already be compromised are a news-worthy threat vector. Really wonder if something got lost in translation, here. In the past we would have just thought that was cool and looked for a way to turn it into a SDR.
- IYasha 2y agoSomeone's just living off the hype again. Scaring the uneducated masses and hurting the reverse-engineer community.
- jimrandomh 2y agoThis headline is a lie. A backdoor in a Bluetooth chip would be something which enabled a wireless attacker to gain code execution on the chip. This article reports on something which allows the device drivers of the attached device to gain code execution on the chip, which does not violate a security boundary. (In a well-functioning journalism ecosystem, this would require a retraction and would significantly harm the reputation of the outlet that wrote it. Sadly this will not happen.)
- pabs3 2y agohttps://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/ https://www.documentcloud.org/documents/25554812-2025-rooted...
- Woodi 2y agoGot me think: it's time to end using binaries of assembler. Just some intermediate bytecode (can be 1:1 to assembly) and private VM that, for starters instruction whitelisting. I know - 'if' (at minimum) on every asssembly instruction :> But there is no other way then that. Life.
- IYasha 2y agoSo, what's next? Declare having "sudo" or "runas" a vulnerability? Oh, wait, it's been already do... NO CARRIER