Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESP32 Undocumented Bluetooth Commands: Clearing the Air

developer.espressif.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#11

Post by Jochim »

rfoo wrote: post #2

tl;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.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#12

Post by ElectRabbit »

Jochim wrote: post #6

Related: Undocumented backdoor found in Bluetooth chip used by a billion devices https://news.ycombinator.com/item?id=43301369

On the HCI interface. That's not a OTA attack.

If an attacker can write raw data the HCI interface you are doomed anyway.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#14

Post by GardenLetter27 »

jpcosta wrote: post #13
rswail wrote: post #4

In other words, this was a beatup for internet points, not, in any way, an actual security issue.

Unfortunately, all too common in the security field.

It's almost the entire field these days - just trying to get CVEs for the CV.

The days of Metasploit 0-days are over, so now it's just loads of sensationalist reporting and box-ticking regulation in companies.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#15

Post by spaintech »

First 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 manipulation or device impersonation.

However, considering that deploying malicious firmware already implies a significant level of system compromise, how does this scenario differ from traditional malware attacks targeting x86 architectures to gain low-level access to servers?

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#16

Post by jwr »

spaintech wrote: post #15

First 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 is feasible to develop malicious firmware for the ESP32 even without these HCI commands. The existence of these undocumented commands doesn't change anything.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#17

Post by mort96 »

atoav wrote: post #10
rswail wrote: post #4

In other words, this was a beatup for internet points, not, in any way, an actual security issue.

If their goal was to get espressif to explain undocumented functionality they reached it. And espressif should have closed that gap without external pressure.

If the researchers had written articles and held talks about undocumented HCI commands to gain direct access to the chip, and hammered on the security impact of having such undocumented commands, they could've probably achieved the same thing without resorting to lying.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#18

Post by pjc50 »

sschueller wrote: post #9

You 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

#19

Post by close04 »

atoav wrote: post #10
rswail wrote: post #4

In other words, this was a beatup for internet points, not, in any way, an actual security issue.

If their goal was to get espressif to explain undocumented functionality they reached it. And espressif should have closed that gap without external pressure.

> Researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco of Tarlogic Security, who presented their findings yesterday at 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

I'd like to believe the didn't have ulterior reasons to cry "backdoor" knowing that's not the case. That would be a huge indictment of the researchers' characters.

They wanted the spotlight and calling something a "backdoor in a chip used by a billion devices" does the job.

Re: ESP32 Undocumented Bluetooth Commands: Clearing the Air

#20

Post by Etheryte »

spaintech wrote: post #15

First 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…

This would require you to have root access to the thing, at that point you might as well write literally any code you like and not bother with the HCI commands.
Post reply on HN