xg3nesis/rustyinjectorImplementazione in Rust della prova di concetto di Marc Newlin sull'iniezione di sequenze di tasti (CVE-2023-45866).
⚠️ Disclaimer: Solo a scopo di Ricerca e Didattica
Questo progetto è un Proof of Concept (PoC) che dimostra l'iniezione di sequenze di tasti Bluetooth, reimplementato in Rust. È destinato esclusivamente a scopi didattici e di ricerca sulla sicurezza.
Scaricando, clonando o utilizzando questo codice, accetti di utilizzarlo in modo responsabile e nel rispetto di tutte le leggi e normative applicabili.
Benvenuto in Rusty Injector — un'implementazione in Rust ispirata al PoC di iniezione di sequenze di tasti Bluetooth di Marc Newlin, legato a CVE-2023-45866, CVE-2024-21306 e CVE-2024-0230.
Attualmente, questo repository implementa solo la CVE-2023-45866, che sfrutta le vulnerabilità di iniezione di sequenze di tasti in BlueZ sul sistema operativo Linux.
Di seguito una schermata della descrizione NIST, inclusa la valutazione CVSS:
Immagine 1: Descrizione NIST della CVE-2023-45866.
Le altre CVE, CVE-2024-21306 e CVE-2024-0230, non sono previste per essere implementate da me, ma i contributi sono benvenuti.
Prima di entrare nei dettagli, ti incoraggio a guardare la presentazione di Marc Newlin alla conferenza NullCon 2024, che offre una spiegazione chiara e approfondita di queste vulnerabilità: Hi, My Name Is keyboard di Marc Newlin.
Ho anche reso disponibile un video che divulgala questa vulnerabilità. Lo trovi qui: Come un semplice hack Bluetooth può dirottare il tuo dispositivo - Hi, my name is keyboard.
📌 Se noti punti mancanti, aree che potrebbero essere meglio semplificate o potenziali errori nella spiegazione qui sotto, sentiti libero di modificarla e inviare una richiesta di merge. Sarò lieto di rivedere i tuoi contributi e incorporarli nel repository.
Poiché abbiamo coperto solo la vulnerabilità CVE-2023-45866 relativa ai sistemi operativi Linux, spieghiamo solo il processo per raggiungere questo specifico sfruttamento che ha come target la libreria BlueZ.
Prima di tutto, devi capire che questa vulnerabilità è sfruttabile solo su Bluetooth BR/EDR perché ha come target il profilo HID che si basa su questa tecnologia. Potresti sapere che l'implementazione architetturale del Bluetooth è suddivisa in più livelli, come il modello OSI per il protocollo Ethernet, come puoi osservare nel nostro schema qui sotto.
Diagramma 1: Stack Bluetooth BR/EDR (Basic Rate - Enhanced Data Rate) semplificato. Il livello più basso dello stack rappresenta il livello fisico con un'antenna dedicata, mentre il livello più alto rappresenta il livello applicativo o ciò che a volte possiamo designare come sistema operativo. Quando due dispositivi vogliono comunicare tra loro, attraversano questi diversi livelli: dall'alto verso il basso per i pacchetti in uscita e dal basso verso l'alto per i pacchetti Bluetooth in arrivo.
Dopo il processo di inquiry, una volta che i dispositivi determinano di voler stabilire una connessione, procedono al processo di pairing. Questo processo consente l'autenticazione reciproca tra i dispositivi e la creazione di una chiave di crittografia, che viene poi utilizzata per proteggere la comunicazione.
La specifica Bluetooth offre diversi livelli di autenticazione e sicurezza. A seconda del meccanismo utilizzato per l'autenticazione, il livello di sicurezza della comunicazione può variare. I dispositivi possono autenticarsi in base alle periferiche di input e output che possiedono, un concetto chiamato modelli di associazione. Probabilmente lo hai incontrato quando hai accoppiato due dispositivi, ad esempio quando ti è stato chiesto di inserire un codice PIN visualizzato sull'altro dispositivo.
Esistono quattro modelli di associazione per il pairing, determinati dalle capacità I/O (Input/Output) dei dispositivi:
Di seguito una tabella che mostra quale modello di associazione viene utilizzato in base alle capacità dei nostri dispositivi IoT.
Diagramma 2: Tabella che illustra i modelli di associazione Bluetooth BR/EDR ispirata alla specifica Bluetooth Core v5.3 - 2.3.5.1 Selezione del metodo di generazione delle chiavi Tabella 2.8: Mappatura delle capacità IO al metodo di generazione delle chiavi (pagina 1573). Per maggiori informazioni sui modelli di sicurezza e di associazione, consulta questo interessante articolo pubblicato da Thyrasec: Sicurezza Bluetooth: Classic & BLE!
Sono sicuro che sei incuriosito dal metodo 'Just Works', che è proprio dove risiede la nostra vulnerabilità. Ecco il problema: questo metodo stabilisce il pairing senza richiedere conferma o interazione da parte dell'utente, non lasciando modo di verificare l'autenticità del dispositivo che effettua il pairing. Sui sistemi Linux, lo stack BlueZ, per impostazione predefinita, accettava richieste di pairing in arrivo da dispositivi classificati come NoInputNoOutput (per garantire la retrocompatibilità). Una scelta progettuale davvero "meravigliosa", non credi?
Immagine 2: Aggiornamento della configurazione predefinita di BlueZ per abilitare la sicurezza Bluetooth e correggere la CVE-2023-45866.
Dopo aver effettuato il pairing con il dispositivo target, il nostro sistema stabilisce una connessione al Service Discovery Protocol (SDP) attraverso la porta 1 del livello L2CAP. Come mostrato nel Diagramma 1, il livello L2CAP funge da intermediario tra i livelli di servizio inferiori e superiori, fornendo segmentazione, multiplexing e riassemblaggio dei pacchetti di dati. Attraverso la connessione SDP, identifichiamo tutti i servizi disponibili sul dispositivo target e ci colleghiamo al servizio Human Interface Profile (HID). Il profilo HID, utilizzato dai sistemi operativi per elaborare input da tastiere e mouse Bluetooth, opera tramite le porte 17 (HID Control) e 19 (HID Interrupt) del livello L2CAP. Per accedere al profilo HID non è richiesta autenticazione e qualsiasi dispositivo connesso alle porte 17 e 19 del L2CAP viene riconosciuto come dispositivo HID.
