Tutorial zum Fuzz-Testen (Fuzzing).

Was ist Fuzz-Test?

Fuzz-Testing oder Fuzzing Fuzz-Testing ist eine Softwaretestmethode, bei der ungültige oder zufällige Daten, sogenannte Fuzz-Daten, in ein Softwaresystem eingeschleust werden, um Programmierfehler und Sicherheitslücken aufzudecken. Ziel des Fuzz-Testings ist es, Daten mithilfe automatisierter oder halbautomatisierter Verfahren einzufügen und das System auf verschiedene Ausnahmen wie Systemabstürze oder Fehler im integrierten Code zu testen.

Fuzz-Testing wurde ursprünglich von Barton Miller an der University of Wisconsin–Madison entwickelt. Er prägte den Begriff, nachdem Leitungsrauschen in einer Modemverbindung die von ihm verwendeten Programme zum Absturz brachte. Seine Studenten setzten die ersten Fuzzer 1989 ein und stellten fest, dass etwa ein Drittel der getesteten UNIX-Dienstprogramme abstürzten oder sich aufhängten. Fuzz-Testing ist ein Softwaretest Technik, und es ist eine Art von Sicherheitstests.

Das untenstehende Diagramm zeigt die grundlegende Fuzzing-Schleife, in der generierte Daten an die zu testende Anwendung gesendet und die Reaktion beobachtet werden.

Warum Fuzz-Tests durchführen?

Fuzzing ist ein wichtiger Bestandteil von Testplänen, da es Eingaben untersucht, für die bisher niemand einen Testfall geschrieben hat. Die wichtigsten Gründe für die Anwendung durch Teams sind unten aufgeführt.

• Beim Fuzz-Testing werden in der Regel die schwerwiegendsten Sicherheitsfehler und -mängel aufgedeckt, da ein Absturz ein direkter Beweis für einen nicht behandelten Eingabepfad ist.
• Fuzz-Testing liefert effektivere Ergebnisse, wenn es mit Schwarz Box Tests, Betatests und andere Debugging-Methoden.
• Fuzz-Testing wird verwendet, um die Schwachstellen von Software zu überprüfen, und es ist eine sehr kosteneffektive Testmethode, da die Eingaben generiert und nicht manuell geschrieben werden.
• Fuzz-Testing ist eine der Black-Box-Testmethoden. Fuzzing ist auch eine der gängigsten Methoden, mit denen Hacker Schwachstellen in einem System aufspüren. Daher wird Angreifern durch die vorherige Durchführung des Tests der einfachste Zugang verwehrt.

Arten von Fuzz-Tests

Fuzzer werden üblicherweise danach gruppiert, wie viel sie über das zu testende Programm wissen. Je mehr der Fuzzer weiß, desto tiefer kann er in den Code eindringen.

Typ	Was der Fuzzer weiß	Typische Verwendung
Black-Box-Fuzzing	Es gibt keine Informationen über die internen Abläufe; es erfasst nur Ein- und Ausgänge.	Quick Smoke testet eine Binärdatei oder einen aktiven Endpunkt.
Weißbox-Fuzzing	Vollständiger Quellcode, oft kombiniert mit symbolischer Ausführung, um schwer erreichbare Verzweigungen zu lösen.	Tiefgehende Analyse einer Komponente, deren Quellcode verfügbar ist.
Graubox-Fuzzing	Keine Quellcodeprüfung, sondern Laufzeit-Feedback, z. B. welche Codezweige eine Eingabe erreicht.	Der Standardwert für moderne Engines wie AFL++ und libFuzzer.

Eine zweite, ältere Spaltung trennt dummes Fuzzing ab intelligentes FuzzingEin einfacher Fuzzer manipuliert Bits, ohne das Eingabeformat zu kennen, sodass die meisten seiner Daten vom ersten Parser verworfen werden. Ein intelligenter Fuzzer hingegen versteht Prüfsummen, Längenfelder und die Nachrichtenstruktur, sodass seine Eingaben die Validierung überstehen und die zugrundeliegende Logik erreichen. Abdeckungsgesteuertes Fuzzing ist die Grey-Box-Verfeinerung, die das Fuzzing massentauglich gemacht hat: Die Engine instrumentiert die Binärdatei, behält alle Eingaben bei, die einen neuen Zweig erreichen, und mutiert die Überlebenden, sodass sich der Korpus stetig in Richtung unerforschten Codes entwickelt, anstatt von zufälligem Rauschen neu zu starten.

So führen Sie Fuzz-Tests durch

Die Schritte für Fuzz-Testing umfassen die grundlegenden Testschritte:

