Proof of Concept der Sweyntooth Bluetooth Low Energy (BLE) Schwachstellen.
Dieses Repository ist Teil eines Forschungsergebnisses der ASSET Research Group.
SweynTooth erfasst eine Familie von 18 Schwachstellen in verschiedenen Bluetooth-Low-Energy-Softwareentwicklungskits (SDKs) von sechs großen System-on-a-Chip-Herstellern (SoC). Die Schwachstellen legen Fehler in bestimmten BLE-SoC-Implementierungen offen, die es einem Angreifer in Funkreichweite ermöglichen, je nach den Umständen Deadlocks, Abstürze und Pufferüberläufe auszulösen oder die Sicherheit vollständig zu umgehen. (Update) Wir haben außerdem ein Testskript hinzugefügt, um Geräte gegen die BLE-KNOB-Variante zu prüfen.
Weitere Informationen zu den Schwachstellen, verfügbaren Patches und betroffenen Geräten findest du auf der ASSET Research Group SweynTooth-Offenlegungswebsite.
Fitbit, August Smart Lock, Eve Energy, CubiTag und andere "Smart"-Geräte sind betroffen.
Dieser PoC verwendet gut gepflegte Bibliotheken wie Scapy und Colorama. Das Erstellen und Analysieren von BLE-Paketen erfolgt über angepasste Scapy-Protokollschichten (bluetooth4LE und bluetooth.py). Es gibt einen laufenden Merge, um unsere Ergänzungen in das Haupt-Repository von Scapy aufzunehmen.
Zunächst musst du sicherstellen, dass Python2.7 auf deinem System installiert ist und die in der Datei requirements.txt aufgeführten Python-Pakete vorhanden sind.
Wenn du Ubuntu verwendest, führe Folgendes aus:
sudo apt-get install python2.7
sudo pip install -r requirements.txt
Zweitens verwendet SweynTooth den Nordic nRF52840-Dongle, um rohe Link-Layer-Pakete über die Luft an das verwundbare Peripheriegerät zu senden und von ihm zu empfangen. Es ist notwendig, die Treiber-Firmware auf das Board zu flashen, bevor du die Python-2.7-Skripte startest.
Das Binärprogramm unseres Firmware-Codes befindet sich in der Datei nRF52_driver_firmware.zip. Du musst das Tool nrfutil installieren, um die Firmware auf das Board zu flashen. Denke daran, den nRF52840 vor dem Flashen in den DFU-Modus zu versetzen (setze den USB-Dongle zurück, während er mit deinem PC verbunden ist, indem du den kleinen Reset-Knopf drückst).
Du kannst die folgenden Befehle ausführen, um die Python-Abhängigkeiten zu installieren und die Firmware zu flashen:
python -m pip install nrfutil pyserial pycryptodome
nrfutil dfu usb-serial -p COM_PORT -pkg nRF52_driver_firmware.zip
Die Skripte funktionieren unter Linux oder Windows. Du musst lediglich den Parameter COM_PORT so ändern, dass er dem Portnamen des nRF52840 entspricht.
Falls die vorherige Flash-Methode nicht funktioniert hat, kannst du die Firmware auch mit der nRF Connect App for Desktop flashen, die eine benutzerfreundliche Oberfläche zum Flashen der Hex-Firmware (nRF52_driver_firmware.hex) bietet.
Nachdem die Anforderungen installiert sind, kannst du ein Exploit-Skript mit dem folgenden Befehl ausführen:
python Telink_key_size_overflow.py COM7 A4:C1:38:D8:AD:A9
Das erste Argument ist der Name der seriellen Schnittstelle (normalerweise /dev/ttyACM0 unter Linux) und das zweite die Adresse des verwundbaren BLE-Geräts. Du kannst jeden BLE-Scanner oder die nRF-Connect-App verwenden, um eine solche Adresse zu ermitteln.
Am Beispiel der Key-Size-Overflow-Schwachstelle gibt das Skript die folgende Ausgabe aus, wenn das verwundbare Gerät nach dem Absturz hängt:
Wenn du SweynTooth über ein Docker-Image verwenden möchtest, um die Installation von Python-Abhängigkeiten zu vermeiden, kannst du das Hilfsskript docker.sh verwenden, um die Docker-Instanz zu erstellen und auszuführen, oder das vorgefertigte Docker-Image (Link) herunterladen, das auf der Release-Seite verfügbar ist. Die Verwendung von docker.sh wird unten beschrieben.
--------- HELP -------------
sudo ./docker run <script_name> <serial_port> <ble_target_address> - Start any sweyntooth script by its name (<script_name>)
sudo ./docker build - Build docker container
sudo ./docker build release - Build docker container and create compressed image for release
sudo ./docker shell - Start docker container shell
---------- EXAMPLE ----------
./docker.sh run extras/Microchip_and_others_non_compliant_connection.py /dev/ttyACM0 f0:f8:f2:da:09:63
Jedes Exploit-Skript entspricht einer Schwachstelle. Die folgende Übersichtstabelle zeigt die Zuordnung zwischen der Schwachstelle und einem Skript, mit dem die Schwachstelle auf den betroffenen SoCs ausgenutzt wird.
Im Allgemeinen verwenden Produkte mit den betroffenen SoCs einen Watchdog, der den BLE-SoC bei einem Fehler automatisch neu startet. Daher können nicht alle Produkte in einen Deadlock versetzt werden. Dennoch sollte es möglich sein, eine visuelle oder akustische Anzeige vom Produkt zu erhalten, wenn es abstürzt und neu startet.
Die kritischste SweynTooth-Schwachstelle ist die Zero-LTK-Installation, die es einem Angreifer ermöglicht, das neueste Bluetooth-Pairing-Verfahren (sichere Verbindungen) vollständig zu umgehen, indem er einen Verschlüsselungs-Setup-Vorgang mit einem mit Nullen gefüllten LTK erzwingt. Um dein Gerät gegen diese Schwachstelle zu testen, muss das Gerät sichere Verbindungen als Pairing-Methode akzeptieren oder unterstützen. Du kannst den PoC wie folgt ausführen:
python Telink_zero_ltk_installation.py COM7 A4:C1:38:D8:AD:A9
Beachte, dass die Argumente COM7 und A4:C1:38:D8:AD:A9 je nach deinem Setup unterschiedlich sind. Wenn das Gerät verwundbar ist, gibt der PoC Folgendes aus:
Das LLID-Deadlock-Skript leert das LLID-Feld, wenn bei jeder erneuten Verbindung mit dem Peripheriegerät abwechselnd Versionsanfragen oder Pairing-Anfragen gesendet werden. Dies dient dazu, die Schwachstelle in den verwundbaren SoCs von NXP und Cypress auszulösen. Wenn das Skript gegen das verwundbare KW41Z ausgeführt wird, gerät der Stack in einen Deadlock und sollte Link-Layer-Pakete in falscher Reihenfolge senden. Das Skript versucht zu erkennen, wann der Stack blockiert ist, und gibt für verwundbare KW41Z-Geräte Folgendes aus:
Verwundbare Cypress-Geräte deaktivieren nach dem Angriff in der Regel ihre Advertising-Pakete. Daher solltest du eine Fehlermeldung sehen, die einen erkannten Absturz anzeigt. Wenn dieses Skript gegen eine verwundbare Fitbit Inspire getestet wird, stürzt die Smartwatch entweder sofort ab oder deaktiviert vorübergehend ihre Advertising-Pakete. Intermittierende Angriffe gegen dieses Gerät sollten zu einer dauerhaften BLE-Fehlfunktion führen, sodass der Benutzer die Fitbit Inspire manuell neu starten muss.
Während KNOB hauptsächlich Bluetooth-Classic-Geräte betraf, da die Schlüssellänge auf 1 Byte reduziert werden konnte, ist es immer noch möglich, die Schlüsselentropie von Bluetooth-Low-Energy-Geräten während des SMP-Pairing-Vorgangs auf 7 Byte (die minimale konforme Schlüssellänge) zu reduzieren. Die Auswirkungen einer solchen konformen BLE-Entropieverringerung wurden in "Low Entropy Key Negotiation Attacks on Bluetooth and Bluetooth Low Energy" von Antonioli, Daniele et al. diskutiert.
Wir haben ein einfaches Skript bereitgestellt, um zu prüfen, welche Schlüssellängen von einem BLE-Peripheriegerät akzeptiert werden. Du kannst den BLE-KNOB-Tester wie folgt ausführen:
# Windows
python extras\knob_tester_ble.py COM6 a4:c1:38:d8:ad:a9
# Linux
python extras/knob_tester_ble.py /dev/ttyACM0 a4:c1:38:d8:ad:a9
Vergiss nicht, COM6 und a4:c1:38:d8:ad:a9 gemäß der seriellen Schnittstelle des nRF52-Dongles (normalerweise /dev/ttyACM0 unter Linux) und der Adresse des zu testenden BLE-Geräts zu ändern. Wenn das Tool erkennt, dass das Peripheriegerät andere Schlüssellängen als 16 Byte akzeptiert, listet es diese wie unten gezeigt auf:
Der Ordner captures enthält einige Beispiel-Mitschnitte für jede Schwachstelle. Wir haben außerdem einige Non-Compliance-Fälle hinzugefügt, die in einigen SoCs erkannt wurden.
Der Ordner extras enthält einige zusätzliche Skripte zu Non-Compliance-Fällen und einigen SweynTooth-Varianten. Weitere Informationen findest du in der Tabelle der Extras-Skripte in extras/README.md.
Diese Forschung wurde teilweise von Keysight Technologies unterstützt.
| Schwachstelle | CVE(s) | Hersteller | Skriptdatei |
|---|