Cybersicherheitsrisiko in Bluetooth Low Energy (BLE) Geräten

Autoren: Ramakrishnan Lakshminaryanan und Jasper Nota

Geräte mit Bluetooth Low Energy (BLE) Konnektivität sind heutzutage weit verbreitet. Ihre Verwendung kann jedoch unsicher sein. Dies ist der Fall, wenn BLE auf unsichere Weise implementiert wird. Um das Cybersecurity-Risiko solcher Geräte zu demonstrieren, haben wir ein medizinisches Gerät gewählt, das von Verbrauchern bei mehreren bekannten Online-Shops bestellt werden kann.

Hinweis: Vor der Veröffentlichung dieses Artikels wurden mehrere Versuche unternommen, den Original Equipment Manufacturer (OEM) über die entdeckten Sicherheitslücken und ihre Folgen zu informieren. Leider hat der OEM nicht geantwortet. Secura hat sich entschlossen, diesen Artikel zu veröffentlichen, um das Sicherheitsbewusstsein von Herstellern und Benutzern zu erhöhen.

Mehrere Sicherheitsprobleme

Während der kurzen Untersuchung wurden mehrere Sicherheitsprobleme festgestellt. Für die Zwecke dieses Artikels werden nur die Risiken im Zusammenhang mit der BLE-Funktionalität aufgezeigt.

Das medizinische Gerät

Das Testable Device (DUT) ist ein medizinisch zertifiziertes Gerät, mit dem Benutzer über Elektroden Schmerzen lindern, Muskeln entspannen oder stärken können. Dieses Gerät kann mit der entsprechenden Android-Anwendung (v4.3.15 zum Zeitpunkt des Tests dieses Geräts) bedient werden.

Die gesamte Funktionalität hängt von der durch das zentrale oder periphere Gerät eingestellten Intensität ab. Je nach Intensitätswert [min = 0; max = 60] ist die Vibration über die Elektrodenpflaster am Körper zu spüren. Je nachdem, auf welchen Teil unseres Körpers die Elektrodenpflaster geklebt werden, gibt es eine Reihe von Trainings-, Entspannungs- bzw. Erholungsprogrammen.

Die Tests begannen mit dem Aufkleben der Pflaster auf die Arme oder Beine. Die Beobachtung (während des Tests am Arm) war, dass der Arm nach Überschreiten des Intensitätswertes von 25 anfing, heftig zu vibrieren. Die Intensität kontrollierte die Armbewegung, so dass es schwierig war, dieser Bewegung zu widerstehen. Diese Vibrationen konnten bei höheren Intensitäten oder bei plötzlichen Änderungen der Intensität zu schweren Schocks werden.

Dienste und Funktionen

Es wurde eine BLE-Erkennung gestartet, um die mit dem Testobjekt verbundene MAC-Adresse (Media Access Control) zu ermitteln. Nach der Identifizierung konnten die Dienste und Funktionen aufgezählt werden, bei denen es sich um verschachtelte Objekte handelt, die für die Verarbeitung der übertragenen Daten zuständig sind:

Beachten Sie, dass mehrere Handles die Eigenschaft WRITE für das DUT haben. Das bedeutet, dass diese Handles eingehende Daten von dem zentralen Gerät, in diesem Fall dem Mobiltelefon, akzeptieren.

Unter den Handles mit Schreibzugriff gab es mehrere interessante, die im Folgenden aufgeführt sind:

(1) Handle 0007 - Peripherie-Datenschutz-Flag

Dieses Flag bezieht sich ausdrücklich auf die Datenschutzfunktion des Peripheriegeräts. Mit anderen Worten, es ist das Flag, das bestimmt, ob das Peripheriegerät Datenschutz unterstützt - aktiviert oder deaktiviert. Für einen Angreifer wäre es interessant zu testen, ob dieses Handle überschrieben/umgeschaltet werden kann.

(2) Handle 000b - Wiederverbindungsadresse

Dieses Handle enthält adressbezogene Informationen, die bei der erneuten Verbindung mit einem privaten Gerät verwendet werden. Da dieses Handle auch aus der Sicht eines Angreifers von Interesse ist, wollten wir überprüfen, ob es überschrieben werden kann.

(3) Handles 0010, 0011, 0012, 0013 - Bezogen auf die Vibrationsintensität

Diese Handles enthalten Werte für die Vibrationsintensität und wären für einen Angreifer ebenfalls interessant, um sie zu überschreiben.

