Über unsMediaKontaktImpressum
Stefan Kiese, Dr. Oliver Matula & Christopher Scheuring 15. März 2016

Car Security – Die Schwachstellen aufgedeckt

Ein modernes Auto besteht aus einer Vielzahl von vernetzten Computern. Diese übernehmen immer mehr Aufgaben, die bis vor einigen Jahrzehnten allein dem Autofahrer vorbehalten waren. Als Beispiel dient der Bremsvorgang auf nasser Straße. Hierbei kommen elektronische Steuergeräte wie das Antiblockiersystem (ABS) oder das Elektronische Stabilitätsprogramm (ESP) zum Einsatz, die zum Beispiel einzelne Räder abbremsen, um ein Gleiten der Reifen zu verhindern und somit die Fahrtrichtung zu stabilisieren. Die Computerisierung des Autos birgt aber auch Gefahren. Potentielle Angreifer können Schwachstellen in vernetzten Komponenten ausnutzen, um Zugriff auf kritische Fahrzeugfunktionen zu erhalten. Im schlimmsten Fall kann so das Auto aus der Ferne gesteuert werden.

Wie sicher sind moderne Fahrzeuge?

Früher bestanden Autos größtenteils aus mechanisch miteinander wechselwirkenden Komponenten: Zum Beispiel wurde das Betätigen des Gaspedals mechanisch in eine Benzin-Luft-Einspritzung übersetzt und die daraus resultierende Drehzahländerung des Motors ebenso mechanisch auf dem Armaturenbrett angezeigt. Die wenigen elektronischen Steuergeräte waren konventionell verdrahtet – wollte Steuergerät A mit B sprechen, wurde eine Leitung zwischen diesen gezogen. Lag eine Fehlfunktion vor, half nur die manuelle Inspektion der unterschiedlichen Komponenten durch den Endverbraucher beziehungsweise den Mechaniker. Heutzutage steuert der Fahrer die mechanischen Komponenten nur noch teilweise selbst. Das meiste wird durch eine Vielzahl an elektronischen Steuergeräten (engl. ECU = Electronic Control Unit) geregelt. Ein Fahrspurassistent kann ein Auto basierend auf Kamerabildern und durch aktives Gegenlenken selbständig innerhalb der Fahrspur halten. Die Geschwindigkeit des Wagens kann durch einen Tempomaten geregelt werden. Letztendlich gipfelt die zunehmende Automatisierung der Fahrzeugführung im autonomen Auto wie dem Google Driverless Car [1].

Insgesamt gibt es vier gute Gründe, die für eine Automatisierung durch elektronische Steuereinheiten sprechen:

  • Effizienz – Die automatisierte Verarbeitung von Sensordaten führt zu einer effizienteren Benzinverbrennung und schont somit die Umwelt.
  • Unfallschutz – Neue Funktionen führen zu einer besseren Fahrzeugkontrolle in kritischen Verkehrssituationen.
  • Komfort – Funktionen wie Tempomat und Spurassistent gestalten das Autofahren angenehmer.
  • Einfache Wartung – Elektronische Komponenten können automatisiert über spezifische Hard- und Software von einem Mechaniker getestet werden.

Die für die Automatisierung eingesetzten Komponenten bringen aber auch neue Risiken mit sich. Denn meist sind diese direkt oder indirekt über verschiedene Schnittstellen gegenüber der Außenwelt exponiert. Neben lokalen Schnittstellen (wie etwa USB oder OBD) kommen hierbei auch Bluetooth-, WLAN- oder GSM-Adapter zum Einsatz. Diese bieten eine große Angriffsfläche, die unter Anderem zu einer unautorisierten Entriegelung der Autotüren oder einer Fernsteuerung des Autos führen kann.

Reconnaissance – Welche Komponenten besitzt ein modernes Auto und wie werden diese untersucht?

