bluetooth backdoor

[coppercone2]

https://hardware.slashdot.org/story/25/03/08/2027216/undocumented-backdoor-found-in-chinese-bluetooth-chip-used-by-a-billion-devices

thats alot of fucking devices

[Whales]

After looking at the presentation: I believe Bleeping Computer's take is completely misleading.  (EDIT: And Tarlogic's "announcement")

There was nothing presented about backdoors that let you get into an ESP32 externally.

The presentation was about using an ESP32 as a general purpose bluetooth receive + transmit device to then do security research.  They discovered that there are undocumented HCI opcodes (sent between the ESP32 CPU and ESP32 bluetooth peripheral) that give give them more control over the peripheral.

As far as I can tell that's it.  Hoping someone else can give their 2c too, maybe I missed something.

Presentation slides in Spanish
Attached is a dodgy google autotranslated anglish copy.

[radiolistener]

The main backdoor is WiFi, it works on larger distance and allows enemies to hijack your machine and execute their code, include traffic spoofing. And they even don't need physical access to your machine in order to do it. It is not even necessary for the machine to be connected to the access point and sending some traffic, just enabled WiFi module is enough

[Whales]

The main backdoor is WiFi, it works on larger distance and allows enemies to hijack your machine and execute their code, include traffic spoofing. And they even don't need physical access to your machine in order to do it. It is not even necessary for the machine to be connected to the access point and sending some traffic, just enabled WiFi module is enough

Are you talking about attack surfaces of products in general, or specifically the articles and presentations linked to in this topic?  I saw no mention of ESP32 wifi research.

> it works on larger distance

Are they not on the same frequency ranges and use the exact same radio?

[timelessbeing]

ooo I hope there's an episode about this.

[coppercone2]

ooo I hope there's an episode about this.

I don't know if its over stated, I never got into it because it was annoying to me how "wrapped" it is. If it was more like a Z80 system with multiple chips and stuff, I would be more interested, but its like a extremely 'black box'. That kind of engineering you need to pay me for (little natural interest)

[ataradov]

This is one of those "we discover how the world works" things. This is not a backdoor, just a bunch of poorly documented vendor specific HCI commands. All HCI controllers would have those. There is no vulnerability of any kind here.  Unfortunately, clueless press will run with this nonsense.

They would be better off publishing a hack-a-day article about new useful commands they discovered. The commands seem to be pretty useful and I'm sure people will find a way to take advantage of them.

A few years back I received a report about vulnerability in the CAN controller in one of the Atmel MCUs. The "vulnerability" was that pins are multiplexed with GPIO and if you manage to change the firmware, then you could switch GPIOs low and drive dominant level on the bus. "Researchers" missed the fact that you don't even need to reassign the pins, Bosch controller has test modes that would do that even if pins were dedicated. They also missed the fact that all sane transceivers will disconnect from the bus if you ask them to drive dominant level for a long time.

[Whales]

A few years back I received a report about vulnerability in the CAN controller in one of the Atmel MCUs. The "vulnerability" was that pins are multiplexed with GPIO and if you manage to change the firmware, then you could switch GPIOs low and drive dominant level on the bus. "Researchers" missed the fact that you don't even need to reassign the pins, Bosch controller has test modes that would do that even if pins were dedicated. They also missed the fact that all sane transceivers will disconnect from the bus if you ask them to drive dominant level for a long time.

 

If you change the firmware then all bets are off, it can do whatever it wants to the bus.

Next vulnerability report: if you change the Atmel MCU for different chip then it can ruin the bus.

[ataradov]

If you change the firmware then all bets are off, it can do whatever it wants to the bus.

  Over the years I've received many vulnerability reports. A couple were genuine issues. The reset were absolute garbage.

Another one was denial of service attack on a wireless network. The network stops working if you jam the channels. Brilliant security research. And they were absoultey serious and wanted to warn us.

[coppercone2]

