Attacchi a Bluetooth e BLE

Bluetooth è ovunque: cuffie, serrature, dispositivi medici, fitness tracker, sistemi di infotainment per automobili e sensori industriali. Il marchio comprende due tecnologie distinte:

• Bluetooth Classic (BR/EDR) — maggiore velocità di trasferimento, utilizzato per audio e trasferimento di file.
• Bluetooth Low Energy (BLE) — basso consumo energetico, utilizzato da dispositivi IoT, dispositivi indossabili e serrature smart.

Le due tecnologie differiscono per comportamento radio, pairing e stack di protocollo, quindi gli attacchi contro una raramente si applicano all'altra. BLE domina l'IoT ed è al centro della maggior parte delle valutazioni moderne, perché viene spesso implementato in modo non sicuro.

BLE opera nella banda dei 2.4 GHz su 40 canali. Tre di questi (37, 38, 39) sono canali di advertising utilizzati per la rilevazione; gli altri 37 trasportano i dati delle connessioni.

Il modello di dati principale è GATT (Generic Attribute Profile):

• i servizi raggruppano funzionalità correlate;
• le caratteristiche sono singoli punti dati che è possibile leggere, scrivere o sottoscrivere;
• ciascuno dispone di un UUID e di un handle.

Enumerare la tabella GATT rivela esattamente ciò che un dispositivo espone ed è il cuore della valutazione BLE.

La ricognizione inizia con la scansione dei pacchetti di advertising per scoprire cosa si trova nel raggio d'azione, quindi prosegue con la connessione per enumerare il database GATT.

Su Linux, lo stack BlueZ e strumenti come bluetoothctl, hcitool e gatttool permettono di scansionare e interrogare i dispositivi. nRF Connect su uno smartphone è un'ottima alternativa grafica.

Per osservare la comunicazione tra un dispositivo e la relativa app, deve intercettare il traffico via radio. Poiché BLE salta da un canale all'altro, uno sniffer deve seguire la connessione.

• Il dongle nRF52840 con il plugin nRF Sniffer per Wireshark è lo strumento di acquisizione economico più utilizzato.
• Ubertooth One è in grado di acquisire il traffico BLE e parte del traffico Classic.
• Acquisisca i dati durante il connection event per intercettare l'handshake iniziale.

Wireshark analizza i pacchetti acquisiti suddividendoli in dati di advertising, richieste di connessione e operazioni GATT, permettendo di mappare esattamente ciò che l'app legge e scrive.

La sicurezza BLE dipende dal metodo di pairing scelto durante l'associazione:

• Just Works — nessuna verifica dell'utente; per sua natura è vulnerabile agli attacchi man-in-the-middle. È estremamente comune nei dispositivi IoT economici.
• Passkey Entry — un codice di 6 cifre, più sicuro ma soggetto ad attacchi a forza bruta se implementato in modo inadeguato.
• Numeric Comparison — entrambi i dispositivi mostrano un numero da confermare (LE Secure Connections).

Il pairing legacy (precedente alla versione 4.2) è crittograficamente debole e le relative chiavi possono essere recuperate da un handshake acquisito. LE Secure Connections utilizza ECDH ed è l'unico metodo considerato robusto.

Quando un dispositivo utilizza il pairing legacy BLE, uno scambio di pairing acquisito può essere sottoposto a un attacco a forza bruta per recuperare la Temporary Key e infine la Long Term Key.

Lo strumento crackle automatizza questa procedura su un pcap dell'evento di pairing. Una volta recuperate le chiavi, è possibile decifrare il traffico precedentemente cifrato contenuto nell'acquisizione.

Molti dispositivi BLE si fidano di chiunque riesca a connettersi. Una volta enumerate le caratteristiche scrivibili, spesso è possibile inviare comandi direttamente senza autenticazione.

• Scritture non autenticate — l'invio di valori appositamente creati a una caratteristica di controllo può sbloccare serrature smart o commutare relè.
• Spoofing del dispositivo — clonare il MAC e l'advertisement di una periferica per impersonarla nei confronti dell'app della vittima.
• GATTacker / Mirage — framework che eseguono un attacco man-in-the-middle su una periferica facendo da proxy per il traffico GATT.