Ein modernes Auto besteht im Durchschnitt aus etwa 70 elektronischen Steuergeräten [2]. Diese kommunizieren untereinander über verschiedene Bus-Systeme wie zum Beispiel das häufig eingesetzten Controller Area Network (CAN). Andere wichtige Bus-Systeme sind das Media Oriented Systems Transport (MOST), das Local Interconnect Network (LIN), FlexRay oder Ethernet. Zusätzlich gibt es häufig noch eine Diagnostikschnittstelle (engl. OBD = On-Board-Diagnose), die an einen oder mehrere der Busse angebunden ist und Diagnosetests der einzelnen ECUs ermöglicht. Außerdem kann es noch Bordcomputer geben, zu denen unter anderem das Radio beziehungsweise Multimediasystem gehört. Diese können ebenfalls an das Bus-System angeschlossen sein und gleichzeitig externe Schnittstellen wie USB, Bluetooth oder WLAN bieten.

Die Untersuchung bestimmter Komponenten ist häufig nur durch deren Ausbau möglich. Hierbei ist zu beachten, dass die Lage der jeweiligen Komponente bei jedem Fahrzeug variieren kann. Lediglich die OBD-II Schnittstelle befindet sich immer im Umkreis des Fahrers  [3]. Eine wichtige Komponente, die bei einer umfassenden Untersuchung auf Grund seiner Funktionalität nicht fehlen sollte, ist das sogenannte Telematikmodul. Dieses erkennt man vor allem an seinem Antennenanschluss (meist starre Leitungen und Koax-Verbinder). Das Modul dient unter anderem dazu, Fahrzeugdaten an den Hersteller zu verschicken, beziehungsweise von diesem zu empfangen. Hierüber können Funktionen des Fahrzeuges ausgelöst oder kleinere Firmware-Updates durchgeführt werden. Eine fest verbaute SIM innerhalb des Moduls ermöglicht die Anbindung an das zugehörige Mobilfunknetz. Verbreitet sind solche Module vor allem in Elektro- oder Hybridfahrzeugen, da die Fahrzeughersteller darüber Statistiken über den Zustand der Akkus bei unterschiedlicher Nutzung erstellen können. Aber auch viele Neuwagen sind mit Telematikmodulen ausgestattet – nur sind diese nicht immer aktiviert (teilweise abhängig von der bestellten Ausstattung). Mit der anstehenden Einführung des sogenannten eCall-Notfallsystems innerhalb Europas wird in Zukunft jeder Neuwagen mit solch einem Modul ausgestattet sein; entweder als eigenständiges oder integriert in bereits vom Hersteller verbaute Lösungen.

Möchte man einzelne Komponenten genauer untersuchen, können vorhandene Debugging-Schnittstellen wie Joint Tag Action Group (JTAG) oder Universal Asynchronous Receiver Transmitter (UART) hilfreich sein. Letzterer kann zum Beispiel einen Zugang zu einer Rettungskonsole auf der Komponente ermöglichen. Außerdem kann die Firmware der Komponente möglicherweise über eine der Schnittstellen extrahiert werden.

Zur Identifikation laufender Dienste auf den verschiedenen Komponenten ist es aber nicht unbedingt nötig, die Firmware zu extrahieren. Ist ein WLAN-Hotspot vorhanden, kann ein Port Scan des zugehörigen Netzwerkes durchgeführt werden, um dort laufende Dienste zu identifizieren. Verfügbare USB-Anschlüsse können mithilfe spezieller Hard- und Software auf unterstützte Geräte überprüft werden. Schon durch einfaches Anschließen einer Tastatur lassen sich Informationen gewinnen. Leuchten LEDs beim Drücken der Num-Taste auf, wurde das Gerät vom System höchstwahrscheinlich erkannt und der zugehörige Treiber geladen. Dasselbe gilt für das Anschließen eines USB-Netzwerkinterfaces.

Da der CAN-Bus bei der Kommunikation zwischen den einzelnen Komponenten häufig eingesetzt wird, ist es wichtig, die Kommunikation auf diesem Bus-System zu untersuchen und zu verstehen. Dazu bietet sich aufgrund der bekannten Lage die OBD-II-Schnittstelle an. Diese ist jedoch häufig über ein Diagnose-Gateway an die verschiedenen CAN-Busse des Fahrzeuges angeschlossen. Gateways sind im Allgemeinen dazu da, die Kommunikation zwischen verschiedenen Bus-Systemen zu filtern und unterschiedlich schnelle Busse aneinander anzubinden. Andere Komponenten wie die Tachoeinheit sind dagegen meist direkt an höher privilegierte Bus-Systeme angeschlossen, sodass ein Ausbau dieser Einheit zu einem direkten, ungefilterten Zugriff auf diesen Bus führt. Da der CAN-Bus eine zentrale Rolle für die Datenkommunikation innerhalb des Autos spielt, soll im Folgenden näher auf dieses Bus-System und das zugehörige Protokoll eingegangen werden.

