Pochi giorni fa, Liberati i ricercatori della Scuola Politecnica Federale di Losanna che hanno identificato vulnerabilità nei metodi di matchmaking dispositivi che soddisfano lo standard Bluetooth Classico (Bluetooth BR / EDR).
La vulnerabilità è denominata in codice BIAS e il problema consente all'aggressore di organizzare la connessione del suo dispositivo falso anziché del dispositivo da un utente precedentemente connesso e superare con successo la procedura di autenticazione senza conoscere la chiave del canale (chiave di collegamento) generata durante l'accoppiamento iniziale dei dispositivi e consentendo senza ripetere la procedura di conferma manuale su ogni connessione.
L'essenza del metodo è che quando ti connetti ai dispositivi che supportano la modalità Connessioni protette, il l'autore dell'attacco annuncia l'assenza di questa modalità e torna a utilizzare un metodo di autenticazione obsoleto (modalità "ereditata"). In modalità "legacy", l'attaccante avvia il cambio di ruolo master-slave e, presentando il suo dispositivo come "master", subentra alla procedura di autenticazione. Quindi l'attaccante invia una notifica sul completamento con successo dell'autenticazione, senza nemmeno avere una chiave del canale, e il dispositivo si autentica dall'altra parte.
Il Bluetooth Spoofing Attack (BIAS) può essere eseguito in due modi diversi, a seconda del metodo Secure Simple Pairing (Legacy Secure Connections o Secure Connections) precedentemente utilizzato per stabilire una connessione tra due dispositivi. Se la procedura di accoppiamento è stata completata utilizzando il metodo Connessioni protette, l'attaccante potrebbe affermare che è il dispositivo remoto precedentemente accoppiato a non supportare più le connessioni protette, riducendo la sicurezza dell'autenticazione.
Dopodiché, l'attaccante potrebbe riuscire a utilizzare una chiave di crittografia troppo corta, contenente solo 1 byte di entropia e applicare l'attacco KNOB sviluppato in precedenza dagli stessi ricercatori per stabilire una connessione Bluetooth crittografata con il pretesto di un dispositivo legittimo (se il dispositivo è protetto contro gli attacchi KNOB e la dimensione della chiave non può essere ridotta, l'attaccante non sarà in grado di stabilire un canale di comunicazione crittografato, ma continuerà ad essere autenticato sull'host).
Per uno sfruttamento di successo di vulnerabilità, il dispositivo dell'aggressore deve trovarsi nella portata del dispositivo Bluetooth vulnerabile e dell'aggressore è necessario determinare l'indirizzo del dispositivo remoto a cui è stata precedentemente effettuata la connessione.
I ricercatori hanno pubblicato un prototipo di toolkit che implementano il metodo di attacco proposto e hanno dimostrato come falsificare la connessione di uno smartphone Pixel 2 precedentemente accoppiato utilizzando un laptop Linux e una scheda Bluetooth CYW920819.
Il metodo BIAS può essere eseguito per i seguenti motivi: la creazione di una connessione sicura Bluetooth non è crittografata e la selezione del metodo di accoppiamento della connessione sicura non si applica per un accoppiamento già stabilito, la creazione di una connessione sicura di Legacy Secure Connections sì non richiede l'autenticazione reciproca, un dispositivo Bluetooth può eseguire un cambio di ruolo in qualsiasi momento dopo la ricerca in banda base e i dispositivi che sono stati accoppiati con Secure Connections possono utilizzare Legacy Secure Connections mentre stabiliscono una connessione sicura.
Il problema è causato da un difetto di memoria e si manifesta in più stack Bluetooth e il firmware dei chip Bluetooth, inclusi Intel, Broadcom, Cypress Semiconductor, Qualcomm, Apple e Samsung Token utilizzati in smartphone, laptop, computer a scheda singola e periferiche di vari produttori.
I ricercatori hanno testato 30 dispositivi (Apple iPhone / iPad / MacBook, Samsung Galaxy, LG, Motorola, Philips, Google Pixel / Nexus, Nokia, Lenovo ThinkPad, HP ProBook, Raspberry Pi 3B +, ecc.), Che utilizzano 28 chip diversi e hanno notificato ai produttori la vulnerabilità lo scorso dicembre. Non è ancora dettagliato quale dei produttori abbia rilasciato aggiornamenti del firmware con la soluzione.
Dato questo, l'organizzazione Bluetooth SIG responsabile dello sviluppo degli standard Bluetooth ha annunciato lo sviluppo di un aggiornamento alla specifica Bluetooth Core. La nuova edizione definisce chiaramente i casi in cui è consentito un cambio di ruolo master-slave, c'è un requisito obbligatorio per l'autenticazione reciproca quando si torna alla modalità 'legacy' e si consiglia di controllare il tipo di crittografia per evitare una diminuzione della connessione livello di protezione.
fonte: https://www.kb.cert.org