Daniele Antonioli, ricercatore sulla sicurezza Bluetooth e precedentemente autore delle tecniche di attacco BIAS, BLUR e KNOB, ha identificato due nuove vulnerabilità (CVE-2023-24023) nel meccanismo di accordo delle sessioni Bluetooth, che interessano tutte le implementazioni Bluetooth che supportano le modalità di accoppiamento sicuro "Secure Connections" e "Secure Simple Pairing", conformi alle specifiche Bluetooth Core 4.2-5.4. Come dimostrazione pratica delle vulnerabilità riscontrate, sono state sviluppate 6 varianti di attacco che consentono di infiltrarsi nella connessione tra dispositivi Bluetooth già accoppiati. Il codice per l'implementazione delle tecniche di attacco e gli strumenti per verificare la presenza delle vulnerabilità sono stati pubblicati su GitHub.
Sono state identificate vulnerabilità durante l'analisi dei meccanismi descritti nello standard per garantire la segretezza diretta (Forward and Future Secrecy), che contrastano la compromissione delle chiavi di sessione nel caso di una chiave permanente identificata (la compromissione di una delle chiavi permanenti non dovrebbe portare alla decrittazione di sessioni precedentemente intercettate o future) e riutilizzo delle chiavi di sessione (la chiave di una sessione non dovrebbe essere applicabile a un'altra sessione). Le vulnerabilità trovate consentono di eludere la protezione indicata e riutilizzare una chiave di sessione non sicura in diverse sessioni. Queste vulnerabilità sono causate da lacune nel standard di base, non specifiche per singoli stack Bluetooth, e si manifestano in chip di vari produttori.
I metodi di attacco proposti realizzano diverse varianti di spoofing delle connessioni Bluetooth classiche (LSC, Legacy Secure Connections basate su primitivi crittografici obsoleti) e sicure (SC, Secure Connections basate su ECDH e AES-CCM) tra il sistema e il dispositivo periferico, oltre a organizzare attacchi MITM per le connessioni in modalità LSC e SC. Si presume che tutte le implementazioni Bluetooth conformi allo standard siano vulnerabili a varianti dell'attacco BLUFFS. La funzionalità del metodo è stata dimostrata su 18 dispositivi di aziende come Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
La natura delle vulnerabilità risiede nella possibilità di forzare, senza violare lo standard, un ritorno a una modalità LSC obsoleta e a una chiave di sessione (SK) breve e non affidabile, specificando durante il processo di negoziazione della connessione l'entropia minima possibile e ignorando il contenuto della risposta con i parametri di autenticazione (CR). Questo porta alla generazione di una chiave di sessione basata su parametri di ingresso costanti (la chiave di sessione SK è calcolata come KDF dalla chiave costante (PK) e dai parametri concordati durante la sessione). Ad esempio, un attaccante durante un attacco MITM può sostituire nel processo di negoziazione della sessione i parametri 𝐴𝐶 e 𝑆𝐷 con valori nulli, impostando l'entropia 𝑆𝐸 a 1, il che porterà alla creazione di una chiave di sessione 𝑆𝐾 con effettiva entropia di 1 byte (la dimensione minima standard dell'entropia è di 7 byte (56 bit), che in termini di sicurezza è comparabile alla forza del cracking delle chiavi DES).
Se un attaccante riesce a ottenere l'utilizzo di una chiave più corta durante il processo di negoziazione della connessione, può poi utilizzare la forza bruta per determinare la chiave permanente (PK) utilizzata per la crittografia e decrittare il traffico tra i dispositivi. Poiché durante un attacco MITM è possibile avviare l'uso della stessa chiave di crittografia, se tale chiave viene scoperta, può essere utilizzata anche per decrittare tutte le sessioni passate e future intercettate dall'attaccante.
Per bloccare le vulnerabilità, è stato proposto dai ricercatori di apportare modifiche allo standard che ampliano il protocollo LMP e cambiano la logica di utilizzo della KDF (Key Derivation Function) durante la generazione delle chiavi in modalità LSC. La modifica non compromette la retrocompatibilità, ma comporta l'inclusione di un comando LMP esteso e la necessità di inviare 48 byte aggiuntivi. L'organizzazione Bluetooth SIG, che si occupa dello sviluppo degli standard Bluetooth, ha suggerito come misura di protezione di rifiutare le connessioni tramite canali crittografati con chiavi di dimensioni fino a 7 byte. Le implementazioni che utilizzano sempre il livello di Security Mode 4 Level 4 sono consigliate a rifiutare connessioni con chiavi di dimensioni fino a 16 byte.
Fonte: opennet.ru