CAN-Bus (Controller Area Network)

Im Jahr 1983 begann die Robert Bosch GmbH die Entwicklung des CAN-Busses mit dem Ziel einer effektiven Vernetzung von elektronischen Steuermodulen. Zwei Jahre später wurde die zugehörige Spezifikation des Bussystems veröffentlicht. Seit 1994 gibt es außerdem eine Standardisierung durch die ISO-11898 Normen. Heutzutage wird der CAN-Bus in fast allen neu produzierten Fahrzeugen eingesetzt.

Standardmäßig besteht der Bus aus zwei isolierten Adern (meist Kupfer). Ist die Spannung beider Kabel auf demselben Niveau (meist 2,5 V), entspricht dies der Übertragung einer 1. Um eine 0 zu übertragen, wird die Spannung des einen Kabels angehoben und des anderen Kabels abgesenkt. Entsprechend ihrer Funktion werden die jeweiligen Kabel beziehungsweise deren Spannungspegel auch als CAN-High und CAN-Low bezeichnet. Der CAN-Bus arbeitet seriell mit Datenübertragungsraten bis zu 1 Mbit/s (abhängig von Material und Kabellänge).

Zugriff auf den CAN-Bus – über das Internet.

Meist sind in einem Fahrzeug mehrere getrennte CAN-Busse mit unterschiedlichen Datenübertragungsraten verbaut, zum Beispiel ein schneller, privilegierter Bus für die Kommunikation zwischen kritischen Steuerungskomponenten (ABS, ESP) und ein langsamer, nicht-privilegierter Bus für unkritische Systeme (Fensterheber, Scheibenwischer). Zum Austausch von Datenpaketen zwischen den einzelnen Bussystemen können spezielle Gateways für den Übersetzungsvorgang zum Einsatz kommen [4].

Auf Applikationsebene bestehen Datenpakete aus einer 11 oder 29 Bit langen Identifikationsnummer (ID) und einem 8 Byte langen Datenfeld. Auf anderen OSI-Ebenen werden Eigenschaften wie die Länge der Datenpakete sowie Checksummen definiert. Die ID dient den über den CAN-Bus verbundenen Steuergeräten als Indikator dafür, ob sie das jeweilige Datenpaket akzeptieren und verarbeiten sollen. Außerdem haben Pakete mit einer niedrigeren ID eine höhere Priorität auf dem CAN-Bus als Pakete mit einer höheren ID. Dies bedeutet, dass ein Steuergerät die Übertragung eines Paketes abbricht, sobald es ein höher privilegiertes Paket auf dem Bus erkennt. Aus der Sicht eines Angreifers ist dies eine willkommene Eigenschaft. Hat der Angreifer sich Zugriff zum CAN-Bus verschafft, kann er den Bus durch Senden von hoch privilegierten Datenpaketen lahm legen.

Die ID eines Datenpaketes ist auf Protokollebene der einzige Anhaltspunkt für ein Steuergerät, um zu entscheiden, ob es das Paket verarbeiten soll. Ein Datenfeld zur Identifikation des sendenden Steuergerätes existiert nicht. Eine Authentifizierung der Steuergeräte durch das Protokoll ist nicht vorgesehen und muss daher innerhalb des Datenbereichs umgesetzt werden. Ebenso wird eine Verschlüsselung des Datenbereichs nicht direkt vom Protokoll unterstützt. Grundlegende Sicherheitsmechanismen müssen also sämtlich von den Herstellern implementiert werden. Dies hat schon zu Sicherheitslücken geführt. Zum Beispiel wird zur Authentifizierung von Diagnosegeräten, die sicherheitsrelevante Funktionen ausführen können, meist ein Challenge-Response-Verfahren verwendet. Dabei beantragt das Diagnosegerät einen Seed vom jeweiligen Steuergerät, gegenüber dem es sich authentifizieren möchte. Aus dem Seed berechnet das Diagnosegerät durch einen Authentifizierungsalgorithmus den zugehörigen Key und sendet diesen zurück an das Steuergerät, um die Authentifizierung abzuschließen. Es existierten jedoch auch schon Steuergeräte, die immer denselben Seed gesendet haben, sodass zur Authentifizierung immer derselbe Schlüssel benötigt wurde [2].

