• Keine Ergebnisse gefunden

1 Einleitung und Motivation

3.2 Praktische Laboruntersuchungen zu Manipulationsmöglichkeiten an automotiver IT

3.2.7 Bösartige Interaktion in drahtlosen Car-to-X Funknetzwerken (L 6.x )

Weitere praktische Untersuchungen wurden zum Kontext zukünftiger Car-to-X Kommunikati-onsnetzwerke durchgeführt. Ziel hierbei ist es, exemplarische Angriffsszenarien in zukünfti-gen C2X-Infrastrukturen praktisch zu untersuchen um das Ausmaß ihrer potentiellen Folzukünfti-gen abschätzen zu können und ggf. die Erforderlichkeit wirksamer Security-Konzepte zu unter-streichen. Die in diesem Abschnitt kompakt vorgestellten Ergebnisse können ausführlicher der eigenen Arbeit [HKKD13] entnommen werden.

14 Hinweis: Ziel des Versuch L5 war es zunächst primär, die grundsätzliche Machbarkeit von Funkti-onsänderungen am Testgerät und die wesentlichen zugrundeliegenden Techniken aufzuzeigen. Es wurden keine konkreten funktionalen Änderungen am Gerät vorgenommen und demonstriert, was sich mangels vorliegender Systemdokumentation vergleichsweise aufwendig gestaltet hätte. Als ein beste-hendes Praxisbeispiel für Code-Manipulationen an diesem Gerätetyp wird in Abschnitt 6.4.1 die als R5.3 recherchierte automotive Schadsoftware vertiefend auf ihre Wirkungsweise bzw. die durchgeführ-ten Änderungen am Originalcode des Navigationssystems analysiert.

Mangels zum Testzeitpunkt verfügbarer Produktivsysteme werden zwei ausgewählte Ent-wicklungs-/Testumgebungen verwendet, die für C2X-Forschungsaktivitäten bereit stehen:

NEC LinkBird-MX: Für Forschung und Entwicklung zu C2X und IEEE802.11p bietet die Firma NEC den Prototyp LinkBird-MX [Nec08] an, der sich universell als On-Board-Unit (OBU) in Fahrzeugen oder stationär als Roadside Unit (RSU) einsetzen lässt (Abbildung 31). Ein auf dem Gerät laufender IP-basierter Dienst namens Car to X daemon (kurz:

C2Xd) verwaltet verschiedene C2X-bezogene Protokollschnittstellen. Wird das Gerät als OBU eingesetzt, können fahrzeuginterne Systeme (hier als Application Units / AU be-zeichnet) aus der In-Vehicle-Domain über verschiedene IP-basierte Protokolle den C2Xd-Dienst der OBU nutzen, um über Funkkommunikation nach IEEE 802.11p mit Systemen in der Ad-Hoc-Domain zu interagieren. Für Java-basierte AUs wird mit dem sog. C2X-SDK eine Programmierschnittstelle zwischen Java und dem C2Xd-Dienst bereitgestellt.

Vector CANoe Option .Car2x: Die für die die Entwicklungs- und Simulationssoftware CANoe der Vector Informatik GmbH verfügbare Option .Car2x [Vect14b] ermöglicht u.a.

die Simulation von C2X-Datenverkehr nach IEEE 802.11p. Genutzt wurde die enthaltene Demonstrations-Konfiguration „Car2xSystemDemo“, die grundlegende Möglichkeiten von C2X in einer exemplarischen Verkehrsumgebung (Abbildung 32) illustriert. Entgegen der restlichen Labortests mit CANoe 7.0 SP6 (vgl. Versuchsumgebung in Abschnitt 3.2.1), wurde für die in diesem Abschnitt vorgestellten Arbeiten an der Produktoption .Car2x ei-ne Demoversion in Version 7.6 SP3 verwendet.

 64bit MIPS-basierter Mikroprozessor bei einer Taktrate von 266 MHz

 2 Gigabyte interner NAND Speicher für das Betriebssystem und Anwendungen

 128 MB Arbeitsspeicher

 Debian Etch mit GNU Linux 2.6.19 als Betriebssystem

 vorinstalliertes C2X-Software-Development-Kit (SDK) inklusive Testprogramme

 Fast Ethernet 10/100 Base-T Netzwerkkarte (NEC candy)

 miniPCI IEEE 802.11p Draft 3.0 kompatible MIMO-WLAN-Karte (Atheros 5212)

 2 SMA Antennenanschlüsse, 2 CAN-Bus Controller, 2x USB 2.0, 2x PCMCIA/Cardbus

