Source Link Privacy.
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. 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.
Update: The ESP32 “backdoor” that wasn’t.
This isn’t a backdoor. Just a company trying to make a name for themselves by sensationalizing a much smaller discovery.
Seriously this. Every single IC which has digital logic contains some number of undocumented test commands used to ensure it meets all the required specifications during production. They’re not intended to be used for normal operation and almost never included in datasheets.
If anyone’s ever followed console emulator development, they know those undocumented commands are everywhere. There’s still people finding new ones for the N64 hardware
Edit: I should say undocumented behavior, not necessarily new commands
Please update the title of this post to mention the update
How so?
Idk maybe specify that it was determined to not be a backdoor. Right now it reads as anti-china fear mongering.
Could be propaganda as well - why not scare the monkeys with the bad Chinese? Without ESPs the market is so much easier to control.
Note:I use both the ES8266ex and different ESP32s in my projects.
Thank you, I keep getting down voted because I said the same, but obviously other get it. Appreciate you and the sanity check!
You can edit post titles as well as content (even images!) on Lemmy.
This sounds like there are some undocumented opcodes on the HCI side – the Host Computer Interface – not the wireless side. By itself, it’s not that big a deal. If someone can prove that there’s some sort of custom BLE packet that gives access to those HCI opcodes wirelessly, I’d be REALLY concerned.
But if it’s just on the host side, you can only get to it if you’ve cracked the box and have access to the wiring. If someone has that kind of access, they’re likely to be able to flash their own firmware and take over the whole device anyway.
Not sure this disclosure increases the risk any. I wouldn’t start panicking.
So explained to me, a tech illiterate in comparison, this is China bad scaremongering?
‘Backdoor’ sounds malicious with intent.Pull up a chair and pour yourself a stiff beverage…
TLDR: Don’t Panic.
If you have a regular old processor (MCU) and want to give it wireless capability, you can buy a wireless chip and stick it next to the processor, then have the MCU talk to it through a wired connection (typically UART or SPI). Think of it as the old ATDT commands that had your PC control your old screeching modems.
To standardize this communication protocol, folks came up with the Host Controller Interface (HCI) so you didn’t have to reinvent that protocol for every new chip. This was handy for people on the MCU side, since they could write firmware that worked with any wireless chip out there, and could swap out for a cheaper/faster one with minimal change.
Fast forward to the era of integrated MCU+wireless, where you had a little ARM or other lightweight processor plus a little radio, and the processor could run programs in a high-level API that abstracted out the low level wireless stuff. Plus, you could use the same radio for multiple wireless protocols, like BLE, wifi, ANT, etc. Nordic and TI were early adopters of this method.
Typically, it was the vendor’s own processor talking to their own wireless module, but they still implemented the full HCI interface and let it be accessed externally. Why? So if your design needed an extra beefy processor and used the MCU+wireless chip as a simple communication module, this would still work. The teeny MCU could be used to run something extra in parallel, or it could just sit idle. A typical example could be a laptop or cell phone. The little MCU is too small for everything else, so you pair it with a big chip and the big chip drives the little chip through HCI.
Sure, it would be cheaper if you just went with a basic ‘dumb’ wireless chip, as folks from CSR, Broadcom, and Dialog kept pointing out. But the market demanded integrated chips so we could have $10 activity trackers, fancy overpriced lightbulbs, and Twerking Santas (https://www.amazon.com/twerking-santa-claus/s?k=twerking+santa+claus).
For integrated MCU+wireless chips, most vendors didn’t release the super low-level firmware that ran between them. There was no need. It was internal plumbing. They exposed SDKs so you could control the wireless chip, or high-level Bluetooth/wifi APIs so you could connect and talk to the outside world in a few lines of code. These SDKs were unique to each vendor (like Nordic’s nRF Connect library, or TI’s SimpleLink SDK).
Then along came Espressif out of Shanghai, China with a combo chip (ESP8266) that offered processor + wifi and was so cheap and easy to program that it took the hobbyist market by storm. Oh, god… so many LED light strips, perfect for Christmas and blinky EDM lightup outfits (hello, Adafruit: https://www.adafruit.com/category/65).
Fast forward and Espressif drops the ESP32. A bigger, faster Tensilica Xtensa processor, with built-in flash storage, plus wifi, Bluetooth, and BLE in one place. Plus lots of peripherals, busses, and IO pins. Also, running FreeRTOS and eventually Arduino SDKs, and MicroPython. All for less than $5! It took off like a rocket. So many products. Plus, you could run them as little webservers. Who doesn’l love a little webserver in their pocket?
It’s gone through a few variations, including swapping out the Tensilica with an open-source RISC-V MCU, but otherwise it’s a massive seller and the gateway drug for most IoT/Smarthome nerds.
So along come these Tarlogic researchers, looking to build a direct USB to bluetooth library. This way, you can drive the wireless from, say Linux, directly. There are already BLE to USB stacks, but this one is giving access at the HCI level, in a C library. Handy if you’re doing research or developing drivers, but not the sort of thing your typical DIY person needs.
As part of their process, the researchers decide to dump the really low level ESP32 firmware and reverse engineer it.
A typical HCI implementation is a giant event loop that handles HCI opcodes and parameters. Host wants to talk to the outside world, it sets up some registers, configures the unique MAC address, then opens a channel and starts sending/receiving (hopefully without the modem screeching tones). There are typical packet encoders and decoders, multiple ISO/TCP layers, and the sort of thing that most people assume somebody else has gotten right.
For fancier implementations, there may be interrupt or DMA support. Sometimes, there’s a multi-tasking part under the hood so they can time-slice between wifi, bluetooth, and ble (aka Fusion or Coexistence support). Not that you should care. The internals of this stuff is usually nobody’s business and the vendors just include a binary blob as part of their SDK that handles things. The host systems just talk HCI. The wireless side talks HCI on the wired side, and wireless on the radio side. Everyone’s happy.
In the process of reverse engineering the low-level HCI blob, these researchers found a few extra undocumented HCI opcodes. They’re not sure what they’re for, but according to their presentation (https://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/) if my super rusty Spanish holds up, it has to do with setting MAC addresses and handling low-level Link-Level Control Protocol communications (https://www.ellisys.com/technology/een_bt10.pdf).
Now in an of itself, this is no big deal. ESP32s already let you easily set your own temporary MAC address (https://randomnerdtutorials.com/get-change-esp32-esp8266-mac-address-arduino/), so there has to be a way to override the manufacturer one. And LLCP management is a totally geeky low-level thing that the MCU needs when handling wireless packets. There are perfectly good reasons why the opcodes would be there and why Espressif may not have documented them (for example, they could be used only during manufacturing QA).
So the original presentation is a teeny bit of an exaggeration. Yes, the opcodes exists. But are they nefarious? Should we stick all our ESP32s inside Faraday cages? Is this a secret plan for the CCP to remotely control our lights and plunge the world into chaos?
As I said before, ONLY if there’s a secret as-yet-undiscovered wireless handshake that gives remote wireless access to these (or really, pretty much any other published HCI opcode). That presentation most definitely doesn’t claim that.
To see if there is a REAL backdoor, you should wait for an analysis from fine professional wireless debugging vendors like Ellisys (starting models run $30K and up), Frontline, or Spanalytics.
Incidentally, Tarlogic, the group that put out that paper have their own BLE analyzer product (https://www.tarlogic.com/es/productos/analizador-bluetooth-le/). They look to know their stuff, so they should know better than putting out clickbait-y hair-on-fire reports. But come on, who can resist a good CCP/backdoor headline? Will media run with this and blow it out of proportion? No way!
If you’ve read this far, you must safely be on your third drink or the edible’s just kicked in. Stop panicking, and wait until the pro sniffer and Bluetooth forum people give their opinions.
If it turns out there is an actual WIRELESS backdoor, then by all means, feel free to panic and toss out all your Smarthome plugs. Go ahead and revert to getting up and flicking on your light switch like a peasant. Have a sad, twerk-free Christmas.
But over a few undocumented HCI opcodes? Have another drink and relax.
Happy Sunday.
PS: controversy already up on wikipedia: https://en.m.wikipedia.org/wiki/ESP32
PPS: you may want to stock up on ESP32s for your light-up Christmas light project. Don’t be surprised if Espressif gets smacked with some hard tariffs or an outright ban, based on these ragebait headlines 🤷🏻♂️
Edit: DarkMentor offers a little more detail on the nature of the opcodes: https://darkmentor.com/blog/esp32_non-backdoor/
what a fantastic write up. thank you so much for taking the time <3
This is a very good comment. I’d give you Lemmy Gold if such a thing existed. Thanks for posting it!
The article is a security company trying to hype their company with a theoretical attack that currently has no hypothetical way to be abused
The article has an update now fixing the wording to “hidden feature” but, spoilers, every BT device has vendor specific commands.
The documentation of the part just wasn’t complete and this companies “fuzzing” tool found some vendor commands that weren’t in the data sheet
The China part just came from OP
The article is a security company
trying to hype their companyruining their reputation in an incredibly ill-thought out attack that companies will ABSOLUTELY remember.Even worse, it just makes this security company look incompetent. Like a home security company that announces a huge vulnerability in Schlage locks- there’s a key that can unlock the lock included with every lock sold!!11!!!11!one!
I agree, but unfortunately, this has become common since Heartbleed, and they seem to be able to sell their snake oil to CTOs…
thank you
Does anyone know where it is that we can find these new commands? I have an esp32 dev kit just a few feet away from me as i read this. It might be interesting to know what these new product “features” are.
I hate it when an attacker who already has root access to my device gets sightly more access to the firmware. Definitely spin up a website and a logo, maybe a post in Bloomberg.
The rebuttal wasn’t as comforting as some are making it out to be. They seem to be more interested in the semantics of it not being a backdoor tied to a specific product, which appears to be true.
Rather it is a potential for vulnerability that exists in all wireless implementation, which seems to me to be a bigger issue.
It’s a vulnerability where an attacker already needs code execution on the device/physical access.
If you have that you’re already compromised no matter what.
The biggest risk would be IoT devices.
That’s just the summary of the entire existence of IoT devices
The issue is where the undocumented commands are. They aren’t just allowing any old external person to send payloads to this.
It’s kind of like noticing that someone unexpectedly hid a spare key next to the door… On the inside of the house. Like, sure, maybe the owner would have like to know about that key, but since you have to be inside the house to get to it, it doesn’t really make a difference.
welp, TL;DR from comments says its fear mongering at best, physical access required right?
Code execution required lmao
It allows the takeover of devices!
How?
By already having taken over the device.
Wtf is this reporting
Well… Shit.
There are so, so, so, many ESP32’s in not just my house, but practically everyone I know.
There outta be fines for this BS.
You’re fine. This isn’t something that can be exploited over wifi. You literally need physical access to the device to exploit it as it’s commands over USB that allow flashing the chip.
This is a security firm making everything sound scary because they want you to buy their testing device.
In that case, how long til some open source project uses it to make a custom firmware to bypass the manufacturer bs and integrate my cheap IoTs seamlessly into Home assistant?
You can already reflash a lot of devices for this purpose. And you could use esp-home to customise once reflashed
Really? Where can I find this
You literally need physical access to the device to exploit it
You don’t need physical access. Read the article. The researcher used physical USB to discover that the Bluetooth firmware has backdoors. It doesn’t require physical access to exploit.
It’s Bluetooth that’s vulnerable.
I just re-read the article and yes, you still need physical access.
The exploit is one that bypasses OS protections to writing to the firmware. In otherwords, you need to get the device to run a malicious piece of code or exploit a vulnerability in already running code that also interacts with the bluetooth stack.
The exploit, explicitly, is not one that can be carried out with a drive-by Bluetooth connection. You also need faulty software running on the device.
“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.”
I of course don’t know details but I’m basing my post on that sentence. “Backdoor may be possible via … rogue Bluetooth connections.”
Looking at the article, the exploit requires you to be able to send arbitrary data to the Bluetooth device over a physical connection. This means that a properly secure application will be protected from drive by connections, but if the application has an exploit that either lets an attacker write arbitrary values to the Bluetooth controller, or more likely contains a general arbitrary code execution exploit, then you could use this to rewrite values to the chip that would let you “persist” certain changes to the Bluetooth chip that would be difficult to notice.
I would consider this a moderate concern, as this will definitely increase your options if you’re looking to be able to make an attack that targets a specific device and this gives you a few additional persistence options, but any attack would have to be designed for a particular program running connected to a Bluetooth chip.
A more likely concern in my opinion would be the possibility of a supply chain attack, where someone compromises a Bluetooth chip that they know will be used to construct a particular part.
I don’t think that it’s super likely that either of these will affect the average person, only corporations and governments where espionage is an actual threat, as if you can find a Bluetooth IOT device that you want to mess with, like a Bluetooth enabled door lock, then you’re more likely to be able to find an arbitrary code execution attack which causes it to unlock immediately. Being able to spoof a different Bluetooth device isn’t likely to give you that big of an advantage when you’re working with a device that was already vulnerable for a different reason.
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.
I really wish these articles just tell us what these scenarios are. I understand companies need publicity or need to sell software but if it isn’t replicatable and the article says “might be possible” it kind of sounds like a secuity sales pitch.
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.
This part basically sounds more like a software issue where the attacker has a way in already. The system is already vulernable at this point before using the exploit found.
I don’t think there’s enough information out yet.
It is very interesting though.
Wrong. Read the analysis. It is a BT vulnerability. One can probably design a cheap attack system that just sends a erase flash command to any BT device in reach, instantly bricking every BT enabled ESP32 device.
Just reread it and no, it’s not a BT vulnerability. The “erase flash” command is something that has to be done by software running outside the BT stack. You can even see that inside the slides. The
UsbBluetoothsoftware is connected to the device with the flawed bluetooth chipset.The vulnerability is that if you have this chipset and compromised software, someone can flash the chipset with compromised flash. They even say that it’s not an easy attack to pull off in the article.
In general, though, physical access to the device’s USB or UART interface would be far riskier and a more realistic attack scenario.
In otherwords, the attack is something that can only be pulled off if there’s also a security vulnerability within other parts of the hardware stack.
Babe, wake up its time for your china fear mongering news
Too much fanfare and too little real info shared to be of any value. Sounds more like an ad than infosec
We really should be pushing for fully open source stack (firmware, os) in all iot devices. They are not very complicated so this should be entirely possible. Probably will need a EU law though.
Open source stack will not prevent this. It’s not even a backdoor, it’s functionality that these researches think should be hidden from programmers for whatever reason.
Open source devices would have this functionality readily available for programmers. Look at rtl-sdr, using the words of these researches, it has a “backdoor” where a TV dongle may be used to listen to garage key fobs gasp everyone panic now!
I 100% believe firmware should be open source no question about it. There’s so many devices out there especially phones and iot devices that just become e-waste because you can’t do anything with it once it’s not supported if it was open source and documented in some way then it could be used. I have like five cheap phones that I got because they were so cheap but once they lost support they’ve become completely useless even though they still work.
Gotta blame China to get upvoted on Lemmy.
Or use a precise title. It’s not a backdoor or a “backdoor”.
Yeah, one of those is factually correct and got upvoted…
At this point I welcome them to come through.
Come through with what though?
Weird that they removed the reference to ESP32, one of the most common and widely known microcontrollers, from the headline.
It’s because the security company basically lied about this being a vulnerability, and probably opened themselves up to a lawsuit.
Fukin dmnit! I just spent the last several months fine tuning a PCB design supporting this platform. I have , what i believe to be my last iteration, being sent to fab now. I have to look i to this. My solution isnt using bluetooth, so i dont know if im vulnerable.
Go for it. It’s a bullshit attention grab. No backdoor, just some undocumented vendor commands (which is the norm for virtually every chip out there).
Its not a backdoor, you’re most likely fine.
The exploit requires physical access. It’s not exploitable in 99% of cases