Eine weitverbreitete Meinung ist, dass der CAN-Bus durch den Einbau innerhalb des Fahrzeugs gegen Zugriff von außen geschützt ist. Leider war dies nicht immer der Fall. Bei manchen Fahrzeugmodellen war über physikalisch leicht zugängliche Schnittstellen wie zum Beispiel über den Außenspiegel ein Zugriff auf den CAN-Bus möglich. Weitreichendere Auswirkungen ergeben sich aus Schwachstellen in Komponenten, die an den CAN-Bus angeschlossen sind und gleichzeitig eine Funkschnittstelle (Bluetooth, WLAN, GSM) anbieten. Durch Schwachstellen in diesen Komponenten ist es schon gelungen, Fahrzeuge aus der Ferne, zum Beispiel über das Internet, zu übernehmen – ein entsprechender Angriff wird im nächsten Kapitel beschrieben.

Schwachstellen moderner Autos

In den vergangenen Jahren gab es eine Reihe von Schwachstellen in verschiedenen Autokomponenten. Abb.1 zeigt eine Auswahl wichtiger Veröffentlichungen zu diesen Schwachstellen. Einige dieser Schwachstellen sollen nun näher beleuchtet werden.

Experimentelle Sicherheitsanalyse eines modernen Autos
Die erste umfassende Studie zu den Schwachstellen eines modernen Autos wurde von Forschern der University of Washington und University of California durchgeführt [5]. Das Testobjekt dieser Studie wurde nicht öffentlich genannt, aber es wird davon ausgegangen, dass es sich um einen Chevrolet Malibu handelt [2].

Die Studie betrachtet Funktionen, die mit Zugang zum CAN-Bus (und der Möglichkeit, auf diesem Pakete zu senden) ausgelöst beziehungsweise genutzt werden können. Durch das Senden bestimmter Pakete war es den Forschern zum Beispiel möglich, gezielt eine der Bremsen zu aktivieren. Dies ließ sich manuell durch den Fahrer nicht rückgängig machen. Ebenso war es möglich, das Auto auf- und abzuschließen oder den Motor abzuschalten.

Wie man sich Zugang zum CAN-Bus verschaffen konnte, ohne direkt physikalischen Zugriff auf diesen zu haben, wurde in einer zweiten Studie derselben Forschungsgruppe dargelegt [6]. Mehrere Schwachstellen in verschiedenen Bereichen konnten dabei identifiziert werden:

  1. Der Media Player des Autos verarbeitete typische CDs mit einem ISO 9660 Dateisystem. Durch einen nicht dokumentierten Aktualisierungsprozess ließ sich mit Hilfe einer präparierten CD der Media Player übernehmen. Außerdem gab es einen Fehler im Parser von WMA-Dateien, der zu einem Buffer Overflow im BSS-Segment des Speichers führte. Dieser erlaubte dynamische Funktionszeiger in der Nähe des Buffers zu überschreiben und so beliebigen Code auszuführen. Eine spezielle WMA-Datei, die normal auf einem Computer abgespielt wurde, aber beim Media Player den Buffer Overflow ausnutzte, wurde daraufhin verwendet, um beliebige CAN-Pakete zu senden (der Media Player hatte eine Anbindung zum CAN-Bus).
  2. Im Code, der für die Bluetooth-Funktionalität des Telematikmoduls zuständig war, konnten unsichere strcpy-Funktionsaufrufe identifiziert werden. Dies führte zu einem einfach auszunutzenden Buffer Overflow im Stack, welcher ebenfalls genutzt werden konnte, um beliebige CAN-Pakete zu senden. Jedem gepaarten Gerät war es möglich, diese Schwachstelle auszunutzen. Durch Kenntnis der MAC-Adresse des Telematik-Moduls, die sich durch Abhören von Bluetooth-Paketen ermitteln ließ, sowie durch eine PIN, die sich durch einen Brute Force-Angriff erhalten ließ, war es jedoch möglich, beliebige Geräte innerhalb weniger Stunden mit dem Modul zu paaren.
  3. Die Telematik-Einheit des untersuchten Autos besaß ebenfalls eine Mobilfunkschnittstelle mit einem 3G-Kanal für Internetkommunikation und einen Sprachkanal zum Senden von Unfallinformationen. Der Sprachkanal benutzte ein Software-Modem, das als Gateway fungierte, um Befehle auf der Telemetrie ausführen zu können. Der Code, der die Weiterleitung der Befehle kontrollierte, war jedoch darauf ausgelegt, Befehle von höchstens ~100 Bytes Länge zu verarbeiten. Das Software-Modem konnte aber 1024 Bytes lange Datenpakete empfangen und hat diese auch weitergeleitet. Hierdurch konnte wiederum ein Buffer auf dem Stack überlaufen werden, wodurch es möglich war, beliebige CAN-Pakete von der Telematik-Einheit aus zu versenden. Ausgenutzt hat die Forschungsgruppe den Fehler, indem sie das Auto über ein normales Telefon angerufen hat und eine spezielle Audiodatei mit Modemtönen durch den Audiokanal abgespielt hat.