Schritt 1) ​​Identifizieren Sie das Zielsystem — Wählen Sie die Binärdatei, Bibliothek, den Dienst oder den Protokollendpunkt aus, der angegriffen werden soll, und bestätigen Sie, dass Sie berechtigt sind, ihn zu testen.

Schritt 2) Identifizieren Sie die Eingaben — Listet alle Einstiegspunkte auf, von denen das Ziel liest: Dateien, Befehlszeilenargumente, Umgebungsvariablen, Netzwerkpakete, Formularfelder und API-Nutzdaten.

Schritt 3) Fuzzed-Daten generieren — fehlerhafte Eingaben erzeugen, indem gültige Beispiele verändert werden, indem sie aus einem Modell des Formats generiert werden oder indem beides kombiniert wird.

Schritt 4) Führen Sie den Test mit Fuzzy-Daten durch. — Führen Sie das Ziel mit den generierten Eingaben aus, idealerweise in einer Schleife, die den Prozess nach jedem Fehler automatisch neu startet.

Schritt 5) Überwachen Sie das Systemverhalten — Achten Sie auf Abstürze, Hänger, Assertionsfehler, übermäßige Speichernutzung und Sanitizer-Berichte, anstatt nur die gedruckte Ausgabe zu überprüfen.

Schritt 6) Fehler protokollieren — Speichern Sie die exakte Eingabe, die jeden Fehler ausgelöst hat, reduzieren Sie sie auf den kleinsten reproduzierbaren Fall und fügen Sie sie dem Stapel hinzu. trace beigefügt.

Beispiele für Fuzzer

Fuzzer werden auch danach klassifiziert, wie sie ihre Eingabe erstellen, und die drei unten aufgeführten Ansätze sind diejenigen, denen Sie am häufigsten begegnen werden.

• Mutationsbasierte Fuzzer Vorhandene Datenbeispiele werden verändert, um neue Testdaten zu erzeugen. Dies ist ein sehr einfacher und unkomplizierter Ansatz: Man beginnt mit gültigen Beispielen eines Protokolls und verändert dann jedes Byte oder jede Datei.
• Generationsbasierte Fuzzer Neue Daten werden auf Basis der Modelleingaben definiert. Sie beginnen, Eingaben von Grund auf anhand der Spezifikation zu generieren.
• Protokollbasierte Fuzzer Die Tests setzen detaillierte Kenntnisse des zu testenden Protokollformats voraus, die aus der Spezifikation stammen. Dazu wird ein Array der Spezifikation in das Tool geschrieben. Anschließend wird mithilfe eines modellbasierten Testgenerierungsverfahrens die Spezifikation durchlaufen und Unregelmäßigkeiten in den Dateninhalten, der Datenreihenfolge usw. hinzugefügt. Dies wird auch als Syntaxtest, Grammatiktest oder Robustheitstest bezeichnet. Ein Fuzzer kann Testfälle aus bestehenden Testfällen generieren oder gültige bzw. ungültige Eingaben verwenden.

Beim protokollbasierten Fuzzing gibt es zwei Einschränkungen:

1. Die Tests können erst fortgesetzt werden, wenn die Spezifikation ausgereift ist.
2. Viele nützliche Protokolle sind eine Erweiterung veröffentlichter Protokolle. Wenn Fuzz-Tests auf veröffentlichten Spezifikationen basieren, Testabdeckung für neue Protokolle wird begrenzt sein.

Die einfachste Form des Fuzzing besteht darin, der Software zufällige Eingaben zu senden, entweder als Protokollpakete oder als Ereignis. Diese Technik ist sehr effektiv, um Fehler in vielen Anwendungen und Diensten aufzuspüren. Es gibt auch andere Techniken, die sich leicht implementieren lassen. Dazu müssen lediglich die vorhandenen Eingaben verändert werden, beispielsweise durch einfaches Vertauschen ihrer Bits.

Von Fuzz Testing erkannte Fehlertypen

Da beim Fuzzing ein Programmlauf anhand des tatsächlichen Programmverhaltens und nicht anhand eines Erwartungswerts beurteilt wird, lassen sich die dabei aufgedeckten Fehler in drei Gruppen einteilen.

