ESP32 Undocumented Bluetooth Commands: Clearing the Air
21–30 of 92 posts
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#22Yet, a significant number of stock investors still suffer heavy losses because the market gets rattled by these exaggerated, attention-grabbing headlines. While the consensus here rightly labels this a non-issue—debug commands, not a backdoor, with no remote exploit possible—the sensationalism still has real-world impact. It’s frustrating to see how security hype, often just for internet clout or CVEs as pointed out,…
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#23First and foremost, I have no affiliation with any of the authors previously mentioned. However, I would like to pose a question to the community: Is it feasible to exploit these undocumented HCI commands to develop malicious firmware for the ESP32? Such firmware could potentially be designed to respond to over-the-air (OTA) signals, activating these hidden commands to perform unauthorized actions like memory manipul…
It differs in a way that the person must have access to the device to flash firmware I believe. In x86 as you describe, the person could attack with a connection to the device/machine.
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#24A phrase I hear around security nowadays is "Shadow API" [0, 1]
A shadow API is an undocumented one, and it tends to set-off massive alarm bells.
The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days.
What exacerbates it is proprietary software - stuff that's hidden, obscured, opaque, deceptive, distributed as mysterious "blobs".... this entire cluster of behaviour raises red flags and gets people looking for things. And when we go looking for things that aren't there ... we find them (assume the worst).
That is to say, the researchers are reacting emotionally (but with good justification) to discovering undocumented features, aka a "shadow API".
This could have been avoided if the device maker had just documented them. Why didn't they?
[0] https://www.cybershow.uk/episodes.php?id=39
[1] https://www.cloudflare.com/learning/security/api/what-is-sha...
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#25tl;dr whichever system using an ESP32 as a bluetooth adapter may also just run arbitrary code on the ESP32 itself over the same interface. Commands have to be issued from the host system, not from the air. This sounds like... a good feature? There are indeed some scenarios where doing so poses a security risk. But most of the time I do want to be able to run arbitrary code on e.g. my WiFi dongle when I'm in control.…
I agree! Your system is already heavily compromised if this is a problem for you. I think the real problem lies in a lack of visibility into the state of the device. A compromised dongle could easily be transferred between machines. What we need is to make obvious what the machine/device is doing.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#26You should be switching off the bluetooth on your device if is not needed. CE also has some regulations regarding this. I use the ESP32 in my product[1] I am glad they exist. Their per-certified modules save you quite a bit of money when you do your CE testing. Espressif also offer free design review if you are using their chip in your commercial project/product[2]. [1] https://www.stationdisplay.com/ [2] https://www…
> CE also has some regulations regarding this. Which part of CE? One of the ETSI standards?
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#27On any embedded platform which allows low level access to a radio transciever of any kind, it is possible to exercise all functionality, which will include various possible attacks. The only thing which prevents this in the industry at present is obfuscation, which most manufacturers (other than Espressif) dont bother with.
Take Nordic for example, who make probably the best and most widely used/respected BLE chipset: the full functionality of the transciever can be used via a relatively small set of registers, which are fully documented. Nordic supply a BLE stack, but you can perfectly well write your own instead, meaning that you can deliberately or accidentally abuse all aspects of the protocol. Even at physical level, one can easily conduct simple jamming attacks, by broadcasting full power carrier signal on the BLE advertising channels.
None of this naughtiness is a security flaw. BLE and other wireless protocols in common use are well designed to be resistant to jamming, and the physical implementation of the radios on various SoCs available currently are limited: you cant put out 10 watts of hash over 82 channels at once, because the silicon doesnt support it. You cant even 'sniff' BLE traffic in a real sense, because the silicon on requires a significant number of bytes of 'address' in order to capture any meaningful packet data from ambient noise.
Here is C code, as a fun example, to broadcast full power carrier on any channel, from Nordic NRF52. This is absolutely documented and useful for testing (for example emissions).
// set channel to number between 0 and 100 int channel = 0;
nrf_radio_shorts_set(0); nrf_radio_int_disable(~0); nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED); nrf_radio_task_trigger(NRF_RADIO_TASK_DISABLE); while (!nrf_radio_event_check(NRF_RADIO_EVENT_DISABLED)) {} nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED);
nrf_radio_mode_set(RADIO_MODE_MODE_Ble_LR500Kbit); nrf_radio_shorts_enable(NRF_RADIO_SHORT_READY_START_MASK); nrf_radio_txpower_set(0); nrf_radio_frequency_set(2400 + channel); nrf_radio_task_trigger(NRF_RADIO_TASK_TXEN);
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#28Yet, a significant number of stock investors still suffer heavy losses because the market gets rattled by these exaggerated, attention-grabbing headlines. While the consensus here rightly labels this a non-issue—debug commands, not a backdoor, with no remote exploit possible—the sensationalism still has real-world impact. It’s frustrating to see how security hype, often just for internet clout or CVEs as pointed out,…
Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air
#29In other words, this was a beatup for internet points, not, in any way, an actual security issue.
It’s something they probably should allow developers to disable but it’s also being WILDLY overstated by clout seekers.
You can, from some angles, call this a security flaw or issue. Anyone calling it a backdoor - a term with a specific meaning intentional secret access - is being irresponsible imho