Miliardi di smartphone, tablet, laptop e dispositivi IoT utilizzano stack di software Bluetooth che sono vulnerabili a una nuova falla di sicurezza rivelata durante l’estate. Chiamato BLESA ( B luetooth L ow E NERGY S poofing A ttack), la vulnerabilità interessa i dispositivi che eseguono il protocollo Bluetooth Low Energy (BLE). BLE è una versione più sottile del classico Bluetooth originale, ma progettata per conservare la carica della batteria mantenendo attive le connessioni Bluetooth il più a lungo possibile.
Grazie alle sue funzionalità di risparmio della batteria, BLE è stato ampiamente adottato negli ultimi dieci anni, diventando una tecnologia quasi onnipresente in quasi tutti i dispositivi alimentati a batteria. Come risultato di questa ampia adozione, nel corso degli anni i ricercatori e gli accademici della sicurezza hanno anche esaminato ripetutamente BLE alla ricerca di falle nella sicurezza, spesso riscontrando problemi importanti.
Gli accademici e il loro studio del processo di “riconnessione” Bluetooth
Tuttavia, la stragrande maggioranza di tutte le ricerche precedenti sui problemi di sicurezza di BLE si è concentrata quasi esclusivamente sul processo di accoppiamento e ha ignorato grandi parti del protocollo BLE. In un progetto di ricerca presso la Purdue University, un team di sette accademici ha deciso di indagare su una sezione del protocollo BLE che svolge un ruolo cruciale nelle operazioni BLE quotidiane, ma è stata raramente analizzata per problemi di sicurezza.
Il loro lavoro si è concentrato sul processo di “riconnessione”. Questa operazione viene eseguita dopo che due dispositivi BLE (client e server) si sono autenticati a vicenda durante l’operazione di associazione. Le riconnessioni avvengono quando i dispositivi Bluetooth si spostano fuori dal raggio d’azione e poi rientrano nuovamente nell’intervallo più tardi. Normalmente, quando si ricollegano, i due dispositivi BLE dovrebbero controllare reciprocamente le chiavi crittografiche negoziate durante il processo di associazione, quindi ricollegarsi e continuare a scambiare dati tramite BLE.
Ma il team di ricerca della Purdue ha affermato di aver scoperto che la specifica ufficiale BLE non conteneva un linguaggio sufficientemente forte per descrivere il processo di riconnessione. Di conseguenza, due problemi sistemici si sono fatti strada nelle implementazioni software BLE, lungo la catena di fornitura del software:
- L’autenticazione durante la riconnessione del dispositivo è facoltativa anziché obbligatoria.
- L’autenticazione può essere potenzialmente aggirata se il dispositivo dell’utente non riesce a imporre al dispositivo IoT di autenticare i dati comunicati.
Questi due problemi lasciano la porta aperta per un attacco BLESA, durante il quale un utente malintenzionato nelle vicinanze aggira le verifiche di riconnessione e invia dati falsificati a un dispositivo BLE con informazioni errate e induce operatori umani e processi automatizzati a prendere decisioni errate. Per farvi un’idea qui sotto trovate una demo di un attacco BLESA.
Presi di mira diversi stack di software BLE
Tuttavia, nonostante il linguaggio vago, il problema non è stato inserito in tutte le implementazioni del mondo reale di BLE. I ricercatori della Purdue hanno affermato di aver analizzato più stack di software che sono stati utilizzati per supportare le comunicazioni BLE su vari sistemi operativi. I ricercatori hanno scoperto che BlueZ (dispositivi IoT basati su Linux), Fluoride (Android) e lo stack iOS BLE erano tutti vulnerabili agli attacchi BLESA, mentre lo stack BLE nei dispositivi Windows era immune.
“A giugno 2020, mentre Apple ha assegnato il CVE-2020-9770 alla vulnerabilità e l’ha risolta, l’implementazione di Android BLE nel nostro dispositivo testato (ad esempio, Google Pixel XL con Android 10) è ancora vulnerabile”, hanno detto i ricercatori in un articolo. Per quanto riguarda i dispositivi IoT basati su Linux, il team di sviluppo di BlueZ ha dichiarato che rimuoverà la parte del suo codice che apre i dispositivi agli attacchi BLESA e, invece, utilizzerà un codice che implementa procedure di riconnessione BLE adeguate, immune a BLESA.
Risolvere il problema può risultare in un vero incubo
Purtroppo, proprio come con tutti i precedenti bug Bluetooth, la patch di tutti i dispositivi vulnerabili sarà un incubo per gli amministratori di sistema e la patch di alcuni dispositivi potrebbe non essere un’opzione. Alcune apparecchiature IoT con risorse limitate che sono state vendute negli ultimi dieci anni e già distribuite sul campo oggi non sono dotate di un meccanismo di aggiornamento integrato, il che significa che questi dispositivi rimarranno permanentemente privi di patch.
Difendersi dalla maggior parte degli attacchi Bluetooth di solito significa accoppiare dispositivi in ambienti controllati, ma difendersi da BLESA è un compito molto più difficile, poiché l’attacco ha come obiettivo l’operazione di riconnessione più frequente. Gli aggressori possono utilizzare bug denial-of-service per rendere le connessioni Bluetooth offline e attivare un’operazione di riconnessione su richiesta, quindi eseguire un attacco BLESA. Proteggere i dispositivi BLE da disconnessioni e cadute di segnale è impossibile.
A peggiorare le cose, sulla base delle precedenti statistiche sull’utilizzo di BLE, il team di ricerca ritiene che il numero di dispositivi che utilizzano gli stack di software BLE vulnerabili sia dell’ordine di miliardi. Tutti questi dispositivi sono ora in balia dei loro fornitori di software, attualmente in attesa di una patch. Ulteriori dettagli sull’attacco BLESA sono disponibili in un documento intitolato “BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy”. Il documento è stato presentato alla conferenza USENIX WOOT 2020 ad agosto.