• Assertionsfehler und Speicherlecks: Diese Methodik wird häufig für große Anwendungen eingesetzt, bei denen die Fehler die Speichersicherheit beeinträchtigen, was eine schwerwiegende Schwachstelle darstellt. Buffer Überläufe, Verwendung nach Freigabe und Lesezugriffe außerhalb des zulässigen Bereichs treten alle hier auf.
• Ungültige Eingabe: Beim Fuzz-Testing werden Fuzzer eingesetzt, um ungültige Eingaben zu generieren, die zum Testen von Fehlerbehandlungsroutinen verwendet werden. Dies ist wichtig für Software, die ihre Eingaben nicht kontrolliert. Einfaches Fuzzing kann als eine Möglichkeit zur Automatisierung angesehen werden. negative Prüfung.
• Korrektheitsfehler: Fuzzing kann auch zur Erkennung bestimmter Arten von Fehlern eingesetzt werden, die die Korrektheit betreffen, wie beispielsweise eine beschädigte Datenbank oder fehlerhafte Suchergebnisse. Differenzielles Fuzzing, bei dem zwei Implementierungen dieselben Eingaben erhalten und die Ergebnisse verglichen werden, ist die übliche Methode, um solche Fehler aufzuspüren.

Fuzz-Testtools

Tools, die in der Websicherheit eingesetzt werden, können auch beim Fuzz-Testing verwendet werden, wie zum Beispiel Burp Suite und Peach Fuzzer. Einige der unten aufgeführten klassischen Namen sind mittlerweile archiviert, daher wird ihr aktueller Status neben jedem Eintrag angegeben.

• Pfirsich FuzzerPeach Fuzzer bietet einen umfassenderen Sicherheitsschutz als ein Scanner. Andere Testwerkzeuge können nur nach bekannten Bedrohungen suchen, während Peach Fuzzer es Benutzern ermöglicht, sowohl bekannte als auch unbekannte Bedrohungen zu finden. Peach Tech wurde von GitLab übernommen, und die Community Edition v3 wird nicht mehr weiterentwickelt; der Nachfolger ist die GitLab Protocol Fuzzer Community Edition.
• Spike-ProxySPIKE Proxy ist ein professionelles Tool, das nach Sicherheitslücken auf Anwendungsebene in Webanwendungen sucht. Es deckt die Grundlagen ab, wie zum Beispiel: SQL Injection und Cross-Site-Scripting auf einer völlig offenen Plattform Python Infrastruktur, und sie war verfügbar für Linux und WindowsEs wurde seit vielen Jahren nicht mehr gepflegt und wird hier nur aus historischen Gründen aufgeführt.
• WebScarabWebScarab ist geschrieben in Java WebScarab ist daher auf vielen Plattformen einsetzbar. Das Framework kommuniziert über HTTP- und HTTPS-Protokolle und fungiert als abfangender Proxy: Es ermöglicht dem Benutzer, Browseranfragen zu prüfen und zu modifizieren, bevor sie den Server erreichen, und Serverantworten zu prüfen und zu aktualisieren, bevor sie den Browser erreichen. Jede von WebScarab gefundene Sicherheitslücke wird der Liste der gemeldeten Probleme hinzugefügt. Das Repository wurde im April 2024 archiviert und ist nun schreibgeschützt.
• OWASP WSFuzzerWSFuzzer ist ein unter der GPL lizenziertes Programm, das in [Sprache/Architektur] geschrieben wurde. Python das auf Webdienste abzielte und in seiner letzten Version HTTP-basiert war SOAP-Dienste waren das Hauptziel. Es wurde als Teil von WebScarab ausgeliefert und zusammen mit diesem eingestellt; OWASP ZAP und sein Fuzzer-Add-on sind der empfohlene Ersatz.
• Beibehaltene Alternativen: AFL++ und libFuzzer sind die standardmäßigen, abdeckungsbasierten Engines für nativen Code. OSS-Fuzz führt sie kontinuierlich und kostenlos für Open-Source-Projekte aus, und Boofuzz behandelt Netzwerkprotokoll-Fuzzing in PythonEine ausführlichere Liste findet sich im Leitfaden zu Tools für Sicherheitstests.

Fuzz-Testing: Bewährte Verfahren

Ein Fuzzer, der einfach auf ein Zielsystem gerichtet und sich selbst überlassen wird, findet selten viel. Die folgenden Vorgehensweisen unterscheiden eine Kampagne, die zu gemeldeten Fehlern führt, von einer, die lediglich Rechenzeit verbraucht.

