francozappa/blurBLURtooth: Ausnutzung der Schlüsselableitung über Transporte hinweg bei Bluetooth Classic und Bluetooth Low Energy [CVE-2020-15802] [CVE-2022-20361]
Repository über die BLUR-Angriffe, die auf der AsiaCCS'22 in dem Paper mit dem Titel: BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy. präsentiert wurden.
Nützliche Links: pdf, video, slides, website.
BibTeX-Eintrag:
@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}
}
Die BLUR-Angriffe haben die folgenden CVE-IDs erhalten: CVE-2020-15802 und CVE-2022-20361.
Im restlichen Teil dieser README bezeichnen wir Bluetooth Classic (auch BR/EDR) als BT, Bluetooth Low Energy als BLE und Cross-Transport Key Derivation als CTKD. Wir gehen außerdem davon aus, dass das Angriffsgerät und die Opfer BT, BLE und CTKD unterstützen. Das bedeutet, dass die Geräte Bluetooth 4.2+ und BT/BLE Secure Connections unterstützen.
Der einfachste Weg, die Angriffe durchzuführen, besteht darin, ein Gerät sowohl als Opfer als auch als Angriffsgerät zu verwenden. Zum Beispiel empfehlen wir, ein Linux-Laptop als Opfer-/Angriffsgerät und ein beliebiges anderes Gerät als das andere Opfer zu verwenden.
Wir verwenden einen Linux-Rechner mit bluez
und bluez-Tools. Wir
verlassen uns auf das btmgmt-Tool, und es könnte hilfreich sein, einen Blick auf seinen
Quellcode zu werfen. Insbesondere verwenden wir den Unterbefehl pair, da er unter anderem das Senden beliebiger Pairing-Anfragen über BT/BLE ermöglicht, während beliebige Eingabe-/Ausgabefähigkeiten deklariert werden.
Usage: pair [-c cap] [-t type] <remote address>
Wenn Sie das genaue Angriffsszenario aus unserem Paper reproduzieren möchten, müssen Sie etwas zusätzliche Arbeit leisten. Insbesondere müssen Sie das Setup nachbilden, das im BIAS-Angriff vorgestellt wird. Sobald Ihr Setup bereit ist, sollten Sie das Entwicklungsboard als Ihren BT/BLE-Controller und das Linux-Laptop als Host verwenden können. Darüber hinaus sollten Sie in der Lage sein, die Link-Layer-Pakete vom Host zu sniffen (z.B. BT LMP-Verkehr) und die Firmware des Entwicklungsboards zur Laufzeit dynamisch mit internalblue zu patchen.
Dieser Schritt ist optional und erfordert das Patchen Ihres eigenen Linux-Kernels.
Bei Verwendung von btmgmt -c 3 deaktiviert bluez automatisch das MitM-Schutz-Flag, d.h. es setzt das AuthReq-Byte auf 0x02 anstelle von 0x03.
Allerdings erfordern die BLUR-Angriffe nicht, dieses Flag zu deaktivieren, sondern nur, NoInputNoOutput-Fähigkeiten zu deklarieren, wenn das entfernte Gerät Eingabe-/Ausgabefähigkeiten unterstützt. Durch diesen Trick wird die Pairing-Prozedur auf Just Works herabgestuft, ohne das MitM-Flag zu deaktivieren.
Die Umsetzung dieses Setups erfordert eine minimale Änderung des Linux-Kernels. Insbesondere in /net/bluetooth/hci_event.c ändern wir:
cp.authentication = conn->auth_type;
zu:
cp.authentication = 0x03;
Dadurch codieren wir unser AuthReq-Flag auf 0x03 fest, unabhängig von den von uns deklarierten Eingabe-/Ausgabefähigkeiten.
Pairing der Opfergeräte wie gewohnt. Wenn Sie beispielsweise ein Smartphone angreifen, paaren Sie es mit Ihrem Laptop (das sowohl als Opfer als auch als Angriffsgerät fungiert). Als Teil des Pairings kann eine Benutzerinteraktion erforderlich sein (z.B. Numerischer Vergleich).
REMOTE-BTADDhciconfig aus und notieren Sie sich Ihren hci-Index, z.B. 0sudo btmgmt -i 0 aus[hci0] # sehenHier gehe ich davon aus, dass das Opfer eine öffentliche BLE-Adresse verwendet. Wenn es eine zufällige verwendet, ändern Sie die Option -t auf 2
Führen Sie in der btmgmt-CLI aus:
pair -t 1 REMOTE-BTADD
Wenn Sie die Assoziation auch auf Just Works herabsetzen müssen, führen Sie aus:
pair -c 3 -t 1 REMOTE-BTADD
Das Flag -c setzt die Eingabe-/Ausgabefähigkeiten des Angreifers, und ein Wert von 0x3 entspricht NoInputNoOutput, während der Standardwert für ein Laptop/Smartphone 0x1 ist, was Display Yes/No entspricht.
In diesem Fall paaren wir uns selbst dann über BT als Central, wenn wir ein BLE-Peripheral imitieren.
Führen Sie in der btmgmt-CLI aus:
pair -t 0 REMOTE-BTADD
Wenn Sie die Assoziation auch auf Just Works herabsetzen müssen, führen Sie aus:
pair -c 3 -t 0 REMOTE-BTADD
Wiederholen Sie die oben beschriebenen Angriffe, während Sie ein Gerät imitieren, das dem Opfer derzeit unbekannt ist (d.h. nicht mit ihm gepaart ist).
In der bluetoothctl-CLI können Sie discoverable auf on oder off und pairable setzen. In der btmgmt-CLI können Sie auch das Flag connectable setzen.
In bluetoothctl können Sie den Zeitüberschreitungswert für die Erkennbarkeit mit discoverable-timeout steuern, z.B. wenn Sie es auf 0 setzen, ist das Gerät immer erkennbar.
Für BT: Während des Pairings mit einem entfernten Gerät – entweder als Central oder als Peripheral – erhalten Sie das folgende LMP-Paket: LMP not accepted ext (Opcode: 0x02) mit der Meldung 'Pairing not allowed' (Fehlercode: 0x18)
Für BLE: Während des Pairings mit einem entfernten Gerät – entweder als Central oder als Peripheral – erhalten Sie das folgende SMP-Paket: SMP Pairing Failed Command (Opcode 0x05) mit Pairing Not Supported (Grund 0x05).
Für BT: Überprüfen Sie während des Pairings mit einem entfernten Gerät die Secure Connections-Unterstützung für den Host und den Controller in den LMP-Feature-Paketen, z.B. mit dem folgenden Wireshark-Anzeigefilter: btbrlmp.efeat.scc or btbrlmp.efeat.sch.
Für BLE: Überprüfen Sie während des Pairings mit einem entfernten Gerät im SMP Pairing Request oder Response das AuthReq-Byte, das das Secure Connection-Flag enthält, z.B. mit dem folgenden Wireshark-Anzeigefilter: btsmp.sc_flag == 1.
Für BT: Während des Pairings mit einem entfernten Gerät wird der BLE-SMP-Verkehr über L2CAP getunnelt. Daher sollten Sie mit dem Wireshark-Filter btl2cap.payload ein Paket vom Central zum Peripheral sehen, dessen Nutzlast mit 0x01 beginnt (SMP Pairing Request), und ein weiteres Paket in die andere Richtung mit einer Nutzlast, die mit 0x02 beginnt (SMP Pairing Response). Außerdem sollten Sie weitere rohe L2CAP-Pakete sehen, die die SMP-Schlüsselverteilungsphase codieren.
Für BLE: Überprüfen Sie während des Pairings mit einem entfernten Gerät im SMP Pairing Request oder Response, ob sowohl der Central als auch der Peripheral bereit sind, während der SMP-Schlüsselverteilung einen Link-Key zu senden und zu empfangen, z.B. mit dem folgenden Wireshark-Filter btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.