Schwachstellen des Jeep Cherokee
Die obigen Schwachstellen zeigen, dass es über verschiedene Wege möglich ist, Nachrichten auf dem CAN-Bus zu senden. Motiviert von dieser Forschung haben sich Charlie Miller und Chris Valasek daran gemacht, weitere Fahrzeugmodelle auf Schwachstellen zu überprüfen. Dies resultierte Ende 2015 im öffentlich viel diskutierten "Hack" des Jeep Cherokee.

Während bei den oben beschriebenen Schwachstellen jeweils Überläufe in bestimmen Buffern ausgenutzt wurden, wurde dies beim Jeep nicht benötigt. Hier wurde ein Standardprogramm der Uconnect-Einheit des Autos ausgenutzt [7]. Uconnect steuert das Unterhaltungs- sowie Navigationssystem des Autos und besitzt eine Mobilfunkschnittstelle sowie einen WiFi-Hotspot. Bei dem Standardprogramm handelt es sich um den D-Bus Message Daemon, welcher auf Port 6667 für alle Netzwerkgeräte gelauscht hat. Das Sprint-Mobilfunknetzwerk, an welches das Auto angebunden war, hat Pakete an diesen Port nicht gefiltert. Daher war es möglich, den Dienst aus dem Sprint-Netzwerk (zum Beispiel über ein Mobiltelefon mit Anbindung an dieses Netz) zu erreichen. Der Dienst hatte eine Funktion, die es direkt erlaubt hat, Befehle auf dem OMAP-Chip der Uconnect-Einheit auszuführen. Der OMAP-Chip hatte jedoch keine direkte Anbindung an den CAN-Bus. Jedoch konnte man über den OMAP-Chip einen weiteren Chip, den V850-Chip, ansprechen und über diesen vorgefertigte CAN-Nachrichten senden. Es war auch möglich, die V850-Firmware über den OMAP-Chip zu aktualisieren, so dass man darüber letztendlich beliebige CAN-Nachrichten senden konnte. Da der Dienst aus dem Sprint-Mobilfunknetzwerk erreichbar war, konnte man so letztendlich über dieses Netzwerk beliebige CAN-Nachrichten zum Auto senden. Über die CAN-Nachrichten ließen sich zum Beispiel der Motor ausstellen oder die Bremsen deaktivieren.

Bremsen aktivieren, Türen öffnen oder gleich das Fahrzeug steuern?