Wie in der obigen Abbildung zu sehen ist, wurde das Peripheral Privacy Flag [Handle 0007] überschrieben. Daraus lässt sich schließen, dass es deaktiviert und aktiviert werden kann. In ähnlicher Weise konnte auch das Feld 'Reconnection Address [Handle 000b]' überschrieben werden, wie in der Abbildung unten zu sehen ist. Abbildungen zum Überschreiben der Werte für die Vibrationsintensität finden Sie im nächsten Abschnitt dieses Artikels.

Es gibt mehrere Methoden, um den BLE-Datenverkehr zwischen Geräten zu analysieren, und zwar mit verschiedenen Hardware- und Software-Tools.

Eine der ersten, die wir in Betracht gezogen haben, war die passive Erfassung des BLE-Verkehrs mit dem Ubertooth One und die anschließende Analyse der Pakete mit Wireshark. Unten sehen Sie einen Screenshot, der die Paketerfassung mit Wireshark zeigt. Es konnten Informationen über den Wert der Vibrationsintensität, die Art des verwendeten Protokolls und Informationen über die Handles untersucht werden:

Der Screenshot oben zeigt, dass die erfassten Pakete das ATT-Protokoll verwenden. ATT, auch bekannt als Attribute Protocol, ist Teil des BLE-Stacks und definiert genau, wie Daten in einer BLE-Server-Datenbank dargestellt werden sollen und wie sie gelesen oder geschrieben werden können.

Ein weiterer Ansatz zur Analyse der BLE-Kommunikation ist die Verwendung der HCI-Sniffing-Technik auf einem gerooteten Android-Mobiltelefon. Grundsätzlich ist ein gerootetes Android-Gerät ein modifiziertes Gerät, das dem Benutzer Superuser-Zugriff gewährt. Beim Rooten eines Geräts durchbricht der Benutzer eine Reihe von Beschränkungen, die vom Gerätehersteller festgelegt wurden, um die volle Kontrolle über das Betriebssystem zu erlangen. Auf diese Weise erlangt er Administrator-Rechte. Sobald die BLE-Kopplung/Kommunikation hergestellt ist, können Sniffer-Protokolle von dem gerooteten Gerät extrahiert werden, um die erfassten Pakete zu analysieren.

Bei den oben genannten Methoden handelte es sich hauptsächlich um passive Sniffing-Techniken der BLE-Kommunikation, um Informationen über den Kopplungsprozess, die Art der verwendeten Protokolle, die MAC-Adresse des Testobjekts, verschiedene Handles usw. zu sammeln.

Um aktiv mit den verschiedenen Handles in Kontakt zu treten, wurde das Bettercap-Tool in Kombination mit einem Bluetooth-Dongle verwendet. Die Ergebnisse dieses Ansatzes werden weiter oben in diesem Artikel vorgestellt.

Abfangen der Kommunikation

Nachdem die Kommunikation zwischen dem zentralen und dem peripheren Gerät analysiert worden war, wurde versucht, eine Man-in-the-Middle (MiTM) Position einzunehmen.

Der Screenshot unten zeigt, wie eine legitime BLE-Verbindung zwischen dem mobilen Gerät und dem DUT erfolgreich abgefangen wurde. Das bedeutet, dass das zentrale Gerät jetzt der Angreifer ist und nicht mehr das Mobiltelefon:

Wenn die BLE-Abfrage läuft, gibt es auf dem Handy-Bildschirm und auf der Vorderseite des Prüflings Hinweise darauf, dass ein ungeregeltes Verhalten stattfindet.

Anzeige 1: Der Prüfling ist eingeschaltet; in der Android-Anwendung ist kein Trainingsprogramm aktiv. Normalerweise sollte sich der Prüfling nach einigen Sekunden ausschalten, wenn ein Benutzer das Training verlässt (Normales Verhalten). Daher ist es unmöglich, dass das Gerät im eingeschalteten Zustand ist, wenn die Anwendung kein Programm ausführt, es sei denn, es wird durch eine aktive BLE-Verbindung von einem anderen zentralen Gerät eingeschaltet gehalten. Dies zeigt, dass die Android-Anwendung nicht mehr die Kontrolle über das Gerät hat, sondern dass der Angreifer nun die Kontrolle über das Gerät hat.

Hinweis 2: Der Prüfling ist aktiviert; die Android-Anwendung versucht, sich erneut mit dem Prüfling zu verbinden, was jedoch mit der Meldung scheitert, dass der Benutzer den Prüfling einschalten soll. Der Prüfling ist jedoch bereits aktiviert und der Angreifer führt gerade ein aktives Trainingsprogramm aus.

