Bluetooth Low Energy Hacking für Anfänger

Nachdem ich mich nun schon einige Zeit mit dem Thema Bluetooth Low Energy (BLE) Hacking beschäftige, kommt eine Frage immer wieder auf: Wie fange ich damit an?

Nun – man könnte sicherlich beginnen, die über 3000 Seiten lange Spezifikation (aktuell Version 5.3) zu lesen, welche durch die Bluetooth Special Interest Group veröffentlicht wird. Allerdings ist hier die gesamte Spezifikation sowohl für Bluetooth Classic als auch für jede einzelne Protokollschicht enthalten. Das ist äußerst umfangreich und daher selbst für erfahrene ITler ein eher unkonstruktives Vorgehen. Wie also dann? Einmal durch die Internet Blogs der letzten 10 Jahre wühlen?

Meiner Erfahrung nach empfiehlt es sich, direkt Hand anzulegen und sich die Sache Stück für Stück in der Praxis anzusehen. Dabei entwickeln sich spezifischere Fragen und Stichworte, mit denen man dann in die tiefere Recherche gehen kann.

Man kann zu Beginn einen Onlinehändler der Wahl aufsuchen und ein x-beliebiges BLE (Bluetooth Low Energy)-Gerät kaufen. Hierbei ist jedoch Vorsicht geboten. So habe ich genug Geräte gesehen, die schlichtweg auf Sicherheit verzichten und wo die „Hacking Experience“ dann ein eher trauriges, weil viel zu einfaches, Ende findet.

Für den Anfang sollte man sich mit den theoretischen Grundlagen von Bluetooth beschäftigen. Daher soll es hier zunächst einen Kurzüberblick über die Technologie geben:

Bluetooth Classic vs. Bluetooth Low Energy

Bluetooth ist nicht gleich Bluetooth. Zu Beginn des Protokolls gab es Bluetooth Classic. Mit Version 4.0 kam dann Bluetooth Low Energy auf den Markt. Die Protokolle sind sich sehr ähnlich, haben aber bei näherer Betrachtung durchaus ein paar Unterschiede. So verbraucht BLE, wie der Name schon andeutet, weniger Energie als Bluetooth Classic. Zusätzlich gibt es in den Protokollschichten Unterschiede: So sind die sicherheitsrelevanten Funktionen von BLE im Host und bei Bluetooth Classic im Controller implementiert.

Host Controller Interface

Beiden Protokollen gemein ist die Aufteilung der Protokollschichten in Host und Controller. Beide Komponenten sind durch das Host Controller Interface (HCI) verbunden. Die beiden Komponenten sind hardwareseitig getrennt. Am besten lässt sich das an einem Beispiel erklären. Denkt man an einen externen Bluetooth Dongle, ist das der Controller bzw. enthält der Dongle die Controller Protokollschichten. Die Hostschichten sind dann im Betriebssystem des Computers angesiedelt. Das HCI ist hierbei über USB umgesetzt.

Protokoll Stack

Bluetooth hat einen komplett eigenen Protokoll Stack. Da sich dieser Blogpost explizit mit BLE Hacking beschäftigt, werden wir im Folgenden nur die BLE Protokollschichten betrachten.

Es sind vor allem die folgenden Schichten interessant:

• Der Security Manager mit dem Security Manager Protokoll (SMP): Wie der Name verrät, ist das Protokoll für die Sicherheit zuständig. Über das SMP wird das Schlüsselmaterial für die Verschlüsselung sowie Authentifizierung über unterschiedliche Pairing Methoden ausgehandelt und verwaltet.
• Das Generic Attribute Profile (GATT) und das zugehörige Attribute Protocol (ATT): GATT definiert die Services, welche eine Anwendung zu Verfügung stellt, zum Beispiel den Puls, welcher mit einem Herzfrequenzmesser gemessen wird. Über das Attribut Protokoll kann auf diese zugegriffen werden. Dies ist in einer Client-Server Architektur umgesetzt. Dabei ist das Slave (auch Peripheral) Gerät der Verbindung der GATT Server und das Master (auch Central) Gerät der Client. Zur Master-Slave-Architektur gleich noch mehr.
• Der Link Layer (LL): Der Link Layer ist in dem Security-Kontext wichtig, da hier die finale Verschlüsselung stattfindet, bevor die Pakete über den physischen Link versendet werden. Dabei bezieht der LL den Verschlüsselungsschlüssel vom Security Manger über das HCI. Das bedeutet, dass die Kommunikation über das HCI unverschlüsselt ist.

Master-Slave-Architektur