I don't know, if it turns out that its particularly easy compared to other systems, or can be done with lower power or higher range or whatever ,its not bad research.


i.e. if its extremely low effort

Kind of like if a lock can be picked by raking it with a paper clip when your drunk or if it needs 10 min with high end tools by a pro

Like if you found it can be effectively jammed from 20 feet by a battery nose hair trimmer or takes a power amp and antenna. they might just be saying that the system is particularly shit. it's hard to tell with electronics because with mechanical stuff its usually pretty obvious if something is mad shoddy, but electronics can go un noticed and un tested.

[ataradov]

No, it was just basic interference, there was absolutely nothing interesting about it. Plus it was for standard radios made by many vendors, and if it went anywhere, I'm sure we would have heard about it by now.

There is just a lot of pressure to get publications for a degree. So people publish random garbage like this just to increase the counter. There is nothing really wrong with observations, so it is not exactly fraud. But there is no useful conclusions either.

[coppercone2]

on the other hand, I believe there are engineers so clueless that they have no idea until the obvious some how hits them. For some reason I think I would be doing a favor to some people to show research that proves its possible to measure a 10 ohm resistor with a multi meter

Just re-do one of Volta's experiments with something that has a OLED panel display on it and it will be cutting edge news for some of your colleges

"Electrochemical potentials observed"

And again in like 100 years with a holo-display volt meter or whatever they have

and then you get to hear about a mercury 'chemical energy storage device' pitch during a meeting like its going to change the world, then the other guy says "we can sell billions of them if we replace the mercury with something else!'

[radiolistener]

Are you talking about attack surfaces of products in general, or specifically the articles and presentations linked to in this topic?  I saw no mention of ESP32 wifi research.

I'm talking about wireless modules in general, including WiFi and Bluetooth. Many of them run on Broadcom BCM chips which is a SoC with an ARM Cortex-R4 with ~900 kB ROM and ~900 kB RAM and running on a proprietary RTOS called HNDRTE. Like any system, they have vulnerabilities and backdoors.

For example, the well-known Broadpwn attack exploited vulnerabilities in Broadcom WiFi firmware, allowing arbitrary code execution without physical access. This allows an attacker to remotely gain full access to most smartphones, tablets, and other mobile devices without even having physical access to them. All what is required is just enabled Broadcom WiFi module on the device... It don't require any user interaction, all is done silent. Bluetooth modules built on such chipsets are susceptible to the same issues, and the same applies to the ESP32.

[ataradov]

But this has nothing to do with the current issue, which is not an issue at all.

I also don't see how BCM vulnerability can apply to ESP32.

[RoGeorge]

IDK, looks to me there's nothing wrong with ESP32. 
Undocumented commands doesn't mean backdoor.

[radiolistener]

I also don't see how BCM vulnerability can apply to ESP32.

You’re right that ESP32 and Broadcom use different hardware and firmware, so a specific BCM vulnerability like Broadpwn doesn’t directly apply to ESP32. However, the general point is that many WiFi and Bluetooth modules, including those in ESP32, rely on proprietary firmware running on embedded MCU. These firmwares have security vulnerabilities. While the specific exploits differ for different vendors, the attack surface remains similar - remote code execution, memory corruption, and other flaws can exist in any closed-source wireless firmware.

[Whales]

While the specific exploits differ for different vendors, the attack surface remains similar - remote code execution, memory corruption, and other flaws can exist in any closed-source wireless firmware.

I'll hedge this with: "closed source designs" are the root of the problem, "closed source firmware" is just the current popular permutation of this.  The difference seems trivial and silly at the moment, but I expect some companies in the future will try to blur the lines between what they call hard gates & soft firmware in their legal arguments.  Especially if there is ever a push for open-source firmware to be a minimum standards requirement (I can only wish).

[ataradov]

There is not a single open source BLE module out there. This is one of the requirements of the Bluetooth SIG to get the certification.