Die obigen Aufforderungen deuten also darauf hin, dass der Angreifer eine MiTM-Position einnimmt.

Sobald eine MiTM-Position eingerichtet war, konnte die Kommunikation zwischen dem Mobiltelefon und dem DUT im HEX-Format beobachtet werden.

Es wurde festgestellt, dass es für denselben Wert der Vibrationsintensität zwei Datenformate von HEX-Daten in den aufgezeichneten BLE-Paketen gab:

1. Daten vom Peripheriegerät an das zentrale Gerät -> Datenformat 1 oder DF1.
2. Daten vom Zentralgerät an das Peripheriegerät -> Datenformat 2 oder DF2.

Betrachten wir zum Beispiel den Wert der Vibrationsintensität 31.
Für denselben Wert wurden bei den Tests zwei verschiedene Datenformate beobachtet.

DF1 für den Wert 31 wurde wie unten dargestellt aufgezeichnet:
LL Daten: 06 1b 17 00 04 00 1b 12 00 4e 4f 54 49 46 59 20 73 74 72 65 6e 67 74 68 20 33 31 0d 0a

DF2 für den Wert 31 wurde wie unten gezeigt aufgezeichnet:
LL Daten: 02 10 0c 00 04 00 52 55 00 3e 73 74 72 20 33 31 0d 0a
LL Daten: 0a 0f 0b 00 04 00 1b 55 00 73 74 72 3d 33 31 0d 0a

Beide Formate zeigen an, dass die Stärke oder Intensität der Vibration auf den Elektrodenfeldern 31 sein sollte.

Die Erfolgsquote war bei DF2 höher, wenn man versuchte, das Handle mit dem Wert der Vibrationsstärke zu überschreiben. Das macht Sinn, da das Gerät des Angreifers nach dem Abfangen der BLE-Verbindung das neue zentrale Gerät ist, so dass DF2 in diesem Fall funktionieren würde. Es gab jedoch einige interessante Szenarien, die auf dem obigen Ansatz basierten -

1. Das Überschreiben des Griffs 0x12 mit einem niedrigeren Wert funktionierte, wenn die Intensität oder Stärke höher war, denn es gab eine spürbare Veränderung der Vibrationsintensität, die an dem Körperteil zu spüren war, an dem die Elektrodenpflaster angebracht waren [Hand/Bein]. Nach einer gewissen Zeit kehrte die Intensität jedoch wieder auf den ursprünglichen Wert zurück.
   
2. Bei einem niedrigeren Intensitäts- oder Stärkewert und dem Überschreiben des Griffs 0x12 mit einem höheren Wert funktionierte es zwar auch, aber es dauerte nur eine sehr kurze Zeit, bis der ursprüngliche Wert wieder erreicht war. Dies war auch der Fall, wenn der Unterschied/Delta zwischen dem ursprünglichen Wert und dem überschriebenen Wert gering war.
3. Wenn Sie einen niedrigeren Intensitäts- oder Stärkewert hatten und den Griff 0x12 mit einem höheren Wert mit einer großen Delta-Differenz zur ursprünglichen Intensität überschrieben, gab es keinen sichtbaren Unterschied in der Vibration am Körper. Ein lauter Gedanke ist, dass dies an einem bestimmten Delta-Schwellenwert liegen könnte, der im DUT eingestellt ist. Auf diesen Teil des Experiments sind wir nicht eingegangen, da wir uns auf das Abfangen der BLE-Kommunikation konzentriert haben.

Die folgenden HEX-Daten wurden an das Gerät gesendet:

Nachdem der Handle 0x12 überschrieben wurde, war die Änderung der Vibrationsintensität an dem Körperteil zu spüren, an dem die Elektroden angebracht waren. Dies zeigt, dass ein Angreifer die volle Kontrolle über die für die Elektroden eingestellte Intensität hat.

Schlussfolgerung

Wir haben gezeigt, wie ein Angreifer die BLE-Kommunikation missbrauchen kann, wenn die Hersteller BLE auf unsichere Weise implementieren. Dies kann dem Endbenutzer ernsthaften Schaden zufügen. Viele andere intelligente Geräte in der Branche haben immer noch eine unsichere Implementierung von Bluetooth Low Energy (BLE). Sind Sie in der Branche der BLE-basierten intelligenten Geräte tätig? Wir raten Ihnen dringend, Ihre Produkte sowohl unter funktionalen als auch unter Sicherheitsaspekten zu bewerten.