README

Repository sugli attacchi BLUR presentati ad AsiaCCS'22 nell'articolo intitolato: BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy.

Link utili: pdf, video, slides, website.

Voce BibTex:

@inproceedings{antonioli22blur,
    author={Antonioli, Daniele and Tippenhauer, Nils Ole and Rasmussen, Kasper
    and Payer, Mathias},
    title={{BLURtooth: Exploiting Cross-Transport Key Derivation in
    Bluetooth Classic and Bluetooth Low Energy}},
    booktitle={Proceedings of the  Asia conference on computer and
    communications security (ASIACCS)},
    month={May},
    year={2022}
}

Agli attacchi BLUR sono stati assegnati CVE-2020-15802 e CVE-2022-20361.

Inizializzazione

Nel resto del README indicheremo Bluetooth Classic (anche BR/EDR) come BT, Bluetooth Low Energy come BLE, e Cross-Transport Key Derivation come CTKD. Assumiamo inoltre che il dispositivo dell'attaccante e le vittime supportino BT, BLE e CTKD. Ciò significa che i dispositivi supportano Bluetooth 4.2+ e BT/BLE Secure Connections.

Il modo più semplice per eseguire gli attacchi è usare un unico dispositivo sia come vittima che come dispositivo d'attacco. Ad esempio, consigliamo di usare un laptop Linux come vittima/dispositivo d'attacco e qualsiasi altro dispositivo come altra vittima.

Stiamo usando una macchina Linux con bluez e bluez tools. Facciamo affidamento sullo strumento btmgmt e potrebbe essere utile dare un'occhiata al suo codice sorgente. In particolare usiamo il suo sottocomando pair poiché, tra le altre cose, consente di inviare richieste di pairing arbitrarie su BT/BLE dichiarando capacità input-output arbitrarie.

Usage: pair [-c cap] [-t type] <remote address>

Se vuoi riprodurre lo scenario d'attacco esatto presentato nel nostro articolo, devi fare del lavoro extra. Nello specifico devi riprodurre la configurazione presentata nell' attacco BIAS. Una volta che la tua configurazione è pronta, dovresti essere in grado di usare la scheda di sviluppo come tuo Controller BT/BLE e il laptop Linux come Host. Inoltre, dovresti essere in grado di sniffare i pacchetti del link layer dall'Host (ad esempio il traffico BT LMP) e di patchare dinamicamente il firmware della scheda di sviluppo a runtime usando internalblue.

Eseguire gli attacchi BLUR

Hardcodare le capacità NoInputNoOutput (senza rimuovere il flag MitM)

Questo passaggio è facoltativo e richiede di patchare il proprio kernel Linux.

Quando si usa btmgmt -c 3, bluez rimuove automaticamente il flag di protezione MitM, ad esempio imposta il byte AuthReq a 0x02 invece di 0x03. Tuttavia, gli attacchi BLUR non richiedono di rimuovere questo flag, ma richiedono solo di dichiarare capacità NoInputNoOutput quando il dispositivo remoto supporta capacità input-output. Con questo trucco la procedura di pairing viene declassata a Just Works senza rimuovere il flag MitM.

Implementare questa configurazione richiede una modifica minima del kernel Linux. In particolare, in /net/bluetooth/hci_event.c cambiamo:

cp.authentication = conn->auth_type;

in:

cp.authentication = 0x03;

In questo modo, hardcodiamo il nostro flag AuthReq a 0x03 indipendentemente dalle capacità input-output che dichiariamo.

Pairing legittimo

