RustyInjector

⚠️ 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.

• Non utilizzare questo codice per compromettere sistemi senza autorizzazione esplicita.
• Qualsiasi uso non autorizzato, illegale o non etico di questo progetto è severamente vietato.
• L'autore non si assume alcuna responsabilità per l'uso improprio o i danni causati da questo codice.

Scaricando, clonando o utilizzando questo codice, accetti di utilizzarlo in modo responsabile e nel rispetto di tutte le leggi e normative applicabili.

🦀 Rusty Injector !

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.

1. Come funziona?

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:

• Just Works (non autenticato)
• Numeric Comparison (autenticato)
• Passkey Entry (autenticato)
• Out of Band (autenticato) – Si basa su un'altra tecnologia per facilitare il processo di pairing.

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.

Un attaccante può impersonare i servizi e la classe di dispositivo di una tastiera wireless Bluetooth, sfruttare il modello di associazione 'Just Works' specificando una capacità 'NoInputNoOutput' e iniettare sequenze di tasti non autorizzate nel dispositivo target.

2. Come è stato implementato?

Per essere completamente onesti, l'unico obiettivo era reimplementare il proof of concept in Rust per comprendere più a fondo i dettagli di questo exploit. Ecco perché in questa prima iterazione l'architettura globale è stata ispirata dal PoC Python di Marc Newlin: Github "hi_my_name_is_keyboard". In una futura rielaborazione, potrebbe essere implementato in modo più rusty.

Crates (= Librerie Rust) utilizzate durante questa implementazione:

[dependencies]
bluer = { version = "0.17.3", features = ["l2cap", "bluetoothd", "id", "rfcomm"] }
tokio = "1.42.0"
regex = "1.11.1"
clap = { version = "4.5.23", features = ["derive"] }

La dipendenza chiave nel mio progetto era 'BlueR', un'API Rust costruita sopra la libreria C BlueZ originale. Puoi dare un'occhiata al loro lavoro qui: GitHub BlueR. Ho anche integrato Tokio per abilitare l'uso delle funzioni async fornite dalla libreria BlueR. Inoltre, ho utilizzato Clap, un parser di argomenti da riga di comando, e Regex, una crate che implementa le espressioni regolari in Rust, per convalidare gli input dell'utente per 'bt_addr' (Indirizzo Bluetooth).

Dopo aver osservato l'implementazione di Marc Newlin, ho scomposto l'architettura in diversi passaggi per replicare la stessa funzionalità:

1. Analizzare gli argomenti dell'utente utilizzati per ottenere:
   • --iface o -i che rappresenta l'interfaccia/adattatore Bluetooth da utilizzare. Questo argomento è facoltativo; se non specificato, tenterà di raggiungerne uno predefinito.
   • --target o -t che è obbligatorio e specifica l'indirizzo Bluetooth del target.
2. Distribuire un agente Bluetooth con capacità NoInputNoOutput per poter accedere al metodo di pairing "Just Works" durante la connessione con il dispositivo target.
3. Registrare un profilo con servizi di tastiera HID e registrare la classe 0x002540 per impersonare una tastiera.
4. Creare tutte le enumerazioni e le funzioni per convertire i nostri input nei byte HID corretti da inviare nei pacchetti HID.
5. Avviare le connessioni alle porte corrette sul livello L2CAP (Porta 1 - SDP, Porta 17 - HID Control e Porta 19 - HID Interrupt) e iniettare sequenze di tasti illegittime.

Ho cercato di commentare il mio codice il più possibile. Se lo esamini, riconoscerai facilmente tutti questi passaggi. Per renderlo più elegante, il prossimo passo sarebbe renderlo più rusty, avere una terminazione pulita e aggiungere molte altre funzionalità come la capacità di analizzare script di tastiera (payload preparati) o avere un'interfaccia utente grafica. Ancora una volta, questo era solo a scopo didattico; non sono sicuro di lavorare su altre iterazioni di questo programma. Ma ancora una volta, i contributi sono benvenuti. Se hai domande, non esitare a chiedere.

3. Come usarlo?

Prima cosa da notare: questo strumento è stato sviluppato e testato su Ubuntu 24.04.

Per utilizzare questo strumento, è necessario disabilitare il servizio HID predefinito registrato da BlueZ, in modo che possa essere registrato nuovamente all'avvio dell'exploit. Segui questi passaggi:

• Modifica il file di configurazione /etc/systemd/system/bluetooth.target.wants/bluetooth.service
• Modifica la riga: ExecStart=/usr/libexec/bluetooth/bluetoothd Con la seguente: ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=input
• Dopo aver modificato il file, è necessario ricaricare la configurazione di systemd e riavviare il servizio Bluetooth per applicare le modifiche. sudo systemctl daemon-reload sudo systemctl restart bluetooth

Ora devi semplicemente clonare il progetto ed eseguirlo compilandolo con cargo build o eseguendolo direttamente specificando gli argomenti con: cargo run -- -i [BT_INTERFACE] -t [BT_TARGET].

Immagine 3: Interfaccia a riga di comando di Rusty Injector.

Ecco un esempio: cargo run -- -i hci0 -t AA:BB:CC:DD:EE:FF

Un'altra cosa da notare è che se desideri modificare il codice e utilizzare la funzione "set_address" tramite il trait Configuration, devi installare il tool bdaddr per poterlo utilizzare:

# build bdaddr dai sorgenti bluez
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/

Tieni presente che se non specifichi alcuna interfaccia Bluetooth, tenterà di raggiungerne una predefinita. E OVVIAMENTE, non dimenticare di collegare un'interfaccia Bluetooth al tuo sistema Ubuntu.🙃

Credo di aver coperto tutto: ora sei pronto per sfruttare al meglio Rusty Injector! Se incontri problemi, hai commenti o feedback, sentiti libero di aprire un issue. Buona esperienza e buon hacking! 🚀