Fuzzing vs. Schwachstellenscan am Steuergerät: Was welche Methode findet

Was ist der Unterschied?

Ein Schwachstellenscan schickt dem Steuergerät Requests, die es versteht, und liest die Antworten. 10 03, um die Extended Session zu öffnen, 22 F1 90, um die VIN zu lesen, 27 01, um einen Seed anzufordern, jeden Service Identifier in jeder Session, und das Steuergerät antwortet positiv oder mit einem Negative Response Code aus ISO 14229-1 Anhang A. Der Scan interpretiert diese Codes: 0x7F sagt, der Service existiert in einer anderen Session, 0x33 sagt, er liegt hinter SecurityAccess, 0x31 sagt, der Identifier ist unbekannt. Die Schwächen, die er findet, drehen sich um das Erlaubte: ein Service ohne Session-Wechsel erreichbar, eine schreibbare Identifikations-DID, ein Seed/Key-Tor ohne Versuchszähler, eine XCP-Schnittstelle, die niemand anlassen wollte.

Fuzzing schickt dem Steuergerät Eingaben, die es nicht erwartet. Ein ReadDataByIdentifier mit 120 Bytes Payload, ein ISO-TP First Frame, der 4.000 Bytes ankündigt und nie liefert, zufällige Service Identifier, ein TransferData-Block mit dreifacher vereinbarter Größe, zufällige CAN-Frames auf den Arbitration-IDs aus deiner DBC. Dann beobachtet es: Antwortet das Steuergerät noch auf TesterPresent, hat sich die DTC-Zahl geändert, ist eine Antwort ausgeblieben. Die Schwächen, die es findet, drehen sich um den Bau des Steuergeräts: Pufferbehandlung, Längenprüfungen, Zustandsmaschinen, die hängen bleiben, Watchdog-Resets.

Beides ist automatisiert. Der Unterschied ist die Frage: “Ist das erlaubt?” gegenüber “Geht das kaputt?”.

Nebeneinander

	Schwachstellenscan (Enumeration und Prüfungen)	Fuzzing
Findet	Services in der falschen Session, lesbare und schreibbare DIDs, fehlende SecurityAccess-Zähler und -Verzögerungen, konstante Seeds, offenes XCP/CCP, DoIP-Routing zu gesperrten Steuergeräten, offene SOME/IP-Services	Resets und Hänger bei fehlerhaften ISO-TP-Frames, Crashes bei überlangen Payloads, Services, die nicht mehr antworten, Fehlercodes durch schlechte Eingaben, Parser-Fehler in der CAN-Signalverarbeitung
Übersieht	Implementierungsfehler in Parsern und Stacks; alles, was nur ungültige Eingaben auslösen	Zugriffs- und Designschwächen; ein perfekt robustes Steuergerät mit schreibbarer Seriennummer besteht jeden Fuzzing-Lauf
Wer macht es	Test-Engineers aus dem Dashboard; liest und klassifiziert	Test-Engineers aus dem Dashboard; braucht einen Rückweg für das Steuergerät
Prüfstandszeit	Minuten pro Session; etwa zehn Minuten pro Session für einen vollständigen DID-Durchlauf	Stunden pro Kampagne; ein kurzer Lauf pro Build, ein langer pro Release
Kosten	Teil der AutoST-Lizenz pro Komponente; freie Tools gibt es	Teil der AutoST-Lizenz pro Komponente; freie Fuzzer gibt es, aber Reproduzierbarkeit und Crash-Erkennung sind dann deine Aufgabe
Passt in den Release-Zyklus	Ja, schnell genug für jeden Build	Ja mit geseedeter, begrenzter Kampagne; ein langer Lauf gehört auf den Release-Branch
Verlangt von	ISO/SAE 21434 [RC-10-12] empfiehlt Schwachstellen-Scans für Komponententests; UN R155 verlangt Tests der umgesetzten Maßnahmen	ISO/SAE 21434 [RC-10-12] empfiehlt Fuzz-Testing; in der Praxis ab CAL 2 für Kommunikationsschnittstellen erwartet
Ergebnis	Eine Karte von Sessions, Services und DIDs mit Risiko-Flags und einem Score von 0 bis 10; PDF und SARIF	Findings mit Iteration, Payload, Monitor und Payload-Historie, per Seed wiederholbar; PDF und SARIF

Nimm den Schwachstellenscan, wenn

• du das Steuergerät zum ersten Mal siehst. Die Enumeration ist nicht-destruktiv und sagt dir, was da ist, bevor du irgendetwas darauf wirfst.
• die Frage Konfiguration ist: Hat der Zulieferer die Programming Session gesperrt, ist der Identifikationsbereich nur lesbar, sperrt SecurityAccess nach drei falschen Keys. Das sind die Findings, die wir an echten Prüfständen am häufigsten sehen, und keines davon braucht Fuzzing.
• das Steuergerät teuer oder schwer wiederherzustellen ist. Ein reiner Lesescan ändert keinen Zustand; Fuzzing kann das.
• du ein Ergebnis in Minuten brauchst, zum Beispiel als Gate bei jedem Build.

Nimm Fuzzing, wenn

• das Steuergerät komplexe Eingaben parst: Multi-Frame-ISO-TP, TransferData-Blöcke, DoIP-Nachrichten, SOME/IP-Payloads, DBC-definierte Signale mit Prüfsummen und Zählern. Dort wohnen Längen- und Zustandsfehler.
• es Feldrückläufer oder Vorfälle auf Testfahrten gab, bei denen Steuergeräte resetteten oder verstummten und niemand es reproduzieren konnte. Ein geseedeter Fuzzer mit Payload-Historie ist der Weg, so etwas zu finden.
• das Steuergerät CAL 2 oder höher hat und dein Assessor nach Fuzz-Tests der Kommunikationsschnittstellen fragen wird, wie [RC-10-12] es empfiehlt.
• das Steuergerät jeden Scan bestanden hat. Eine saubere Karte sagt nichts über Robustheit.

Beides zusammen

Es sind zwei Hälften des Komponententests, und ISO/SAE 21434 nennt sie in einem Satz. Die praktische Reihenfolge ist: erst scannen, dann fuzzen. Die Enumeration gibt dem Fuzzer seine Ziele (die Sessions, die sich öffnen, die Services, die antworten, die DIDs, die Schreibzugriffe annehmen) und sagt dir, was du ausschließen musst, damit du das Steuergerät nicht in Iteration eins resettest. In AutoST laufen beide von derselben Komponente aus und landen im selben Fix Plan, sodass eine schreibbare DID und ein Crash auf demselben Service als das erscheinen, was sie sind: zwei Findings auf einer Angriffsfläche.

Keines von beiden findet Logikfehler oder verkettete Angriffe. Dafür, und für den Seed/Key-Algorithmus selbst, brauchst du weiterhin einen Menschen, der die Firmware liest.