Fuzzing

Was ist Fuzzing?

Fuzzing ist eine Softwaretesttechnik, die ein Programm automatisch mit unerwarteten, fehlerhaften oder halb fehlerhaften Eingaben versorgt, um Bugs, Schwachstellen und unerwartetes Verhalten zu finden, so die Definition von OWASP. Der Fuzzer erzeugt Eingaben, liefert sie aus und beobachtet das Ziel: Ein Absturz, ein Hänger, ein Reset, ein Speicherfehler oder eine falsche Antwort zeigt einen Bug, den ein menschlicher Tester von Hand selten erreicht hätte.

Fuzzer unterscheiden sich darin, wie sie Eingaben erzeugen. Mutationsbasierte Fuzzer nehmen gültige Beispiele und kippen, fügen ein und löschen Bytes. Generierungsbasierte oder protokollbewusste Fuzzer bauen Eingaben aus einem Modell des Formats oder Protokolls, kommen so an der ersten Längenprüfung vorbei und erreichen tieferen Code. Coverage-geführte Fuzzer wie AFL++ oder libFuzzer instrumentieren das Programm, behalten Eingaben, die neuen Code erreichen, und mutieren von dort weiter; sie sind am wirksamsten, wo der Code mit Instrumentierung kompiliert werden kann. Für ein Gerät auf dem Prüfstand, dessen Code sich nicht instrumentieren lässt, ist protokollbewusstes Fuzzing mit sorgfältiger Fehlererkennung der gangbare Weg.

Wo ist es definiert?

Keine Norm definiert Fuzzing selbst, aber mehrere verlangen oder empfehlen es. ISO/SAE 21434 nennt Fuzz-Tests zusammen mit Funktionstests, Schwachstellenscans und Penetrationstests unter den Methoden der Cybersecurity-Verifikation in der Produktentwicklung (Klausel 10). IEC 62443-4-1 führt es innerhalb der Praktik zu Security-Verifikation und -Validierung für Industriekomponenten. Der Cyber Resilience Act verlangt in Anhang I Teil II, dass Hersteller wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts mit digitalen Elementen durchführen. Cybersecurity-Anforderungen von OEMs an Zulieferer verlangen zunehmend Fuzzing-Berichte als Nachweis.

Was es in der Praxis bedeutet

Fuzzing ist eine der Kerntätigkeiten von Zyberum und die Grundlage unseres Produkts AutoST. Auf Embedded-Zielen ist das Schwierige nicht, Eingaben zu erzeugen, sondern zu sehen, was sie bewirkt haben. Ein Server stürzt sichtbar ab; ein Steuergerät resettet still, verliert eine Diagnose-Session oder antwortet auf einen Dienst nicht mehr, während alles andere weiterläuft. Wir instrumentieren deshalb die Umgebung statt des Codes: einen Heartbeat wie UDS TesterPresent, Überwachung von Reset-Leitungen oder Stromaufnahme, einen Debugger, wo einer verfügbar ist, und den Vergleich jeder Antwort mit dem erwarteten Verhalten.

Wo wir es einsetzen:

• Diagnose- und Fahrzeugprotokolle: UDS über CAN und DoIP, ISO-TP-Segmentierung, SOME/IP und seine Service Discovery. Protokollbewusstes Fuzzing dieser Stacks auf Leistungselektronik-Steuergeräten hat Parser gefunden, die das Steuergerät bei bestimmten fehlerhaften Längen und Sequenzen resetten. Mit der Diagnosedatenbank (ODX oder CDD) fuzzen wir genau die Identifier und Routinen, die existieren, was weit effizienter ist als zufällige Bytes.
• Infotainment-Plattformen: Kernel- und Treiberschnittstellen auf Embedded Linux und Android sowie die Schnittstelle zwischen Normal World und Trusted Execution Environment, wo ein Absturz in einer Trusted Application mehr zählt als irgendwo sonst im System.
• IoT-Geräte: MQTT-Broker, proprietäre Funkprotokolle, Bluetooth-Stacks und Firmware-Update-Parser.

Ein Fuzzing-Ergebnis ist ein Ausgangspunkt, kein Finding. Jeder Absturz wird reproduziert, auf die kürzeste Eingabe minimiert und in der Firmware analysiert, um zu entscheiden, ob es ein Denial of Service ist, eine Speicherkorruption, die zu Codeausführung werden könnte, oder ein harmloser Watchdog-Reset. Der Bericht nennt diese Einschätzung, die Reproduktionsschritte und den Fix.

Häufige Missverständnisse

Fuzzing findet nicht alles: Logikfehler, schwache Authentifizierungsdesigns und fehlende Zugriffskontrolle sind für den Fuzzer unsichtbar. Deshalb ergänzt es einen Penetrationstest, statt ihn zu ersetzen. Zufällige Bytes sind auf einem Protokoll mit Prüfsummen und Längenfeldern kein sinnvolles Fuzzing; der Fuzzer muss das Protokoll kennen. Und ein Fuzzer, der null Abstürze meldet, hat nichts gezeigt, solange du nicht weißt, was er abgedeckt hat. Abdeckung, nicht Laufzeit, ist das Maß.