# Glitching Angriffe Auf Fahrzeuge

- Link: https://smartnuts.com/2025/06/04/glitching-angriffe-auf-fahrzeuge/
- Veröffentlicht: 2025-06-04T12:10:58+02:00
- Autor: Michael Bunzel

Die digitale Welt da draußen ist gefährlich. Nicht nur für elektronische Bankgeschäfte,(
bewußt) schlecht implementierte Krypto Wallets oder wertvolle Unternehmensdaten,
die in den Clouds dieser Welt vor sich hin vegetieren und nur darauf warten, dass
jemand die Gammelinfrastruktur des Cloud-Hosters aufmacht. Nein – auch das Bewegen
eines Fahrzeugs mit jeder Menge Elektronik an Bord kann zu einem erlebnisreichen
weil fremdbestimmten Abenteuer werden.

In der Vergangheit hielt sich der Spass von poteniellen Car Hackern mehr oder minder
in Grenzen – nur wenig tatsächlich remote ausnutzbare Schwachstellen, fehlende Skalierbarkeit
der Angriffe, sehr spezifisches Know-how notwendig, bei erfolgreichem Angriff dennoch
eingeschränkter Zugriff auf Fahrzeugressourcen – alles in allem eine Gemengelage,
die nur wenige Enthusiasten und Geschäftsleute aus der Tuning-Szene zu unlauteren
Mitteln greifen lies. Auch rüsteten die OEMs teils intrinsisch, teils extrinsisch(
[UN R155](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security),
GB 44495-2024) motiviert die neuesten Elektrik/Elektronik (E/E)-Generationen ihrer
Fahrzeuge mit immer wirksameren Schutzmechanismen aus, die die Widerstandsfähigkeit
der Fahrzeugelektronik sukzessive erhöhten. Hierbei mussten die OEMs auch mit einer
gewissen Weitsicht vorgehen: Der Erfolg eines Angriffs auf ein Fahrzeug im Feld 
wird von Schutzmechanismen determiniert, die etwa 6-7 Jahre vor dem “Start of Production”(
SoP) eines Fahrzeugderivats architekturell konzipiert und sodann bei den TierX zur
Entwicklung in Auftrag gegeben wurden. Während sich also die Welt der Angriffsverktoren
aufgrund des technologischen Fortschritt stetig zu Gunsten des Angreifers fortentwickelt,
müssen die Schutzmechanismen, die schon lange vor den neuen technischen Möglichkeiten
erdacht und implementiert wurden, dennoch über den Lebenszyklus einer E/E-Generation
Bestand haben.

