Daniele Antonioli, ricercatore di sicurezza Bluetooth che in precedenza ha sviluppato tecniche di attacco BIAS, BLUR e KNOB, ha identificato due nuove vulnerabilità (CVE-2023-24023) nel meccanismo di negoziazione delle sessioni Bluetooth, che colpiscono tutte le implementazioni Bluetooth che supportano le modalità di accoppiamento sicuro "Secure Connections" e "Secure Simple Pairing", in conformità con le specifiche Bluetooth Core 4.2-5.4. Come dimostrazione pratica delle vulnerabilità identificate, sono stati sviluppati sei varianti di attacco in grado di infiltrarsi in una connessione tra dispositivi Bluetooth già accoppiati. Il codice per l'implementazione dei metodi di attacco e gli strumenti per verificare la presenza di vulnerabilità sono stati pubblicati su GitHub.
Le vulnerabilità sono state identificate durante l'analisi dei meccanismi descritti nello standard per garantire segretezza diretta (Forward and Future Secrecy), che contrastano la compromissione delle chiavi di sessione in caso di individuazione di una chiave permanente (la compromissione di una chiave permanente non dovrebbe portare alla decrittazione di sessioni precedentemente intercettate o future) e al riutilizzo delle chiavi di sessione (la chiave di una sessione non dovrebbe essere applicabile a un'altra sessione). Le vulnerabilità trovate permettono di aggirare questa protezione e di riutilizzare una chiave di sessione poco sicura in diverse sessioni. Le vulnerabilità sono causate da inadeguatezze nello standard di base, non sono specifiche per singoli stack Bluetooth e si manifestano in chip di vari produttori.
I metodi di attacco proposti implementano diverse varianti di spoofing di connessioni Bluetooth classiche (LSC, Legacy Secure Connections basate su primitivi crittografici obsoleti) e sicure (SC, Secure Connections basate su ECDH e AES-CCM) tra un sistema e un dispositivo periferico, oltre a organizzare attacchi MITM per connessioni nelle modalità LSC e SC. Si presume che tutte le implementazioni Bluetooth conformi allo standard siano vulnerabili ad alcune varianti dell'attacco BLUFFS. L'efficacia del metodo è stata dimostrata su 18 dispositivi di aziende come Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
La sostanza delle vulnerabilità riguarda la possibilità di revertire forzatamente la connessione a un utilizzo della modalità LSC obsoleta e di una chiave di sessione (SK) breve e non sicura, senza violare lo standard, specificando durante il processo di negoziazione della connessione la minima entropia possibile e ignorando il contenuto della risposta con i parametri di autenticazione (CR), il che porta alla generazione di una chiave di sessione basata su parametri d'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 e impostare l'entropia 𝑆𝐸 a 1, il che porterà alla formazione di una chiave di sessione 𝑆𝐾 con un'entropia effettiva di 1 byte (la dimensione minima standard dell'entropia è di 7 byte (56 bit), che per livello di affidabilità è comparabile a un attacco di brute force sulla chiave DES).
Se l'attaccante è riuscito a ottenere l'uso di una chiave più corta durante il processo di negoziazione della connessione, può quindi tramite attacco di brute force determinare la chiave costante (PK) utilizzata per la crittografia e riuscire a decriptare il traffico tra i dispositivi. Poiché durante un attacco MITM è possibile avviare l'uso della stessa chiave di crittografia, se questa chiave viene trovata, può essere utilizzata anche per decriptare tutte le sessioni passate e future intercettate dall'attaccante.
Per bloccare le vulnerabilità, è stato proposto dai ricercatori di apportare modifiche allo standard, che espandono il protocollo LMP e modificano la logica di utilizzo del KDF (Key Derivation Function) nella formazione delle chiavi in modalità LSC. La modifica non compromette la retrocompatibilità, ma porta all'inclusione di un comando LMP esteso e alla necessità di inviare ulteriori 48 byte. L'organizzazione Bluetooth SIG, responsabile dello sviluppo degli standard Bluetooth, ha proposto come misura di protezione di rifiutare le connessioni tramite canale di comunicazione crittografato con chiavi di dimensione fino a 7 byte. Alle implementazioni che applicano sempre il livello Security Mode 4 Level 4, si raccomanda di rifiutare connessioni con chiavi di dimensione fino a 16 byte.
Fonte: opennet.ru