Schwachstellen des Tesla Model S
Im Rahmen einer Sicherheitsanalyse von modernen Fahrzeugen haben die Forscher Kevin Mahaffey und Marc Rogers einen Tesla Model S gestellt bekommen. Bei ihrer Analyse konnte ein verborgener Netzwerkanschluss nach dem Ausbau des Infotainment-Systems gefunden werden, der vollen Zugriff auf das System (zum Beispiel über Telnet und Filesystem-Zugriff) und auch auf das Tesla-VPN ermöglichte. Das Tesla-VPN erlaubte den beiden Forschern über das Fahrzeugnetzwerk Zugriff auf die Fahrzeugsteuersoftware QtCarVehicle zu erhalten. Mit dieser war es möglich, über den physikalischen Netzwerkzugriff das Fahrzeug komplett zu steuern. Möglich wäre es auch, einen Trojaner in das Fahrzeugsystem einzuschleusen, der einen Remote-Zugriff auf die Fahrzeugsteuerung ermöglichen würde. Allerdings muss für diesen Angriff ein physikalischer Zugriff auf das Innere des Fahrzeugs gegeben sein.

Ein möglicher Remote-Angriffsvektor auf den Tesla S stellte das 4 Jahre alte Apple WebKit für die Darstellung von Internetinhalten dar. Lässt sich ein Anwender auf eine präparierte Internetseite locken, können Schwachstellen in diesem WebKit genutzt werden, um Remote-Zugriff auf das Fahrzeug zu erlangen.

Schwachstellen von OBD-Adaptern
Weitere Angriffsflächen liefern die mittlerweile in den USA und Europa recht weit verbreiteten Telematic Control Units (TCUs). Diese meist von Drittherstellern entwickelten Adapter werden an die OBD-Schnittstelle des Fahrzeugs gesteckt und implementieren zum Beispiel elektronische Fahrtenbücher oder dienen zur Übermittlung des Fahrverhaltens (Geschwindigkeit, Geo-Position, Zeitstempel) an Versicherungen für einen fahrverhaltensabhängigen Versicherungstarif. Die Ermittlung der Daten erfolgt über die CAN-Schnittstelle des Fahrzeugs. Häufig haben diese Module für die Fernüberwachung ein GSM-Modem verbaut, das Zugriff über Internet oder SMS ermöglicht.

Eine 2015 durchgeführte Studie des Xirgo XT-3000 C4E TCU-Moduls zeigte, dass solche OBD-Adapter ein reelle Angriffsfläche für Remote-Verbindungen liefern, mit denen auf den CAN-Bus des Fahrzeuges zugegriffen werden kann [8]. Das Xirgo XT-3000 C4E nutzt einen Low-Power ARM Core mit 500MHz, 64MB RAM, 256MB Flashspeicher und verschiedene Sensoren (Gyroskope, Beschleunigungssensoren), GPS, Bluetooth und ein GSM-Modem (2G oder 3G). Zusätzlich ist Debugging-Zugriff auf das TCU-Modul über eine USB-Schnittstelle möglich.

Für einen Angriff auf das TCU-Modul existieren zwei Angriffsvektoren: Lokal (zum Beispiel) über die USB-Debugging-Schnittstelle oder aus der Ferne über GSM/Internet. Die USB-Debugging-Schnittstelle lieferte für die Vorbereitung eines Remote-Angriffs wertvolle Informationen über ein HTTP- sowie Telnet-Interface ohne Authentifizierung. Hierüber können Konfigurationsparameter (SIM- und SMS-Konfiguration) sowie weitere Informationen (GPS-Position, Log-Files des Linux-Betriebssystems) ausgelesen und auch verändert werden. Zusätzlich ist ein SSH-Service erreichbar, der allerdings eine Authentifizierung erfordert.

Eine Analyse der Hardware des Adapters ermöglichte das Entfernen und Auslesen des NAND-Flashspeichers. Mit Hilfe des nandsim Linux-Kernel-Moduls konnte über einen Rechner auf den NAND-Speicherinhalt über UBIFS zugegriffen werden. Neben dem eingesetzten Linux-System auf dem TCU-Adapter konnte auf die Daten der Anwendung für den Telemetriedienst und auch auf private/öffentliche kryptographische Schlüssel und Zertifikate und den privaten SSH-Schlüssel für den root-Zugang zugegriffen werden. Eine Überprüfung des SSH-root-Schlüssels auf baugleichen TCUs ergab, dass diese den gleichen SSH-root-Schlüssel verwendeten. Damit war ein großflächiger Angriff über den SSH-Shellzugriff als root auf alle Fahrzeuge möglich, die diesen Adapter nutzten.