Klar – nicht immer bedarf es der Neuentwicklung von Schutzmechanismen – insbesondere
dann, wenn Schutzkonzepte wie state-of-the-art, security-by-design sowie security-
over-lifetime im Konzept- und Entwicklungszeitpunkt mitbedacht wurden. In der Regel
blieben dann nur noch sog. [“Black-Swan”-Ereignisse](https://de.wikipedia.org/wiki/Black_Swan_(Risiken))
wie bspw. der technologische Durchbruch in der Quantenkryptografie, um den relevanten
Entscheidungsträgern den Angstschweiß auf die Stirn zu treiben, wenn man sich über
Verluste von Deckungsbeiträgen durch Hacking unterhält.

Hierbei gehen wir freilich von Umfeldbedingungen aus, die sich zunächst einmal postiv
auf die Berücksichtigung von Security-Anforderungen im Enwicklungsprozess von E/
E-Systemen auswirken (Stichworte sind hier Diversifizierung vom Wettbewerb durch
eigene Security-Capabilities, die den Kunden ansprechen; Kostenminimierung für Fixes
im Feld durch frühzeitige Berücksichtigung der Security-Anforderungen in der Design-
und Entwicklungsphase sowie ein durch regulatorischen Druck motivierter geringer
Risikoappetit für Security-Schwachstellen).

In Zeiten der gloablen wirtschaftlichen Unsicherheit und des damit einhergehenden
Kostendrucks auch in der Fahrzeugentwicklung sieht das Bild freilich anders aus:
OEMs neigen in diesen Phasen vielleicht dazu, sich umfänglich aus dem schon bestehenden
Methoden- und Technologiebaukasten des Security-Engineerings zu bedienen, anstatt
den nächsten qualitativen Hub anzustreben. Die Gefahr hier: Zukünftige potentielle
Angriffsszenarien werden zu Gunsten kurzfristiger Rentabilität ausgeblendet, notwendige
Maßnahmen nicht in dass Fahrzeug eingebracht und die Kostenlast in die Lebensphase
des Feldbetriebs verschoben. Man kann ja später immer noch Remote Software Updates
rausschieben, um das Problem zu fixen. Es bedarf keiner hellseherischen Fähigkeiten,
um vorherzusagen, dass dieses Fixing natürlich nur dann funktioniert, wenn keine
konzeptionellen oder Hardwareänderungen erforderlich sind, um das Problem in den
Griff zu bekommen. Hardwareänderungen im Feld sind dagegen der Garant für das Inssichzusammenbrechen
jeder noch so optimistischen Rentabilitätsprognose für ein Fahrzeugderivat.

Interessant in diesem Kontext ist dabei auch die Rolle der Regulatoren und der technischen
Dienste, die die regulatorischen Vorgaben exekutieren: Wenn beispielsweise der chinesische
Regulator im GB 44495-2024 eine konkrete Anzahl von sehr spezifischen Testfällen
definiert, die ein OEM erfolgreich bestehen muss, um die notwendige Marktzulassung
für China unter dem Blickwinkel der Automotive Cybersecurity zu erhalten, kann man
darin sicher die Etablierung einer Marktzugangshürde sehen. Auf der anderen Seite
kann dies aber auch der Ausdruck einer gewissen Weitsichtigkeit des Regulators in
Bezug auf die Weiterentwicklung von Angriffspfaden in der Zukunft sein. Beispielsweise
sind [Glitching-Angriffe](https://www.darkreading.com/cyber-risk/glitching-the-hardware-attack-that-can-disrupt-secure-software)
als eine Variante der sog. Seitenkanalangriffe heute noch nicht als Allgemeingut
im Repertoire von potentiellen Angreifern angekommen. (Voltage) Glitching-Angriffe
sind hierbei eine Klasse von Hardware-Angriffen, die die Anfälligkeit elektronischer
Systeme gegenüber plötzlichen und kurzen Änderungen ihrer Stromversorgungsspannung
ausnutzen. Durch das absichtliche Einführen dieser abrupten Spannungsänderungen (“
Glitches”) zielen Angreifer darauf ab, den normalen Betrieb des Zielgeräts zu stören
und es dazu zu bringen, in kontrollierter und nachvollziehbarer Weise Fehlfunktionen
zu verursachen. Dies kann zum Umgehen von Sicherheitsmaßnahmen, zur Beschädigung
von Daten oder zur unbeabsichtigten Ausführung von Code führen. Voltage Glitching
ist besonders relevant im Kontext von eingebetteten Systemen, wie bspw. ECUs in 
Fahrzeugkomponenten. Während das Needle-Pinning mittels Pin-Probes auf Leiterplatten(
Printed Circuit Boards, PCB) in der Lebenswirklichkeit eines Red-Teams bei einem
OEM in der Vergangenheit eher in die Katergorie “Machbarkeitsstudie” fiel, bekommt
das Thema durch einige im GB 44495-2024 beschriebene Testfälle (bspw. Kap. 7.2.8
sowie 7.4.1 – 7.4.4) und deren Konkretisierung im operativen Doing durch die technischen
Dienste eine neue Relevanz: Auf einmal muss der OEM eben nicht nur das Fahrzeug 
selbst oder ausgewählte Komponenten dem technischen Dienst im Rahmen der Type Approval-
Aktivitäten zur Verfügung stellen, sondern auf Anforderung auch PCBs von bestimmten
kritischen Konponenten, auf die dann der technische Dienst mit Pin-Probes und Multimeter
losgeht. Auch wenn derzeit derartige Testaufbauten zunächst nur darauf zielen, besimmten
ECUs Antworten zu entlocken und nicht, den in Silikon gegossenen Ablauf der Informationsverarbeitung
nachzuvollziehen und ggf. zu manipulieren, ist der Weg in die Zukunft jedoch schon
vorgezeichnet. Dies gilt um so mehr dann, wann man die zukünftigen Fähigkeiten der
Fahrzeuge in den höheren Automatisierungsleveln mit berücksichtigt. Es ist also 
nur noch eine Frage der Zeit, bis sich auch das Glitching in den Testfällen bestimmter
Regulatoren wiederfindet.

Unter der Prämisse, dass OEMs weit im Vorraus Schutzmaßnahmen für die fortschreitende
E/E-Entwicklung planen und implementieren müssen, sollte dies ein Weckruf an die
Branche sein, ihre System diesbezüglich zu härten.

[Link zur englischen Version dieses Beitrags](https://smartnuts.com/2025/06/04/glitch-as-you-can/)