• Beginnen Sie mit einem guten Ausgangskorpus. Sammeln Sie echte, gültige Eingaben, die die Anwendung bereits akzeptiert. Das Verändern einer gültigen Datei erreicht den Parsing-Code wesentlich schneller als das Verändern zufälliger Bytes.
• Entwerfen Sie ein kleines, schnelles Geschirr. Der Einstiegspunkt sollte pro Durchlauf genau eine Sache erledigen, Netzwerkaufrufe und Festplattenschreibvorgänge vermeiden und schnell zurückkehren, da der Durchsatz in Ausführungen pro Sekunde gemessen wird.
• Desinfektionsmittel einschalten. Stille Speicherbeschädigung führt oft nicht zu einem Absturz. AddressSanitizer und UndefinedBehaviorSanitizer wandeln sie in einen sofortigen, diagnostizierbaren Fehler um.
• Läufe lange und laufe ununterbrochen. Ein ein- oder zweistündiger Testlauf deckt oberflächliche Fehler auf; tieferliegende Fehlerpfade benötigen in der Regel viele Stunden. Deshalb gehört Fuzzing eher in einen nächtlichen CI-Job als in eine manuelle Sitzung.
• Minimiere und dedupliziert jeden Absturz. Reduziere die fehlerhafte Eingabe auf ihre kleinste Form und gruppiere Abstürze nach Stapel. tracAndernfalls würde ein Fehler zu Hunderten von Tickets führen.
• Führen Sie einen Regressionskorpus. Füge jeden reproduzierenden Input einem permanenten Satz hinzu, der bei jedem Build ausgeführt wird, damit ein behobener Fehler nicht unbemerkt wieder auftreten kann.
• Das Ziel muss legal anvisiert werden. Das Fuzzing eines laufenden Drittanbieterdienstes ohne schriftliche Genehmigung ist von einem Angriff nicht zu unterscheiden.

Vorteile des Fuzz-Tests

Bei realistischen Erwartungen bietet Fuzzing einen Mehrwert, den andere Techniken nur schwer erreichen.

• Fuzz-Testing verbessert die Software-Sicherheitstests.
• Die beim Fuzzing gefundenen Fehler sind manchmal gravierend und oft dieselben, die auch von Angreifern ausgenutzt werden, darunter Abstürze, Speicherlecks und unbehandelte Ausnahmen.
• Falls Fehler aufgrund von Zeit- und Ressourcenmangel von den Testern nicht bemerkt werden, werden diese Fehler auch beim Fuzz-Testing gefunden.
• Die Eingaben werden von einer Maschine generiert, sodass die Abdeckung über Nacht ohne zusätzlichen manuellen Aufwand stetig wächst.

Nachteile des Fuzz-Tests

Die gleichen Eigenschaften, die das Fuzzing kostengünstig machen, begrenzen auch, was es beweisen kann.

• Fuzz-Testing allein kann kein vollständiges Bild einer gesamten Sicherheitsbedrohung oder einer Reihe von Fehlern liefern.
• Fuzz-Testing ist weniger effektiv bei der Bekämpfung von Sicherheitsbedrohungen, die keine Programmabstürze verursachen, wie beispielsweise einige Viren, Würmer und Trojaner.
• Fuzz-Testing kann nur relativ einfache Fehler oder Bedrohungen aufdecken und berücksichtigt keine Geschäftslogik.
• Für eine effektive Durchführung ist ein erheblicher Maschineneinsatz erforderlich.
• Die Festlegung einer Randwertbedingung bei zufälligen Eingaben ist sehr problematisch, obwohl Tester dies mittlerweile größtenteils mit deterministischen, benutzergesteuerten Algorithmen lösen.

Fuzz-Testing vs. Penetrationstesting

Beide Aktivitäten suchen nach Sicherheitslücken, beantworten aber unterschiedliche Fragen und sind selten austauschbar.

Eigenschaften	Fuzz-Tests	Penetrationstests
Angetrieben durch	Ein automatisierter Motor, der fehlerhafte Eingaben erzeugt	Ein erfahrener Tester, der über das System nachdenkt.
Schaut nach	Abstürze, Hänger und Speichersicherheitsfehler	Ausnutzbare Schwachstellen, einschließlich Logik- und Konfigurationsfehler
Tiefe	Sehr breite Eingabeabdeckung, oberflächliches Denken	Enger Themenbereich, tiefgründige Argumentation
Ausgang	Eingaben und Stack reproduzieren traces	Ein Ergebnisbericht mit Exploit-Pfaden und Risikobewertungen
bester Moment	Kontinuierlich in der Build-Pipeline	In regelmäßigen Abständen, gegen einen Release-Kandidaten

In der Praxis ergänzen sich die beiden Ansätze: Durch das Fuzzing werden die billigen, automatisierbaren Abstürze beseitigt, sodass die begrenzte Zeit eines Testers für die Fehler genutzt werden kann, die nur ein Mensch erkennen kann.

Häufig gestellte Fragen