Esegui il pairing dei dispositivi vittima come al solito. Ad esempio, se stai prendendo di mira uno smartphone, esegui il pairing con il tuo laptop (che agisce sia come vittima che come dispositivo d'attacco). Potrebbe essere richiesta qualche interazione da parte dell'utente come parte del pairing (ad esempio, Numeric Comparison).

Aprire una shell btmgmt

Prendi nota dell'indirizzo Bluetooth della vittima, indicato come REMOTE-BTADD
Apri un terminale
Esegui hciconfig e prendi nota del tuo indice hci, ad esempio 0
Esegui sudo btmgmt -i 0
Dovresti vedere un prompt del terminale blu contenente [hci0] #

Attacco di Central Impersonation su BLE, [sovra]scrittura della chiave di pairing BT

Qui assumo che la vittima stia usando un indirizzo BLE pubblico. Se ne sta usando uno casuale, cambia l'opzione -t in 2

Dalla CLI di btmgmt esegui:

pair -t 1 REMOTE-BTADD

Se devi anche declassare l'associazione a Just Works esegui:

pair -c 3 -t 1 REMOTE-BTADD

Il flag -c imposta le capacità input-output dell'attaccante e un valore di 0x3 corrisponde a NoInputNoOutput, mentre il valore predefinito per un laptop/smartphone è 0x1 che corrisponde a Display Yes/No.

Attacco di Peripheral Impersonation su BT, [sovra]scrittura della chiave di pairing BLE

In questo caso, anche se impersoniamo un periferica BLE, eseguiamo il pairing su BT come Central.

Dalla CLI di btmgmt esegui:

pair -t 0 REMOTE-BTADD

Se devi anche declassare l'associazione a Just Works esegui:

pair -c 3 -t 0 REMOTE-BTADD

Attacchi di sessione non intenzionali (Unintended session attacks)

Ripeti gli attacchi descritti sopra impersonando un dispositivo che è attualmente sconosciuto (cioè non associato) alla vittima.

Q&A (Bluetooth, CTKD, Linux, bluez, Wireshark)

Come imposto il mio dispositivo BT/BLE come scopribile/connettibile/associabile?

Dalla CLI bluetoothctl puoi impostare discoverable su on o off e pairable. Dalla CLI btmgmt puoi anche impostare il flag connectable.

Come posso controllare per quanto tempo il mio dispositivo è scopribile?

Da bluetoothctl, puoi controllare il timeout di scopribilità usando discoverable-timeout, ad esempio, se lo imposti a 0 il dispositivo è sempre scopribile.

Come posso verificare se il mio dispositivo BT/BLE supporta il pairing o è associabile?

Per BT, durante il pairing con un dispositivo remoto sia come Central che come Peripheral, riceverai il seguente pacchetto LMP: LMP not accepted ext (opcode: 0x02) con pairing non consentito (codice di errore: 0x18)

Per BLE, durante il pairing con un dispositivo remoto sia come Central che come Peripheral, riceverai il seguente pacchetto SMP: SMP Pairing Failed Command (opcode 0x05) con Pairing Not Supported (motivo 0x05).

Come posso verificare se il mio dispositivo BT/BLE supporta Secure Connections?

Per BT, durante il pairing con un dispositivo remoto, controlla il supporto a Secure Connections per l'Host e il Controller nei pacchetti delle feature LMP, ad esempio usando il seguente filtro di visualizzazione di Wireshark: btbrlmp.efeat.scc or btbrlmp.efeat.sch.

Per BLE, durante il pairing con un dispositivo remoto, nella SMP Pairing Request o Response controlla il byte AuthReq contenente il flag Secure Connection, ad esempio usando il seguente filtro di visualizzazione di Wireshark: btsmp.sc_flag == 1.

Come posso verificare se il mio dispositivo BT/BLE supporta CTKD?

Per BT, durante il pairing con un dispositivo remoto, il traffico SMP BLE viene incapsulato su L2CAP. Quindi usando il filtro Wireshark btl2cap.payload dovresti vedere un pacchetto dal Central al Peripheral contenente un payload che inizia con 0x01 (SMP Pairing Request) e un altro pacchetto nella direzione opposta con un payload che inizia con 0x02 (SMP Pairing Response). Dovresti anche vedere altri pacchetti L2CAP grezzi che codificano la fase di distribuzione delle chiavi SMP.

Per BLE, durante il pairing con un dispositivo remoto, nella SMP Pairing Request o Response controlla che sia il Central che il Peripheral siano disposti a inviare e ricevere una chiave di link durante la distribuzione delle chiavi SMP, ad esempio usando il seguente filtro Wireshark btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.

blur

Più Popolari