Bluetooth Verbindungen enthalten immer genau ein Master Gerät und mindestens ein Slave Gerät. Das Master Gerät ist dabei meist ein Computer oder Smartphone. Slave Geräte sind dann all die „smarten“ BLE-fähigen Gadgets auf dem Markt.

Pairing Methoden

Besonders interessant sind die verschiedenen Pairing Methoden des SMP. Abhängig von den technischen Möglichkeiten der beteiligten Geräte stehen hier unterschiedliche Varianten zur Verfügung. Prinzipiell gibt es folgende Kategorien von Geräten:

• DisplayOnly: Das Gerät hat ein Display, auf dem ein PIN Code angezeigt werden kann
• KeyBoardOnly: Das Gerät hat ein Keyboard, auf welchem ein PIN eingegeben werden kann
• DisplayYesNo: Das Gerät hat die Möglichkeit, das Pairing mit Ja oder Nein über Buttons und ein Display zu bestätigen
• NoInputNoOutput: Das Gerät verfügt weder über eine Eingabe- noch eine Ausgabemöglichkeit

Das Pairing bei Bluetooth Low Energy wird weiter, versionsabhängig, in Legacy und dem Secure Connections Pairing unterschieden.

Version	Pairing
Legacy Pairing v4.0 & v4.1	JustWorks
	PassKey Entry
	Out-of-Band
Secure Connections v4.2+	Just Works
	Numeric Comparison
	PassKey Entry
	Out-of-Band

• JustWorks: Für Geräte ohne Ein- oder Ausgabemöglichkeit. Dieses Verfahren besitzt keinen MitM Schutz und ist daher per Spezifikation angreifbar
• NumericComparison: Beide Geräte benötigen ein Display, auf dem ein PIN angezeigt werden kann, sowie eine Möglichkeit, diesen zu bestätigen. Nur im Secure Connections Pairing verfügbar.
• PassKey Entry: Ein Gerät benötigt ein Keyboard, das andere ein Display. Hier wird auf dem Gerät mit Display ein PIN angezeigt, welcher auf dem anderen Gerät eingegeben werden muss.
• Out-Of-Band: Das Pairing findet auf anderem Wege als BLE statt, zum Beispiel NFC.

Testgerät(e) kaufen

Bei der Wahl eines entsprechenden Testgeräts sind ein paar Dinge zu beachten. Mit viel Glück kann sowohl die Version des Protokolls, egal ob Bluetooth Classic oder Low Energy, als auch die Versionsnummer den technischen Details entnommen werden. Leider sind Informationen über den implementierten Pairing Algorithmus meist Mangelware. Hier kann man nur anhand der verfügbaren Ein- und Ausgabemöglichkeiten des Produkts vermuten, was verwendet wird. Klar ist, ein Gerät ohne Display oder Keyboard wird sicher auf JustWorks zurückgreifen. Geräte, welche für Audioanwendungen, Kopfhörer, Freisprechanlagen etc. verwendet werden, verfügen meist über Bluetooth Classic. Zwar gibt es inzwischen auch le-audio, erfahrungsgemäß dauert es aber ein wenig, bis die Hersteller die neue Technologie adaptieren.

Auch ein Ansatz kann sein, die zugehörige App zu analysieren, wenngleich das zu Beginn aufgrund der Komplexität keine anfängerfreundliche Variante ist.

Erste passive Analyse

Abhängig davon, ob das Gerät mit dem Smartphone oder dem Computer verbunden werden kann, gibt es unterschiedliche Tools, mit denen die Verbindung initiiert wird. Für Android Geräte gibt es generell die nRF Connect App, welche umfangreiche Funktionen zur Analyse von BLE-fähigen Geräten bietet. Für den Anfang empfehlenswerter ist die zugehörige App des BLE-fähigen Geräts, falls vorhanden. Für Linux Systeme bietet sich das Tool bluetoothctl an. Dieses bietet ein breites Funktionsspektrum, um Verbindungen zu initiieren. Alternativ kann die graphische Benutzeroberfläche für das Initiieren der Verbindung verwendet werden. Hier ist das Ziel, die Kommunikation zwischen Computer und BLE Gerät mitzuschneiden und zu analysieren.

Die passive Analyse des Packet Logs bei regulärer Nutzung ist die Basis für jede Analyse. Ganz ohne irgendwelche Spezialhardware kann die Kommunikation des HCI, während der Nutzung des Geräts, mitgelesen werden. Diese ist wie oben bereits erwähnt unverschlüsselt und ermöglicht eine ausführliche Analyse der Kommunikation beider Geräte. Im Folgenden soll das Vorgehen zur Extraktion des Paket Logs für Linux sowie Android beschrieben werden.

