Fuzzing (Fuzz-Testing)

Was ist Fuzzing?

Fuzzing ist automatisiertes Negativtesten. Ein Fuzzer erzeugt ungültige, unerwartete oder zufällige Eingaben, schickt sie an das Testobjekt und beobachtet, was passiert. Das Ziel ist nicht zu prüfen, ob das System mit korrekten Eingaben das Richtige tut, sondern Eingaben zu finden, bei denen es etwas tut, was es nie tun sollte: abstürzen, hängen, neu starten, Speicher preisgeben oder einen Request annehmen, den es ablehnen müsste.

Es gibt zwei grobe Ansätze. Mutationsbasierte Fuzzer verändern gültige Nachrichten (Bits kippen, Längen ändern, Bytes anhängen). Generierungsbasierte Fuzzer bauen Nachrichten aus einem Modell des Protokolls. Beide brauchen einen Monitor, der Fehler erkennt, denn ein Fuzzer, der einen Absturz nicht von einer normalen Antwort unterscheiden kann, findet nichts.

Wo ist es definiert?

Fuzzing ist eine Methode, kein Protokoll, deshalb regelt keine Norm, wie man es macht. ISO/SAE 21434 nennt Fuzz-Testing in Kapitel 10 unter den Testmethoden der Cybersecurity-Verifikation bei Integration und Verifikation, neben Penetrationstests und Schwachstellenscans. Die Ziele sind anderswo definiert: UDS in ISO 14229-1, das ISO-TP-Framing in ISO 15765-2, CAN-Frames in ISO 11898-1.

Was es in der Praxis bedeutet

Am Steuergerät trifft Fuzzing zwei Schichten. UDS-Fuzzing schickt fehlerhafte Requests: falsche Längen, unbekannte Sub-Funktionen, überlange DID-Listen, Service IDs, die das Steuergerät nicht dokumentiert. CAN-Fuzzing schickt zufällige klassische oder FD-Frames auf die Arbitration IDs aus der DBC und zielt auf die Signal-Handler der Applikation. Der Transport ist ein eigenes Ziel: Wir sehen regelmäßig Steuergeräte, die bei fehlerhaften ISO-TP First Frames, bei einer angekündigten Länge, die nicht zum Rest passt, oder bei überlangen TransferData-Blöcken neu starten oder hängen.

Die Erkennung ist der schwierige Teil. Ein Steuergerät kann in 200 ms neu starten und danach normal antworten. Ein guter Monitor prüft nach jeder Iteration die Lebendigkeit, beobachtet die DTCs auf neue Fehlereinträge und speichert die Payload und die letzten Requests vor jedem Ausfall.

Wie AutoST es testet

AutoST fuzzt über UDS (zufällige Payloads bis 128 Bytes auf ausgewählten oder nicht standardisierten Service IDs, mit erneutem Session-Eintritt) und über CAN und CAN FD (zufällige Frames auf Arbitration IDs aus einer DBC). Jeder Lauf hat einen Seed und ist reproduzierbar. Nach jeder Iteration läuft ein TesterPresent-Liveness-Check, ein optionaler DTC-Monitor und Timeout-Erkennung ergänzen ihn, und jedes Finding speichert die Payload samt Vorgeschichte.

Häufige Missverständnisse

Fuzzing ist kein Schwachstellenscan: Ein Scan sucht bekannte Schwächen, Fuzzing sucht unbekannte. Es beweist auch nicht, dass ein Steuergerät robust ist. Ein Lauf, der in einer Stunde nichts findet, hat nur abgedeckt, was der Fuzzer in dieser Stunde gesendet hat.