I just read this article and found it quite interesting, so I’m sharing it.
If someone gains access to my home server through the ESP32’s Bluetooth, I doubt they could extract anything useful from my family pictures, videos, or custom programs.
Even so, I’ve decided to use an RPi Pico W in the future and disable Bluetooth from the start (prevention is better than cure) because it’s true that someone could spam through my router.
I don’t use Arduino for my projects but rather Micropython; even so, I know I’m not completely shielded from attacks.
Opening this up for discussion to hear everyone’s thoughts.
To turn off Bluetooth (BT) functionality on an ESP32 using MicroPython:
import bluetooth
# Initialize Bluetooth
bt = bluetooth.Bluetooth()
# Disable Bluetooth
bt.active(False)
print("Bluetooth is turned off.")
To turn off Bluetooth (BT) functionality on an ESP32 using Arduino:
#include <BluetoothSerial.h>
BluetoothSerial SerialBT;
void setup() {
// Start Bluetooth Serial
SerialBT.begin("ESP32_Device"); // Give your Bluetooth device a name
// Wait for a moment to establish the Bluetooth connection
Serial.println("Bluetooth device is ready to pair.");
// Delay for demonstration
delay(2000);
// Deactivate Bluetooth
SerialBT.end(); // This effectively turns off Bluetooth.
Serial.println("Bluetooth is turned off.");
}
void loop() {
// Your loop code (if any) goes here
}
BT is disabled by default on the ESP32, and a hacker won’t be able to pair with an ESP32 device unless it has BT enabled.
A standard Blynk sketch written in any programming language won’t give any BT access.
Of course, it could potentially be an issue for someone still using BT/BLE running under Blynk legacy local server on an ESP32 device.
If Matter provisioning via BT is implemented on ESP32 devices then that could potentially make a device vulnerable to a BT hack.
Well, technically speaking, you don’t need BT activated. An embedded or hidden code can access the intranet or internet via an established connection to a router.
That’s not what it says in the article you linked…
The risks arising from these commands include malicious implementations on the OEM level and supply chain attacks.
Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the commands might be possible via malicious firmware or rogue Bluetooth connections.
You either need access to add malicious firmware to the ESP32 via USB or OTA, or via a BT connection.
Well, I wasn’t referring to the article. It was just a general comment. A hidden embedded code can easily open a back door, though I’m not sure it would happen with ESPs. I need to check this with my son, who works in cybersecurity.
BTW, I hope your property here in Spain hasn’t suffered any damage from the recent rains.
All good in Spain thanks, although I’m in the UK at the moment. Looking forward to being back there in a few weeks.
The thing about using an ESP32 with Blynk is that 99.999% of the time they are running the code you’ve written, and connecting via a WiFi connection.
A hacker can’t use that WiFi connection to upload malicious code, or activate a “hidden backdoor” unless you’ve enabled OTA updates and you haven’t secured this access with a password.
The only other time an update is possible is when you plug the ESP into a COM port and upload new code.
These are WiFi/internet related vulnerabilities, which need to be exploited first before a BT vulnerability could be exploited. If a hacker has managed to gain access to the device via OTA or your PC then they don’t need to exploit BT vulnerabilities, as they already have control of the device.
The article is about using a BT connection to gain control of the ESP device rather than WiFi or OTA. That can’t happen if BT is turned off and the device isn’t accepting BT connections.