Un risultato tipico è una serratura smart il cui comando di sblocco consiste in una scrittura statica in testo non cifrato che chiunque può riprodurre.

Un proxy BLE per attacchi MITM clona la periferica bersaglio, consente all'app della vittima di connettersi al clone e inoltra il traffico al dispositivo reale. In questo modo espone l'intera conversazione e permette di modificarla in tempo reale.

Framework come Mirage e GATTacker automatizzano la clonazione degli advertisement e il collegamento tra due radio. È possibile acquisire, modificare o riprodurre qualsiasi operazione GATT durante il transito.

Bluetooth Classic ha una propria storia di problemi. Tra gli esempi più noti figurano BlueBorne (un insieme di vulnerabilità a livello di stack che consentono l'esecuzione remota di codice) e KNOB (Key Negotiation of Bluetooth), che forza la chiave di cifratura a una lunghezza attaccabile con la forza bruta.

• Molte cuffie e molti kit per automobili accettano ancora PIN deboli o predefiniti.
• Il rilevamento dei servizi tramite SDP può esporre le funzionalità del dispositivo e indizi sul firmware.
• Gli stack obsoleti potrebbero non essere aggiornati contro CVE note.

Per Classic, la valutazione si concentra sulla versione dello stack, sulla robustezza del pairing e sulla presenza di firmware vulnerabile noto.

I dispositivi BLE che trasmettono annunci in continuazione creano rischi per la privacy e il tracciamento. Un indirizzo MAC statico permette a un osservatore di seguire una persona in luoghi diversi.

• La randomizzazione del MAC cambia periodicamente l'indirizzo per impedire il tracciamento, ma molti dispositivi la implementano in modo inadeguato o non la implementano affatto.
• I payload di advertising identificabili (nomi fissi, dati del produttore) possono consentire di reidentificare un dispositivo anche con un MAC randomizzato.
• Le antenne direzionali a lunga portata estendono la distanza pratica di intercettazione ben oltre i 10 metri nominali.

Valutare l'esposizione al tracciamento è una parte legittima e importante della revisione della privacy BLE.

Le raccomandazioni difensive derivanti in genere da una valutazione BLE includono:

• Utilizzi LE Secure Connections con confronto numerico; non distribuisca mai Just Works per funzioni sensibili.
• Applichi crittografia e autenticazione a livello applicativo oltre a quelle del collegamento, così che un attacco MITM non possa riprodurre o contraffare i comandi.
• Implementi nonce per sessione o codici variabili per i comandi di controllo, come lo sblocco.
• Abiliti una corretta randomizzazione del MAC e rimuova i dati identificativi dagli advertisement.
• Mantenga lo stack Bluetooth aggiornato contro BlueBorne, KNOB e problemi simili.

L'insegnamento ricorrente è questo: la sicurezza a livello di collegamento non basta quando l'applicazione si fida di qualsiasi client connesso.

Verifichi la Sua comprensione della sicurezza del pairing BLE.

Ora è in grado di valutare dispositivi Bluetooth e BLE dall'inizio alla fine:

• BLE utilizza 40 canali ed espone i dati attraverso il modello GATT di servizi e caratteristiche.
• La ricognizione consiste nella scansione degli advertisement e nell'enumerazione del database GATT con gli strumenti BlueZ o nRF Connect.
• L'intercettazione con nRF52840 o Ubertooth alimenta Wireshark per l'analisi del protocollo.
• Just Works e il pairing legacy sono deboli; crackle recupera le chiavi dagli handshake legacy acquisiti.
• Gli attacchi attivi sfruttano scritture non autenticate e proxy MITM come Mirage e GATTacker.
• La difesa richiede LE Secure Connections, oltre all'autenticazione a livello applicativo e a comandi variabili.

Ora passerà dai protocolli connessi ai tag contactless con RFID e NFC.