You can make one, I guess, but you will never get it certified. This will never work for big vendors. Some vendor in China that is not concerned with certification may do it, but they rarely have interest.

[golden_labels]

Initially I laughed at this and even thanked Whales for a quick explanation. But after digging deeper into the presentation PDF and trying to extract as much juice as I could from the scraps, I think the ridicule is unwarranted.

Calling it a “backdoor” was too strong. The word implies intentions, and they presented no evidence even remotely suggesting that. But it is a vulnerability and a damn good one. If anybody has trouble understanding, what they did, let me put it in a more comprehensible example. Imagine the following hypothetical situation:

• Windows has a bunch of undocumented kernel calls,⁽¹⁾ that allows any userspace program to directly control peripherals.
• It is bundled with motherboards with built-in wireless communications.
• Those motherboards are deployed to a billion devices of all kinds, most of which aren’t even advertised to have wireless connectivity.
• There is no way to apply a patch to existing deployments.

Ring -1 access to unadvertised wireless communications from userspace. Not something I wish to call “nothing.”

It’s a local escalation, yes. With microcontrollers landscape of 2000s that would be of no imporance, as the only actor capable of carrying out an attack would be the device vendor. But folks, I've a feeling we're not in 2020s anymore. The puzzle piece you might’ve overlooked is that ESP32 isn’t used as we used microcontrollers 20 years ago. The firmware is being developed in high-level languages, with underlying runtime and with a massive number of third-party libraries. In the age of chain supply attacks this is bad news. With where ESP32 is being deployed, it almost universally is being used by people with no understanding of the subject, not caring about security, and hiring absolute newbies barely able to make everything not crash. Makes the situation orders of magnitude worse. And all this happens on a SoC that has wireless communications, and one that happens to be used without ever mentioning them to the buyer.

Does that sound to you more serious?

⁽¹⁾ That one is actually not hypothetical.

[ataradov]

Does that sound to you more serious?

No, not at all.

There are similar commands in most (if not all) HCI controllers. This is how firmware updates are done on them. The one you have in your devices now likely has them.

"Undocumented" part is also not suspicious, documentation for such products is shit even from good vendors. They can get away with bad documentation on the main commands because BT spec has them as well and they are standard, so if documentation is bad, you can just read the spec. But vendor-specific commands are not in the spec, of course.

Locking options and preventing updates with unsigned binaries would be the only issue here. But they should not have hyped it this way and there should be absolutely no mention of remote attacks here.

It is a modern trend to take the most minor issue and blow it up with hypothetical scenario. "This lock is easy to pick, if it guards the nuclear arsenal, then terrorists may get access to it and do a nuclear strike" kind of thing.

It is good and necessary to bring attention to the issues, but really this should have been published as "Hey we found some cool commands to make your projects better. They may also be used maliciously, so may be vendor should consider locking them up better".

[Whales]

With where ESP32 is being deployed, it almost universally is being used by people with no understanding of the subject, not caring about security, and hiring absolute newbies barely able to make everything not crash. Makes the situation orders of magnitude worse. And all this happens on a SoC that has wireless communications, and one that happens to be used without ever mentioning them to the buyer.

That has very little to do with these undocumented bluetooth commands.  It sounds like you will accept nothing short of a microcontroller with no wireless features whatsoever.

If you are running untrusted code then it can do bad things, whether or not HCI commands are documented does not help your hypothetical newbies.  Even if you tried to make the peripherals perfectly fool proof: "harm" is a complex human concept, the device can still inject javascript into served webpages to try and exploit user's personal devices; and many other things.

[Geoff-AU]

Tons of Bluetooth chips by other vendors have drivers with firmware patch ability that fixes ROM bugs and they deliver the patch via HCI.

This is a nothingburger.  You have to exploit a backdoor (remote execution or physical access) before you can do this and at that point you're inside the castle so you can do anything else you like too.