Eigentllich sollte dieser Beitrag ein Rant auf den Datenreichtum bei VW („Volksdaten“ und die Unfähigkeit des OEMs, personenbezogenen Daten aus Fahrzeugen zu anonymisieren) und Subaru (auch hier trägt man mit gut gefüllten Trögen zum Datenreichtum bei) werden – vielleicht auch ein wenig mit Häme gerniert. Dann schien es mir jedoch sinnvoller, die Leserschaft zunächst einmal durch die Historie des Car-Hackings zu begleiten, um auf diese Weise ein wenig das Verständnis für das Thema Automotive Cybersecurity (ACS) zu wecken. Insoweit wurde der Rant auf einen späteren Zeitpunkt verschoben.
Dieser Beitrag startet also mit der historischen Entwicklung des Car-Hackings (Teil 1). Dann kommt der Rant auf VW und Subaru (Teil 2) und abschließend gibt es in einem dritten Beitrag zu den Rahmenbedingungen (regulatorischer und prozessualer Art) zur Automotive Security.
Zwischenzeitlich ist ja ein gewisser Gewöhnungseffekt bzgl. der im Stakkato aufschlagenden Meldungen über Datenverluste und „gehexte“ Infrastrukturen in der breiten Masse des interessierten Publikums eingetreten. Bisher waren in diesen Meldungen die üblichen Verdächtigen (Softwarehersteller, Infrastrukturbetreiber und sonstigen Serviceanbieter) zu finden. Seit einiger Zeit schwappt die Welle von ausnutzbaren Schwachstellen allerdings auch in Branche der OEM hinein.
Dabei sind gehackte Fahrzeuge und Angriffe auf Backend-Strukturen der OEMs und Flottenbetreiber kein Novum:
Um 2001 ereilte es VW, Audi, Chevrolet, Dodge, Subaru und Ford: Endkunden beauftragten eine dritte Partei, durch Modifikationen an relevanten Steuergeräten etwas mehr Motorleistung aus den Antrieben bestimmter Derivate der vorgenannten Hersteller rauszukitzeln. Gibt es heute auch noch – nennt sich Tuning.
Im Jahre 2005 waren dann Chrysler, GM und Nissan mit ihren Bluetooth-Stacks in den Fahrzeugen betroffen. Angreifer konnten diese kompromitieren und in der Folge Gespräche, die über verbundene Mobilfunkgeräte geführt wurden, mithören oder Kontaktdaten aus Telefonbüchern extrahieren.
Zwei Jahre später, im Jahr 2007, zeigten Sicherheitsforscher auf der CanSecWest, dass sie in der Lage sind, herstellerübergreifend den Radio-basierten Traffic Feed so zu modizieren, dass fehlerhafte Staumeldungen ausgegeben wurden – sozuagen die frühe Version von „Freie Fahrt für freie Bürger!“.
Weiter ging es dann 2010 mit GM und Jeep: Angreifer waren in der Lage, remote alle wesentlichen Fagrzeugfunktionen, abgesehen von der Lenkung, zu übernehmen. Lustiger fun fact: GM brauchte rund 5 (sic!) Jahre, um die Schwachstelle, die diesen Hack erst ermöglichte, zu fixen. Jeep kam (wahrscheinlich wegen der Rückrufpflicht der NHTSA) da schneller zu einer Lösung das Problems. Dann gab es 2010 herstellerübergreifend noch ein paar Probleme mit dem Tire-Pressure Monitoring System (TPMS) sowie der Möglichkeit, die Bremsfunktion es Fahrzeugs mittels eines am OBD-Port des Fahrzeugs angestecktem Dongle zu beeinflussen
Dann kam 2013 – das Jahr von Charlie Miller und Chris Valasek, die sich mittels OBD-Schnittstelle Zugriff auf alle Fahrzeugfunktionen (einschließlich der für die Fahrdynamik relevanten Quer- und Längsbeschleunigung) bestimmter Fahrzeug von Ford und Toyota verschafften. Hierzu gibt es auch ein kleine Videodokumentation von Andy Greenberg bei YT. Aufgrund des Medienechos auf den vorgenannten „Hack“ ging dabei fast die Nachricht unter, dass VW (Bentley), Audit, Porsche and Lamborghini in diesem Jahr auch ein paar operationelle Probleme mit ihrer Wegfahrsperre hatten. Zum Glück für die Hersteller stoppte der High Court of Britain unverzüglich die Veröffentlichung des diesem Angriff zugrundeliegenden Papers der Sicherheitsforscher aus Holland und UK mit der Begründung, dass der Hack so einfach sei, dass die Gefahr bestand, dass dieser „industrialisiert“ werden und damit buchstäblich jeder mit den diesen Fahrzeugen eine kleine Spritztour unternehmen könnte.
In 2014 ereilte es dann Honda – Hacker pflanzten eine kleine Platine an den CAN-Bus des Fahrzeug, welche remote via GSM-Network erreichbar war. In der Folge konnte die Angreifer sämtliche Fahrzeugfunktionen remote steuern.
Ein Jahr später, in 2015, machten wieder Charlie Miller und Chris Valasek von sich reden: Sie setzten Andy Greenberg in einen Jeep Cherokee (damals noch Fiat Chrysler Automotive, heute Stellantis) und ließen ihn damit über die Stadtautobahn in St. Louis fahren. Um die Fahrt für Greenberg etwas abwechslungsreicher zu gestalten, griffen sie remote auf verschiedene Fahrzeugfunktionen bis hin nzur Bremse zu. Hierfür war es nicht notwendig, über ein Zusatzgerät Zugriff auf die ´´interne Bussysteme des Fahrzeugs zu nehmen. Vielmehr wurde eine Schwachstelle in der UConnect-Funktionalität der Headunit für diesen Angriff genutzt, wobei der Zugriff über das Internet-Frontend möglich war.
Auch hatte Tesla in 2015 sein Debüt auf der Bühne des Automotive Hackings. Security Researcher des Tencent Keen Labs waren in der Lage, über eine Wifi-Verbindung in einem Tesla Model S die Bremsen während der Fahrt auszulösen. Hiernach hielt dann auch bei Tesla Code Signing als eine Schutzmaßnahme Einzug in alle Fahrzeuge des Herstellers.
Das Jahr 2015 endete sodann mit einem brachenweiten Happening der Hauptdarsteller VW, Honda, Audi, Hyundai, Kia, Porsche & Volvo zum Thema „Wie man die Kommunikation des Keyfobs mit dem Fahrzeug über eine Replay-Attacke etwas aufbohrt“. Auch hier wieder eine side note zum Thema Schachstellen-Handling: VW kannte die Schwachstelle schon seit 2013, hat jedoch zunächst einmal mehr Energie in das juristische Krisenmanagement gesteckt, anstatt die Schwachstelle auch zeitnah zu fixen.
Den Reigen von Automotive Cybersecurity Incidents im Jahr 2016 eröffnete Nissan mit seinem Nissan Leaf, auf den Hacker über die Backend-API remote zugreifen konnten. Als nächster OEM war dann Mitsubishi an der Reihe – Hacker waren in der Lage, über das Onboard Wifi die Alarmanlage des Fahrzeugs zu deaktivieren um so den Diebstahl des angegriffenen Fahrzeugs, einem Mitsubishi Outlander, zu ermöglichen. Auch für Fiat Chrysler (FCA) lief das Jahr 2016 nicht so optimal – zum einen waren da wieder die Probleme mit den Relay/Replay-Attacken auf die Keyfob-Kommunikation mit dem Fahrzeug. Zum anderen gab es wieder Schwachstellen in der Kommunikation über den OBD-Port, so dass über ein Dongle beliebige Steuerbefehle an die Onboard-ECUs übertragen werden konnten (einschließlich Befehle zur Beeinflussung der Fahrdynamik). Auch Tesla stand 2016/2017 wieder im Fokus des Interesses von Security-Enthusiasten aus den Keen Labs von Tencent. Dieses Mal traf es ein Tesla Model X, auf dem remote bestimmte Kundenfunktionen aktiviert werden konnten.
In 2017 traf es dann Hyundai, auf dessen Fahrzeuge Hacker via einer Sschwachstelle in der Hyundai Blue Link Mobile App remote über das ungesicherte Fahrzeug-WiFi zugreifen und sodann das Fahrzeug starten konnten.
Im folgenden Jahr 2018 gab es sodann noch ein kleines Intermezzo beim Remote Service-Anbieter Calamp, über dessen fehlkonfiguriertes Backend-System IoT-Devices von Viper SmartStart in 1,5 Millionen Fahrzeuge für Hacker fernsteuerbar waren.
Die nächsten nennenswerten Schwachstellen im Automotive Cybersecurity-Umfeld fielen im Jahr 2020 Ford und VW auf die Füße: Zum einen war es den Angreifern möglich, auf personenbezogene Daten von Kunden wie standortspezifische Informationen oder Kontaktdaten zuzugreifen, als auch remote Kundenfunktionen im Fahrzeug aufzurufen. Im gleichen Jahr gelang es einem Team von Sicherheitsforschern auf der Pwn2Own, eine Schwachstelle in der Multimedia Control Unit (MCU) eines Tesla Model 3 mittels zero-click exploit auszunutzen.
Zwei Jahre später traf es auf der Pwn2Own wieder ein Teslas Model 3. Dieses Mal gelang der remote durchgführte Angriff auf das Infotainment-System des Fahrzeug mittels einer Schwachstelle im LTE-Modem.
In den letzten zwei Jahren sind die medientauglichen Automotive Cybersecurity Hacks offenkundig etwas weniger geworden. Dies könnte verschiedene Gründe haben:
These 1: Mit dem Inkrafttreten der Automotive Cybersecurity Regulierungen (der UN R155 für den Wirtschaftsraum der 1958er Vertragsstaaten sowie der GB 44495-2024 für China) ist das Sicherheitsniveau im Automotive Sektor gestiegen. Klar – die These steht insoweit auf wackligen Füßen, als dass zum einen die Entwicklungszeiträume für E/E-Systeme sich über 5 bis 7 Jahre erstrecken und die in den letzten zwei Jahren erstmals vom Band gelaufenen Fahrzeuge ihren „Cybersecurity-Zuschnitt“ i.S. der Sicherheitsarchitektur zwischen 2017 und 2019 erfahren haben. Zum anderen fahren auch noch viele Fahrzeuggenerationen auf den Straßen herum, deren E/E-Systeme vor langer Zeit designt und auf dieser Grundlage sodann die notwendigen Komponenten und Funktionen entwickelt und implementiert worden. Signifikante Änderungen am E/E-System, insbesondere auf der Hardwareebene, sind nach dem Start-of-Production (SoP) Date kaum realisierbar oder mit derart erheblichen Kosten verbunden, dass die zuständigen Produktverantwortlichen lieber den Lebenszyklus des jeweiligen Derivats (End-of-Production, EoP) vorzeitig beenden1 als dieses nachträglich hardware- bzw. softwarechtechnisch zu befähigen. Insoweit könnten sich Hacker eben gerade auf diejenigen Derivate konzentrieren, die schon lange „im Feld“ sind und dortige Schwachstellen ausnutzen, anstatt es mit den neuesten E/E-Generationen aufzunehmen.
These 2: Mit dem Eintritt von sicherheitsrelevanten Ereignissen bei einem OEM werden regualtorische Prozesse in Gang gesetzt, die unter Umständen die Homologationsfähigkeit eines Derivats oder Cybersecurity Type grundsätzlich in Frage stellen´ würden. Insoweit könnten OEMs versucht sein, mittels non-disclosure Vereinbarungen die Existenz von bestimmten Schwachstellen möglichst nicht in die große weite Welt hinauszuposaunen. Das dieses Szenario nicht unbedingt fernliegend ist, zeigte VW anlässlich der Hacks von 2013, 2015 und 2024 sehr eindrucksvoll. Auf der anderen Seite setzt Compliance zu den einschlägigen Automotive Cybersecurity (ACS)-Regulierungen eine entsprechende Informationspflicht des OEMs in Richtung der jeweiligen Aufsichtsbehörden vor und es ist davon auszugehen, dass die OEMs dieser Verpflichtung sicher nachkommen werden.
Unabhängig von den vorgenannten, vermeintlichen Gründen des Absinkens des Rauschpegels von Nachrichten über Schwachstellen in Komponenten und Funktionen in Fahrzeugen sowie deren Backend-Systemen ist das Problem dennoch nicht verschwunden. Zum einen sind da die in den letzten 3-4 Jahren auf den einschlägigen Security-Konferenzen immer wieder gezeigten Angriffe mittels Remote Code Execution (RCE), die den Beweis dafür antreten, dass die Sicherheitsforscher mit der aktuellen Technologieentwicklung bei den OEMs Schritt halten. Zum anderen nimmt die technischen Komplexität von Gesamtfahrzeugsystemen insbesondere im Kontext der automatisierten Fahrfunktionen immer weiter zu. Damit bieten zukünftige Fahrzeuge eine größer werdende Angriffsfläche gegenüber potentiellen Attacken.
- Sprechende Beispiele für dieses Szenario waren Porsches Macan, der 718 Boxster und der 718 Cayman. Die E/E-Systeme dieser Fahrzeuge hätte die homologationsrechtlichen Anforderungen der UN R155 zum EIntrittszeitpunkt der all type-Regulierung zum 01. Juli 2024 nicht mehr erfüllt und wurden daher vom Hersteller aus den UN R155-Märkten genommen. ↩︎