Daniele Antonioli, un ricercatore di sicurezza Bluetooth che in precedenza ha sviluppato le tecniche di attacco BIAS, BLUR e KNOB, ha identificato due nuove vulnerabilità (CVE-2023-24023) nel meccanismo di negoziazione della sessione Bluetooth, che interessano tutte le implementazioni Bluetooth che supportano le modalità Connessioni sicure. " e "Secure Simple Pairing", conforme alle specifiche Bluetooth Core 4.2-5.4. A dimostrazione dell'applicazione pratica delle vulnerabilità identificate, sono state sviluppate 6 opzioni di attacco che ci permettono di incunearci nella connessione tra dispositivi Bluetooth precedentemente accoppiati. Su GitHub è pubblicato il codice con l'implementazione dei metodi di attacco e le utilità per la verifica delle vulnerabilità.
Le vulnerabilità sono state identificate durante l'analisi dei meccanismi descritti nello standard per il raggiungimento della segretezza anticipata (Forward e Future Secrecy), che contrastano la compromissione delle chiavi di sessione nel caso di determinazione di una chiave permanente (la compromissione di una delle chiavi permanenti non dovrebbe comportare alla decrittazione di sessioni precedentemente intercettate o future) e riutilizzo delle chiavi di sessione (una chiave di una sessione non dovrebbe essere applicabile a un'altra sessione). Le vulnerabilità rilevate consentono di aggirare la protezione specificata e riutilizzare una chiave di sessione inaffidabile in sessioni diverse. Le vulnerabilità sono causate da difetti nello standard di base, non sono specifiche dei singoli stack Bluetooth e compaiono in chip di diversi produttori.
I metodi di attacco proposti implementano diverse opzioni per organizzare lo spoofing delle connessioni Bluetooth classiche (LSC, Legacy Secure Connections basate su primitive crittografiche obsolete) e sicure (SC, Secure Connections basate su ECDH e AES-CCM) tra il sistema e un dispositivo periferico, come nonché l'organizzazione delle connessioni MITM, attacchi per connessioni in modalità LSC e SC. Si presuppone che tutte le implementazioni Bluetooth conformi allo standard siano suscettibili a qualche variante dell'attacco BLUFFS. Il metodo è stato dimostrato su 18 dispositivi di aziende come Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
L'essenza delle vulnerabilità si riduce alla capacità, senza violare lo standard, di forzare una connessione a utilizzare la vecchia modalità LSC e una chiave di sessione breve (SK) inaffidabile, specificando l'entropia minima possibile durante il processo di negoziazione della connessione e ignorando la contenuto della risposta con parametri di autenticazione (CR), che porta alla generazione di una chiave di sessione basata su parametri di input permanenti (la chiave di sessione SK viene calcolata come KDF dalla chiave permanente (PK) e parametri concordati durante la sessione) . Ad esempio, durante un attacco MITM, un utente malintenzionato può sostituire i parametri 𝐴𝐶 e 𝑆𝐷 con valori zero durante il processo di negoziazione della sessione e impostare l'entropia 𝑆𝐸 su 1, il che porterà alla formazione di una chiave di sessione 𝑆𝐾 con un'entropia effettiva di 1 byte (la dimensione minima standard dell'entropia è 7 byte (56 bit), che è paragonabile in termini di affidabilità alla selezione della chiave DES).
Se l'aggressore è riuscito a ottenere l'utilizzo di una chiave più breve durante la negoziazione della connessione, può utilizzare la forza bruta per determinare la chiave permanente (PK) utilizzata per la crittografia e ottenere la decrittografia del traffico tra i dispositivi. Poiché un attacco MITM può innescare l'uso della stessa chiave di crittografia, se questa chiave viene trovata, può essere utilizzata per decrittografare tutte le sessioni passate e future intercettate dall'aggressore.
Per bloccare le vulnerabilità, il ricercatore ha proposto di apportare modifiche allo standard che espandono il protocollo LMP e cambiano la logica di utilizzo di KDF (Key Derivation Function) durante la generazione di chiavi in modalità LSC. La modifica non interrompe la compatibilità con le versioni precedenti, ma comporta l'abilitazione del comando LMP esteso e l'invio di ulteriori 48 byte. Bluetooth SIG, responsabile dello sviluppo degli standard Bluetooth, ha proposto come misura di sicurezza di rifiutare le connessioni su un canale di comunicazione crittografato con chiavi di dimensioni fino a 7 byte. Le implementazioni che utilizzano sempre la modalità di sicurezza 4 livello 4 sono incoraggiate a rifiutare le connessioni con chiavi di dimensioni fino a 16 byte.
Fonte: opennet.ru