Fahrzeug-Hacks gehören derzeit zu den vieldiskutieren Security-Themen. In unserem Blog-Beitrag schauen wir uns ein bestimmtes IoT-Gerät im Automotive-Bereich genauer an und analysieren es in punkto Sicherheit. Mit dem PACE Kit erwirbt man einen Spritspartrainer, ein elektronisches Fahrtenbuch, einen Tankstellenfinder und viele weitere Funktionen. Angeschlossen wird das kleine Gerät einfach an die Diagnoseschnittstelle Ihres Wagens, den OBD Port, und sammelt dann eine Reihe unterschiedlicher Daten, z.B. zu Ihrem Fahrstil und zur Performance des Autos, deren Verarbeitung und Darstellung über Ihr Smartphone läuft. In seinem Sammeleifer erfasst das Gerät eine ganze Menge potentiell sensibler Daten und gibt uns damit Grund genug, die Sicherheit des PACE Kits zu überprüfen.

Reverse Engineering der App möglich

Wie auch bei allen anderen bisher getesteten Produkten steht und fällt das Sicherheitsniveau im Wesentlichen mit der Sicherheit der dazugehörigen App, und das PACE Kit ist keine Ausnahme von dieser Regel.

Im vorliegenden Fall kann man die App (getestete Version: 1.0.1) allerdings als ziemlich ungesichert bezeichnen, da auf Quellcode-Ebene keinerlei Schutzvorrichtung zu finden ist. Der folgende Screenshot zeigt einen Ausschnitt aus dem Klassendiagram und es ist klar zu erkennen, dass aufgrund der unverschleierten Anzeige aller Klassen und Funktionsnamen keine Obfuskation eingesetzt wurde. Folglich kann der gesamte Quellcode durch Reverse Engineering offengelegt werden, und das selbst durch Angreifer, die nur über wenig Know-how verfügen. Mit Hilfe des frei verfügbaren Tools Apktool (https://ibotpeaches.github.io/Apktool/) und einem der unzähligen JAVA-Decompiler ist es relativ einfach, die .apk zu dekodieren und rekonstruieren, um eine erstklassige Abbildung des Original-Quellcodes zu erhalten. Eine Analyse des unter Einsatz dieser Methode erhaltenen Quellcodes ist dann auch keine Zauberei mehr, und wichtige Sicherheitsfunktionen können einfach aufgespürt werden.

Als erstes fällt bei der App die schiere Menge an Debug-Code ins Auge, zusammen mit exzessivem Protokollieren und noch mehr Loggings, die durch einige wenige Änderungen am Code aktiviert werden können. Die App befindet sich zwar noch in der Beta-Phase, aber bei der Release-Version werden nicht plötzlich 100 Prozent der Funktionen geändert werden, so dass eine derartige Offenlegung vieler Informationen zu diesem Zeitpunkt durchaus als problematisch bezeichnet werden kann. So richtig überrascht hat es uns also nicht, dass die Hauptfunktionen der App relativ einfach identifiziert und analysiert werden konnten. So gelang es uns beispielsweise, eine auf dem PACE Link (Dongle) hinterlegte vollständige Liste aller Bluetooth-Dienste und Eigenschaften einzusehen, ebenso wie ihre Funktionen und UUID. Dargestellt werden diese Ergebnisse in der folgenden Abbildung in einem Ausschnitt des dekompilierten Quellcodes.

Auf Grundlage dieser Liste ist die Suche nach einem Code für den Einsatz einer bestimmten Eigenschaft oder Dienstes ein recht einfacher und unkomplizierter Prozess. Zusammen mit den Informationen, die von den unverschleierten Identifiern geliefert werden, können Angreifer mühelos das gesamte Bluetooth-Kommunikationsprotokoll des PACE Dongels und der App rekonstruieren, inklusive Authentifizierungsprozess.

Ein prüfender Blick auf den Authentifizierungsprozess, z. B. den Aktivierungsprozess, ermöglicht Angreifern die Schlussfolgerung, dass zur Authentifizierung ein Challenge-Response-Verfahren eingesetzt wird. Ebenso können sie erkennen, dass die vom Gerät gestellte Challenge zwar einmalig für das Gerät, jedoch abhängig von dessen Seriennummer ist; in diesem Fall gleichbedeutend mit seiner MAC-Adresse. Auf Seiten der App wird die Response mithilfe eines statischen Algorithmus generiert, zum Einsatz kommen dabei die Challenge des Gerätes und ein serienabhängiger sogenannter CRAM-Schlüssel, der – was wir immerhin mit Erleichterung festgestellt haben – über den Server abgerufen wird. Dieser Prozess kann in seiner Gesamtheit rekonstruiert werden und (was mehr ins Gewicht fällt) durch einen Angreifer potenziell ausführbar sein. In unserem Test haben wir nicht explizit versucht, den Authentifizierungsprozess zu brechen oder ihn unter Zuhilfenahme eines unbekannten Geräts ohne Original-App auszuführen, gehen aber stark davon aus, dass dies möglich ist.

Darüber hinaus ist uns ebenfalls gelungen, den Source-Code als weitere kritische Informationsquelle für einen ganz zentralen Bestandteil des gesamten Sicherheitskonzept anzuzapfen, und zwar hinsichtlich des Client-Zertifikats. Einerseits ist die Verwendung eines Client-Zertifikats beispielhaft zu nennen und noch nicht üblich bei Android-Apps, andererseits ist die Offenlegung des Zertifikats beim Einsatz eines solchen fast noch schlimmer, als wenn überhaupt kein Zertifikat verwendet worden wäre. Ein mögliches Certificate Pinning von Seiten des Servers wird somit nutzlos, wenn das Client-Zertifikat nicht mehr vertrauenswürdig ist und ein Man-in-the-Middle-Angriff serverseitig nicht mehr entdeckt werden kann. Die Tatsache, dass das Client-Zertifikat fest in die App programmiert war, bedeutet auch, dass das gleiche Zertifikat für alle Kopien und damit für alle Nutzer eingesetzt wird.

Zu finden war das Client-Zertifikat als ein String-Array im Code und es war tatsächlich verschlüsselt, unglücklicherweise jedoch zusammen mit dem dazugehörigen Passwort. Wir konnten daraufhin den Java Keystore vom Zertifikat wiederherstellen und schließlich auch den privaten Schlüssel und die Zertifikat-Information exportieren, geholfen hat uns dabei das frei verfügbare Tool portecle. Die folgenden Abbildungen zeigen einen (immerhin fast 100-prozentigen) Ausschnitt der einfachen Klasse, mit der wir den Keystore einsehen und wiederherstellen konnten, sowie die Extraktion des privaten Schlüssels und der Zertifikat-Information mit portecle (ohne Darstellung des privaten Schlüssels).

Online-Kommunikation

Abgesehen von dem geleakten Client-Zertifikat steht die Online-Kommunikation durchaus auf soliden Füßen: Alle Verbindungen sind ausreichend per TLS 1.2 gesichert und zur Verschlüsselung der Kommunikation wird eine adäquate Cipher Suite eingesetzt (siehe folgende Abbildung). Zwar werden nicht alle Verbindung mit SSL-Pinning gesichert, aber es wird immer ein vertrauenswürdiges Zertifikat benötigt und eingesetzt, damit der Server die Verbindung auch akzeptiert.

Mit unserem eigenen auf dem Test-Smartphone installierten Root-Zertifikat konnten wir nahezu alle eingerichteten Verbindungen ausspähen. Unser Lauschangriff enthüllte User-Login, Fahrzeuginformationen (darunter auch die sogenannte Vehicle Identification Number,VIN, gewöhnlich als Fahrgestellnummer bezeichnet), Logs und vieles mehr. Die folgenden Abbildungen zeigen mitmproxy-Mitschnitte und durch eine MitM-Attacke erhaltene Informationen.

Zugegebenermaßen ist ein Angriffsszenario mit einem speziellen Root-Zertifikat auf dem Smartphone des Users unter Android nicht sehr wahrscheinlich (da die Durchführung durchaus schwierig ist), dennoch wird damit zumindest eine theoretische Sicherheitslücke aufgezeigt ebenso wie deutliches Potenzial für Verbesserungen.

Fazit

Zieht man alles in Betracht, und blickt man auf die bereits seit mehreren Jahren laufenden Tests zurück, zählt das PACE Kit im Vergleich dann doch zu den eher sicheren Geräten. Ein paar Probleme haben sich im Test gezeigt, einige davon auch schwerwiegender Natur, aber deren Behebung sollte keine unlösbare Aufgabe sein. In dem Zusammenhang ist auch zu berücksichtigen, dass die getestete Version noch in der Beta-Phase steckt und hinsichtlich der Menge an möglichen Bugs also noch Zugeständnisse gemacht werden müssen. Und dennoch kann die Preisgabe so vieler Informationen in dieser Debug-Version, das hatten wir in diesem Blog-Beitrag bereits erwähnt, als extrem problematisch angesehen werden, wenn die Release-Version auf den Markt kommt. Was die Funktionsweise angeht, sind einige Features wie z.B. die Find-My-Car-Funktion noch nicht implementiert und einige arbeiten noch nicht so, wie sie sollten: laut App lag unser durchschnittlicher Spritverbrauch bei 1,7 Litern auf 100 km, was gelinde gesagt sehr zweifelhaft ist. Sobald die finale Version mit diesen Features auf dem Markt ist, wäre es durchaus im Bereich des Möglichen, dass wir uns selbige auch genauer anschauen und testen.