Für den Remote-Angriff bietet sich die GSM-Internetverbindung und die SMS-Empfangs- und Sendemöglichkeit an. SSH, Telnet und HTTP sind so konfiguriert, dass diese auf allen Schnittstellen ansprechbar sind (USB-Netzwerk und GSM-Internetverbindung). Problem bei der GSM-Internetverbindung ist allerdings, dass einige Telekommunikationsanbieter ein NAT-Gateway nutzen und somit der Adapter nicht aus dem Internet erreichbar ist.

Falls der Telekommunikationsanbieter eine NAT nutzt, ist immer noch ein Angriff über die SMS-Updatefunktion möglich. Um die Update-SMS an die anfälligen Adapter zu schicken, muss jedoch die SIM-Nummer bekannt sein. Diese kann zum Beispiel über War-Dialing herausgefunden werden. Hierzu wird eine Service-SMS mit status an alle Nummern eines Anbieters versendet und die Antwort-SMS ausgewertet. Mit Hilfe des SMS-Updateprozesses und eines eigenen Internetservers ist es letztendlich möglich, eine SSH-Verbindung aufzubauen, über die der Angreifer als root auf den Adapter zugreifen kann.

Angriffe auf das Schließsystem eines Fahrzeugs
Neben den oben vorgestellten Angriffen, deren Ziel der Zugang zum CAN-Bus war, gibt es auch immer wieder Angriffe auf die Schließsysteme eines Fahrzeugs. Während hierfür früher einige Hersteller auf eine Fernschließung per Infrarot setzten, kommen heute ausschließlich aktive oder passive Funksysteme zum Einsatz.

Bei der normalen Funkfernbedienung spricht man von einem aktiven System: Es muss manuell ein Knopf betätigt werden, welcher dem Fahrzeug ein Signal übermittelt. Nun kann hier noch zwischen uni- und bidirektionaler Kommunikation unterschieden werden. Erfolgt die Kommunikation unidirektional, wird in der Regel auf Rolling Codes gesetzt, das heißt, jede Übertragung einer Aktion ist individuell, da ein Teil der Übertragung aus einem sich ändernden Code besteht. Hierzu bestehen zwei Codetabellen – eine in der zuständigen ECU des Fahrzeuges, eine im Schlüssel. Bereits verwendete Codes lassen sich nicht ein zweites Mal verwenden, was Replay-Attacken, bei denen das gesendete Signal aufgezeichnet und erneut wiedergegeben wird (was mit Hardwarekosten von ca. 5€ verbunden wäre) verhindert. Nach einer definierten Anzahl von Tastendrücken (in der Regel 1.000) müssen Sender und Empfänger erneut synchronisiert werden. Als sicher kann diese Technologie trotzdem nicht bezeichnet werden, da außerhalb der Reichweite des Fahrzeugs ein Tastendruck zum Öffnen aufgenommen und am Fahrzeug wiedergegeben werden kann. Weiterhin besteht noch die Möglichkeit des Brute Force-Angriffs auf valide Codes oder der Code-Vorhersage. Leider gibt es auch heute einige wenige Automodelle, die nicht einmal Rolling Codes verwenden. Hier lässt sich mit einer "erbeuteten" Übertragung das Auto beliebig oft öffnen.

Bei bidirektionaler Kommunikation erfolgt die Kommandoübergabe ans Fahrzeug erst nach Authentifizierung des Schlüssels. Dies wird meist durch ein Challenge-Response-Verfahren realisiert.