Abbildung 31: IEEE 802.11p Prototyping-System NEC LinkBird-MX inkl. Eckdaten

Abbildung 32: Simuliertes C2X-Verkehrsszenario aus Vector CANoe .Car2X [Vect14b]

Die Unterstützung von Security-Features, wie sie z.T. in verschiedenen Arbeitsgruppen erar-beitet (vgl. Abschnitt 2.5.3) und standardisiert werden (z.B. IEEE 1609.2 [IEEE13] und ETSI TS 103 097 [ETSI13]), war in den verwendeten C2X-Testumgebungen zum Testzeitpunkt noch nicht oder nur in Ansätzen vorhanden. Die Testumgebungen dienen daher primär als Hilfsmittel für die praktischen Tests, um das potentielle Ausmaß von Folgen erfolgreicher Angriffe über die Simulation entsprechender Angriffsszenarien abschätzen zu können.

Die mit Hilfe des LinkBird-MX simulierten Angriffsszenarien fokussieren einen externen An-greifer, d.h. Angriffe, die von eingehenden C2X-Nachrichten aus der Ad-Hoc-Domain ausge-hen. Exemplarisch werden Denial-of-Service (DoS) Angriffsszenarien betrachtet, die sich das Ziel setzen, mittels präparierter Nachrichten andere Teilnehmer z.B. aus dem Netzwerkver-bund auszuschließen (Verfügbarkeits-Angriff). Die OBU bzw. der auf ihr laufende Dienst C2Xd fungiert als eine Art Gateway zwischen den fahrzeuginternen AUs und dem C2X-Drahtlosnetzwerk. Besonders auch mit Blick auf die Verfügbarkeit der C2X-Technologie ist die OBU somit eine der kritischsten Fahrzeugkomponenten – fällt sie aus, ist keine C2X-Kommunikation der fahrzeugseitigen Application Units mehr möglich.

L6.1 – DoS-Angriff auf eine C2X Onboard-Unit: Die praktische Simulation entsprechen-der Angriffsszenarien erfolgt über in Python2 verfasste Skripte, mittels entsprechen-derer aus entsprechen-der Hoc-Domain direkt mit dem C2Xd kommuniziert wird. Sie simulieren einen Knoten im Ad-Hoc-Netzwerk, der unter Nutzung der regulären Protokolle fehlerhafte C2X-Nachrichten in die Ad-Hoc-Domain übermittelt.

Durch das als Grundansatz gewählte Fuzzing15 gelingt es, mögliche Belegungen von C2X-Paketinhalten zu identifizieren, die zum Absturz des C2Xd-Dienstes der (in Sende-reichweite befindlichen) Empfängerknoten führen können, woraufhin die Kommunikation mit ihnen unterbrochen ist. In der vorliegenden Implementierung tritt dies ein, wenn sog.

Geo-Broadcast bzw. Geo-Anycast Nachrichten mit einer Positionsangabe versendet werden, deren Breitengrad größer als 0x35A4E900 (dezimal: 90000000) ist. Der Fehler kann im Logfile des C2Xd der Umwandlung von Längen-/Breitengraden in kartesische Koordinaten zugeordnet werden:

c2xd: ../src/location.c:213: angle_to_cart:

Assertion ‘(-90 <= angle->lati) && (angle->lati <= 90)' failed.

Weitere Tests zeigen, dass durch gezieltes Setzen der Node-ID in den generierten C2X-Nachrichten auch ein einzelner Teilnehmer im Angriffsradius von der DoS-Wirkung aus-genommen werden kann, so dass auch Angriffe zur Isolation eines Knotens denkbar sind.

In der Praxis könnte bei Existenz vergleichbarer Schwachstellen die Kommunikation zwi-schen den Knoten durch solche DoS-Angriffe empfindlich gestört werden. Auch das wichtige Routing von Nachrichten wäre im (ggf. noch erweiterbaren) Sendebereich des Angreifers nicht mehr möglich. Durch die typische Topologie von Verkehrsnetzen könnten durch wenige Eingriffe eines Angreifers ganze Streckenabschnitte in der Kommunikation gestört werden.