Android

Für den Überblick über die Kommunikation sind die ausgetauschten Bluetooth Datenpakete interessant. Diese können in Android mit dem HCI Snooplog Feature der Android Entwickler Tools bezogen werden. Die Funktion aktiviert das Loggen von Bluetooth Paketen und ermöglicht, dieses Log später von dem Gerät zu extrahieren und in Wireshark zu betrachten.

Zunächst muss also das HCI Snooplog Feature aktiviert werden. Dafür geht man in die Entwickleroptionen des Geräts und aktiviert dort die Funktion. Bei manchen Geräten ist es notwendig, Bluetooth danach aus- und wieder einzuschalten, damit der Log erstellt wird.

Sind die Entwicklerfunktionen nicht aktiviert, kann man dies durch 7-faches Drücken der Buildnummer in den Systeminfos des Android Gerät finden.
Ohne Root Rechte kann meist nicht auf das Log File zugegriffen werden. Allerdings kann dieses mittels adb extrahiert werden. Mit dem Befehl adb bugreport erstellt adb einen ausführlichen Fehlerbericht des Geräts, in welchem auch das Bluetooth HCI Protokoll enthalten ist. Der Pfad kann wieder für unterschiedliche Geräte variieren, der Name ist aber immer btsnoop_hci.log

Als Ergebnis erhält man ein ZIP-Archiv. Nach Extraktion kann auf die Log Datei zugegriffen werden.

Dieser kann dann in Wireshark betrachtet werden.

Linux

In Linux ist das Mitschneiden der Bluetooth Kommunikation noch einfacher. Hier kann der Bluetooth Monitor genutzt werden, um die Pakete des HCI mitzulesen. Zunächst können verfügbare Bluetooth Adapter mittels dem Tool hciconfig ermittelt werden. Im folgenden Fall stehen drei Adapter zu Verfügung. Adressiert werden diese über den Interfacenamen, also im konkreten Fall hci0, hci1 und hci2.

Mittels btml -i kann das Interface abgehört werden. Das Flag -w erlaubt zusätzlich, den Log in einer Datei zu speichern.

Auch dieses Log kann direkt in Wireshark analysiert werden.

Noch ein paar Tipps für die erste Analyse

Wireshark unterstützt das Filtern der einzelnen Bluetooth Protokollschichten. So kann zum Beispiel mit dem Filter btsmp das Pairing analysiert werden. Um zu verstehen, was hier vor sich geht, bieten die Sequenz Diagramme in der Bluetooth Spezifikation (v5.3) im Appendix C Message Sequence Charts (Seite 1625) einen guten Überblick, hier ist man auch gleich im richtigen Kapitel, falls weitere Fragen aufkommen.

Die eigentliche Kommunikation der Anwendung kann durch Betrachten des Attribut Protokolls nachvollzogen werden. Der Filter hierfür lautet btatt.

Zusammenfassung

In dem Blog haben wir zunächst die Basics des Bluetooth Low Energy Protokolls betrachtet, welche für den Start des BLE Hackings notwendig sind. Weiter haben wir Anforderungen an mögliche Testgeräte erläutert und final praktisch gezeigt, wie man ohne zusätzliche Hardware die Verbindung des Testgeräts analysieren kann und somit hoffentlich dem ein oder anderen den Start in die Thematik erleichtert. In einem weiteren Blogpost werden wir dann erste, konkrete Schwachstellen und Angriffsmöglichkeiten betrachten.

Nachtrag von Dezember 2022: Bluetooth Low Energy in der Praxis

Nach dem ersten Teil, der sich vorwiegend mit den ersten Schritten und passiver Analyse beschäftigt, freue ich mich nun im zweiten Teil, aktivere Angriffe vorstellen zu können. Hier konnte ich eine ganze Menge an Angriffsmodulen sowie Szenarien in dem Mirage Framework implementieren.

Wer einen meiner Vorträge zum Hacken und der Exploit Entwicklung gesehen hat, kennt bereits den ein oder anderen Angriff. Ich wurde dabei oft gefragt, ob es den Code auch online zu finden gibt und musste bisher immer mit der Antwort „Es ist in Arbeit“ verneinen. Aber zum Abschluss des Jahres bin ich nun endlich dazu gekommen, den Code hier veröffentlichen zu können!

Hier findet sich auch gleich eine Beschreibung, wie die einzelnen Module oder Szenarien aufgerufen werden können. Von dem her, schöne Feiertage und happy Hacking!