Passive Systeme verwenden in der Regel RFID-Technologie. Hier kann das Fahrzeug geöffnet und/oder gestartet werden, ohne den Schlüssel aus der Tasche zu nehmen. Innerhalb des Autos befinden sich mehrere Sende- und Empfangsmodule, die Signale aussenden, die die RFID-Hardware im Schlüssel aktiviert und daraufhin mit dieser kommuniziert. Auch hier gibt es unterschiedliche Verfahren, die Teils auf Kryptographie und/oder auf Signallaufzeiten setzen, um eine gewisse Sicherheit zu gewährleisten. Meist ist die Leistung von RFID-Lösungen stark beschränkt, da die Betriebsenergie in der Regel extern bezogen wird (drahtlos durch den Sender im Auto) und somit eher gering ausfällt. Dies macht starke Verschlüsselung nahezu unmöglich und ist eine potentielle Schwachstelle dieser Systeme. Außerdem werden durch fehlende Überwachung der Signallaufzeit sogenannte RFID-Relay-Angriffe ermöglicht. Hierzu befindet sich Person X in der Nähe (oft 20cm) des Schlüsselbesitzers mit einem RFID-Gerät und einem Datenfunkgerät (zum Beispiel Mikrocontrollerboard mit Funklösung oder Software Defined Radio). Am Fahrzeug befindet sich Person Y, welche über die gleiche Hardware verfügt. Sendet das Auto nun ein Signal für den RFID-Schlüssel aus, wird dies über den Datenfunk an Person X übertragen, welche mittels verstecktem RFID-Gerät (z. B. im Jackenärmel) nahe des Schlüsselbesitzers ist und dessen Schlüssel aktiviert, der darauf antworten wird. Nun wird dieses Signal zurück an Person Y am Fahrzeug übermittelt, bei der das RFID-Gerät das Signal für das Fahrzeug zur Verfügung stellt, welches sich nun öffnen wird. Diese Attacke ist zwar nicht trivial, aber mit heutiger Hardware dennoch zu einem geringen Preis und mit einem handhabbaren Aufwand zu realisieren.

Fazit

Moderne Autos können als ein komplexes Computer-Netzwerk mit einer Vielzahl von externen Schnittstellen angesehen werden. Als solches erben sie die gleichen Schwachstellen, die auch in normalen Netzwerken auftreten können. Da die Ausnutzung solcher Schwachstellen in Gefahr für Leib und Leben resultieren kann, ist es notwendig, Schwachstellen entweder erst gar nicht entstehen zu lassen oder diese so weit wie möglich einzugrenzen. Ersteres lässt sich durch eine auf Sicherheit ausgelegte Entwicklung der Soft- und Hardware mit anschließenden Schwachstellentests erreichen. Letzteres heißt, dass die Kompromittierung einer ECU des Autos nicht sofort auch die Möglichkeit bieten sollte, alle anderen ECUs des Autos zu kompromittieren. Eine geeignete Isolierung von Komponenten, die nicht miteinander kommunizieren müssen, ist daher nötig. Für Komponenten, die untereinander kommunizieren müssen, sollte das Kommunikationsverhalten eingegrenzt werden. Insgesamt sollten auch geeignete Zugriffsbeschränkungen (zum Beispiel über Authentifizierung) für externe Schnittstellen implementiert werden.

Letztendlich läuft dies darauf hinaus, dass beim Design des Auto-Netzwerkes berücksichtigt werden muss, dass eine Schwachstelle generell in jeder Komponente auftreten kann. Sicherheitsmaßnahmen auf Netzwerkebene (wie die oben genannte Isolation einzelner Komponenten) können die Auswirkung dieser Schwachstellen jedoch effektiv eingrenzen.

Quellen
  1. Google: Driverless Car
  2. C. Miller und C. Valasek: Adventures in Automotive Networks and Control Units
  3. OBD-II Regulations
  4. T. Trautmann: Grundlagen der Fahrzeugmechatronik, Vieweg+ Teubner GWV Fachverlag GmbH, 2009, S. 116
  5. K. Koscher et al.: Experimental Security Analysis of a Modern Automobile
  6. S. Checkoway et al.: Comprehensive Experimental Analyses of Automotive Attack Surfaces
  7. C. Miller und C. Valasek: Remote Exploitation of an Unaltered Passenger Vehicle
  8. I. Foster et al.: Fast and Vulnerable: A Story of Telematic Failures

Autoren

Christopher Scheuring

Christopher Scheuring war Security-Experte für einen Deutschen Fahrzeughersteller und lehrt an der Dualen Hochschule Mosbach Web Engineering und IT Security.
>> Weiterlesen

Stefan Kiese

Stefan Kiese ist als IT Security Analyst tätig und hat einen starken Hintergrund in Elektronik und Nachrichtentechnik.
>> Weiterlesen

Dr. Oliver Matula

Dr. Oliver Matula ist promovierter Physiker und als IT Security Consultant tätig. Er möchte als Wissenschaftler die Welt zu einem sichereren Ort zu machen.
>> Weiterlesen
botMessage_toctoc_comments_9210