
Ein Writeup und ein theoretischer Proof-of-Concept für CVE-2019-19194
Dies ist ein Writeup und ein theoretischer Proof-of-Concept der CVE-2019-19194.
⚠️ Diese CVE wurde gefunden von https://asset-group.github.io/disclosures/sweyntooth/
Dieser Bericht beschreibt, wie die Zero LTK Initialisation-Schwachstelle (CVE-2019-19194) es einem Angreifer ermöglicht, die volle Kommunikationskontrolle über eine Bluetooth Low Energy (BLE)-Anwendung zu erlangen, indem das Secure Connections-Pairing-Verfahren umgangen wird.
Diese Schwachstelle betrifft Produkte, die Telink-SMP-Implementierungen verwenden, die das Secure Connections-Pairing-Verfahren unterstützen.
BLE ist ein stromsparendes, kurzreichweitiges Funkkommunikationssystem. Es besteht aus einem Satz standardisierter Protokolle, die eine Fernverbindung und Sicherheit zwischen zwei Geräten bieten.
Der BLE-Stack ist auf zwei Architekturblöcke verteilt: Host und Controller.
Die Verteilung des Stacks ermöglicht die Implementierung jedes Blocks in physisch getrennten Komponenten.
Eine standardisierte logische Schnittstelle namens Host Controller Interface (HCI) ermöglicht die Kommunikation zwischen den beiden Blöcken.
Über dem Host-Block befindet sich die BLE-Anwendung.

Die Bitübertragungsschicht arbeitet im Industrial, Scientific and Medical (ISM)-Funkband im 2,4-GHz-Spektrum. Sie verwendet 40 Kanäle: 3 Advertising-Kanäle und 37 Daten-Kanäle.
Die Sicherungsschicht (LL) hat viele Aufgaben, die hier nicht beschrieben werden. Sie wird durch eine Zustandsmaschine gesteuert, die wichtige Rollen und Zustände definiert:
Das Logical Link Control and Adaptation Protocol fungiert als Protokollmultiplexing-Schicht. Es behandelt Fragmentierung und Rekombination von Paketen zwischen den darunter- und darüberliegenden Schichten.
Das Generic Access Profile betrifft die Geräteentdeckung und Verbindung. Mit anderen Worten: GAP definiert Verfahren für das Senden von Werbepaketen und deren Empfang durch Scannen.
Sobald eine Verbindung zwischen zwei BLE-Geräten hergestellt wurde, verwendet GATT ein Client/Server-Modell zum Datenaustausch zwischen den beiden Geräten. Und sowohl Client als auch Server verwenden das Attribute Protocol (ATT).
Der SM unterstützt sicherheitsrelevante Verfahren wie Pairing, Bonding und Schlüsselverteilung. Das Pairing von Geräten gilt als Grundlage der Bluetooth-Sicherheit: Nach dem Pairing können die beiden Geräte ihre Kommunikation verschlüsseln, sich gegenseitig authentifizieren, ...
Unter den verschiedenen an der BLE-Kommunikation beteiligten Protokollen tritt die Zero LTK Installation-CVE während des Pairing-Verfahrens im Secure Connections-Modus auf.

Der Secure Connections-Pairing-Modus ist der "sicherere Ansatz" und wurde entwickelt, um die Schwächen des Legacy-Modus zu beheben. Allerdings hat die Zero LTK Installation-CVE gezeigt, dass schlechte Implementierungen des SC-Pairings es ermöglichen, die Sicherheit zu umgehen.

Das zentrale Gerät sendet eine Pairing-Anfrage und beide Geräte tauschen ihre Sicherheitsfähigkeiten und -anforderungen aus. Diese Phase definiert den Pairing-Modus.
Öffentlicher Schlüsselaustausch: Ein Austausch öffentlicher Schlüssel wird vom zentralen Gerät initiiert. Sowohl Peripherie als auch Zentrale überprüfen, ob der empfangene Schlüssel auf der P-256-Kurve liegt.
Berechnung des DHKey: Jedes Gerät verwendet seinen eigenen privaten Schlüssel (SK) und den öffentlichen Schlüssel des anderen Geräts (PK), um seinen Diffie-Hellman-Schlüssel (DHKey) zu berechnen. Auf diese Weise besitzen beide Geräte denselben DHKey-Wert.
Central: DHKey = p256(SKc, PKp)
Peripheral: DHKey = p256(SKp, PKc)
Falls MITM-Schutz angefordert wurde, findet ein interaktives Verfahren statt, um die Authentizität der Pairing-Geräte zu bestätigen.
Berechnung des Long Term Key (LTK) und gegenseitige Bestätigung: Die Geräte authentifizieren sich gegenseitig und berechnen einen LTK-Schlüssel. Aus dem LTK wird ein Sitzungsschlüssel abgeleitet, um die Verbindung vor Phase 3 zu verschlüsseln.
Über die verschlüsselte Verbindung können die Geräte Schlüssel verteilen.
Die Grundursache der Zero LTK Installation ist, dass der Zustand, in dem sich die beiden Geräte während des Pairing-Verfahrens befinden, nicht überprüft wird. Dadurch kann ein angreifendes zentrales Gerät den Schritt der Schlüsselerzeugung und Authentifizierung überspringen. Dies führt dazu, dass ein LTK-Schlüssel im Peripheriegerät auf 0 gesetzt wird, und somit zu einem leicht ableitbaren Sitzungsschlüssel.

⚠️ Dies ist ein vollständig theoretischer Proof-of-Concept, da ich keinen Mitschritt (pcap) von BLE-Erkennung, Werbung oder Pairing-Verfahren erhalten konnte und auch kein BLE-Gerät mit Telink-SMP-Implementierung besaß.