louisabricot/writeup-cve-2019-19194Un writeup e una Proof-of-Concept teorica per CVE-2019-19194
Questa è una writeup e una Proof-of-Concept teorica della CVE-2019-19194.
⚠️ Questa CVE è stata scoperta da https://asset-group.github.io/disclosures/sweyntooth/
Questo report descrive come la vulnerabilità Zero LTK Initialisation (CVE-2019-19194) consente a un attaccante il pieno controllo della comunicazione di un'applicazione Bluetooth Low Energy (BLE) aggirando la procedura di pairing Secure Connections.
Questa vulnerabilità colpisce i prodotti che utilizzano le implementazioni SMP di Telink che supportano la procedura di pairing Secure Connections.
Il BLE è un sistema di comunicazione radio a corto raggio e basso consumo. Consiste in un insieme di protocolli standardizzati che forniscono connettività remota e sicurezza tra due dispositivi.
Lo stack BLE è distribuito su due blocchi architetturali: Host e Controller.
La distribuzione dello stack consente di implementare ciascun blocco in componenti fisicamente separati.
Un'interfaccia logica standard chiamata Host Controller Interface (HCI) consente la comunicazione tra i due blocchi.
Sopra al blocco Host si trova l'applicazione BLE.
Il livello fisico opera nella banda radio Industrial, Scientific and Medical (ISM), nello spettro dei 2.4GHz. Utilizza 40 canali: 3 canali advertising e 37 canali data.
Il livello di collegamento (LL) ha molte responsabilità che non verranno descritte qui. È governato da una macchina a stati che definisce ruoli e stati importanti:
Il logical link control and adaptation protocol agisce come livello di multiplexing dei protocolli. Gestisce la frammentazione e la ricombinazione dei pacchetti tra i livelli sottostanti e sovrastanti.
Il Generic Access Profile riguarda la scoperta e la connessione dei dispositivi. In altre parole, GAP definisce le procedure per la trasmissione dei pacchetti di advertising e la loro ricezione tramite scansione.
Una volta stabilita una connessione tra due dispositivi BLE, GATT utilizza un modello client/server per scambiare dati tra i due dispositivi. Sia il client che il server utilizzano l'Attribute Protocol (ATT).
Lo SM supporta procedure relative alla sicurezza come pairing, bonding e distribuzione delle chiavi. Il pairing dei dispositivi è considerato il fondamento della sicurezza Bluetooth: una volta effettuato il pairing, i due dispositivi possono cifrare la propria comunicazione, autenticarsi a vicenda, ...
Tra i diversi protocolli coinvolti nella comunicazione BLE, la CVE zero LTK installation si verifica durante la procedura di pairing, nella modalità Secure Connections.
La modalità di pairing Secure Connections è l'"approccio più sicuro" ed è stata sviluppata per risolvere le debolezze della modalità Legacy. Tuttavia, la CVE zero LTK installation ha scoperto che implementazioni errate del pairing SC consentono di aggirare la sicurezza.
Il dispositivo centrale invia una richiesta di pairing ed entrambi i dispositivi si scambiano le proprie capacità e i propri requisiti di sicurezza. Questa fase definisce la modalità di pairing.
Scambio di chiavi pubbliche: lo scambio di chiavi pubbliche viene avviato dal dispositivo centrale. Sia il periferico che il centrale verificano che la chiave ricevuta sia sulla curva P-256.
Calcolo della DHKey: ciascun dispositivo utilizza la propria chiave privata (SK) e la chiave pubblica dell'altro dispositivo (PK) per calcolare la propria chiave Diffie-Hellman (DHKey). In questo modo entrambi i dispositivi possiedono lo stesso valore di DHKey.
Central: DHKey = p256(SKc, PKp)
Peripheral: DHKey = p256(SKp, PKc)
Se è stata richiesta la protezione MITM, viene eseguita una procedura interattiva per confermare l'autenticità dei dispositivi in pairing.
Calcolo della Long Term Key (LTK) e conferma reciproca: i dispositivi si autenticano a vicenda e calcolano una chiave LTK. Dalla LTK viene derivata una chiave di sessione per cifrare il collegamento prima della Fase 3.
Attraverso il collegamento cifrato, i dispositivi possono distribuire le chiavi.
La causa principale di zero LTK installation è che non viene verificato lo stato in cui si trovano i due dispositivi nella procedura di pairing. Di conseguenza, un dispositivo centrale attaccante può saltare il passaggio di generazione delle chiavi e di autenticazione. Ciò comporta una chiave LTK impostata a 0 nel dispositivo periferico e, di conseguenza, una chiave di sessione facilmente derivabile.
⚠️ Questa è una Proof-of-Concept completamente teorica: non sono riuscito a ottenere una pcap delle procedure di discovery, advertisement o pairing BLE, né avevo un dispositivo BLE con implementazione SMP Telink.