In der Simulation der Car2xSystemDemo fahren sieben Fahrzeuge einen vorgegebenen Rundkurs jeweils in unterschiedlicher Geschwindigkeit und Richtung. Sie richten sich dabei nach der Ampel, die ihre Rot-/Gelb-/Grün-Phasen zyklisch in festgelegten Zeitabständen durchläuft. Eine einleitend durchgeführte Analyse der verwendeten C2X-Datenflüsse ergibt u.a., dass die Fahrzeuge alle 1000 ms mittels einer sog. CAM-Nachricht (Cooperative Awareness Message) ihre aktuelle Position und Geschwindigkeit mitteilen. Der Status der als Roadside Unit agierenden Ampel wird alle 500 ms mittels einer sog. SPaT-Nachricht (Signal Phase and Time) verbreitet und umfasst u.a. ihre Geokoordinaten, die aktuelle Ampelphase und die Zeit bis zum nächsten Umschaltvorgang. Ein in Reichweite der Ampel befindliches Fahrzeug reagiert es mit einem Brems- bzw. Haltemanöver, sofern der über die

15 Hierbei wird ein aus Black-Box-Sicht betrachteter Algorithmus mit komplett zufälligen oder selektiv abgewandelten Eingabedaten aufgerufen, um Softwareschwachstellen wie z.B. nicht geprüfte oder nicht abgefangene Fehlerbedingungen aufzudecken. Durch hierbei häufig provozierbare Abstürze können entsprechende Schwachstellen z.B. für DoS-Angriffen missbraucht werden, teilweise darüber hinaus auch für erweiterte Zugriffe wie z.B. das Einschleusen von Schadcode.

Nachricht übermittelte Status der Ampel nicht grün ist und die Ampel weniger als 20 Meter entfernt ist. Wesentliche Beispiele der in [HKKD13] simulierten Angriffsszenarien sind:

L6.2 – Übernehmen der Identität von Fahrzeugen oder Ampeln: In zwei simulierten Angriffsszenarien werden Folgen eines Identitätsdiebstahls in C2X-Netzwerken unter-sucht. Im ersten Fall liest das Fahrzeug des Angreifers die Identität eines vorbeifahren-den Fahrzeugs aus und übernimmt diese anschließend selbst, indem es die eigenen CAM-Nachrichten nur noch mit der ausgelesenen anstatt der (ehemaligen) eigenen Iden-tität versendet. Im zweiten Fall wartet der Angreifer auf regulär gesendete SPaT-Nachrichten der Ampel und setzt anschließend Kopien dieser SPaT-Nachrichten mit selektiv verfälschten Informationen (z.B. Ampelphase oder -standort) und unveränderter Absen-deradresse ab. Zur Implementierung der Angriffsszenarien wird einem als Angreifer aus-gewählten Fahrzeug der Car2xSystemDemo zusätzlicher, schadhafter Programmcode hinzugefügt. Die als Simulationsergebnis ermittelbaren Folgen sind u.a.:

Im Fall der Car-to-Car-Datenflüsse, die in der Car2xSystemDemo lediglich zu Informati-onszwecken ausgewertet werden, wird ab Inkrafttreten des o.g. Angriffs kein Fahrzeug mit der ID des Angreifers mehr geführt, dafür jedoch zwei Fahrzeuge mit der ID des vom Identitätsdiebstahl betroffenen Fahrzeugs. Im Kartenfenster (Abbildung 32) bleibt die Markierung des Angreiferfahrzeugs ab diesem Zeitpunkt stehen, während das Zielfahr-zeug in zweifacher Ausführung (und ggf. entgegengesetzten Richtungen) weiterfährt.

Im Fall der zusätzlich eingespielten Ampelnachrichten resultiert die Simulation dieses Angriffs hingegen in effektiven Auswirkungen auf den Verkehr. Setzt der Angreifer in sei-nen gefälschten Kopien z.B. die aktuelle Ampelphase auf „Grün“, ist zu beobachten, dass andere Fahrzeuge die Kreuzung auch während einer Rotphase überqueren. Verfälscht er die Ampelkoordinaten auf eine andere, auf dem Rundkurs befindliche Position, halten beim Rotsignal der originalen Ampel auch Fahrzeuge an der gefälschten Ampelposition.

Gleichzeitig überfahren auch Fahrzeuge die rot zeigende Ampel an der realen Position.

Sollte es in der Praxis Angreifern zukünftig gelingen, die geplanten und in der verwendeten Car2xSystemDemo noch nicht implementierten C2X-Schutzkonzepte zu umgehen, wäre laut den Simulationsergebnissen mit Folgen zu rechnen, die grundsätzlich von angezeigten Falschinformationen bis hin zu effektiven Auswirkungen auf den Verkehr reichen können.

ÄHNLICHE DOKUMENTE