What’s all the fuzz about?

2 Code Intelligence GmbH

Fuzzing ist ein leistungsfähiges Werkzeug, um Programmierfehler zu finden. Mit der Hilfe von Fuzzing können Hacker Schwachstellen aufdecken und als Angriffspunkt ausnutzen. Unternehmen können gefundene Sicherheits­lücken schließen, die Sicherheit ihrer Software erhöhen und die Code­qualität ihrer Anwendungen verbessern. Die Technologie gibt es schon seit 1989 (Prof. Barton Miller) hat allerdings erst in den letzten Jahren mit sei ner Weiterentwicklung (2016 AFL) und den zunehmenden finanziellen Schäden durch Sicherheitslücken in Software an Relevanz gewonnen. Nicht nur Unternehmen setzten die Technologie ein, um Sicherheitsrisiken zu mi nimieren auch Hacker nutzen sie zur Identifizierung von Schwachstellen. In einer Zeit, in der jeder auf mächtige Computerressourcen zurück greifen kann, ist es zu einem unverzichtbaren Werkzeug im Rüstungswettlauf zwi schen Hackern und Sicherheitsexperten geworden. Trotz seiner Rele vanz im Testing Prozess ist der Begriff Fuzzing vielen noch nicht geläufig.

Definition Fuzzing

Fuzzing ist eine Methode zum Testen von Software, mit der Programmierfehler und Sicherheits­

lü cken in Anwendungen, Betriebssystemen und Netzwerken gefunden werden können. Beim

Fuzzing werden unerwartete Eingaben an die zu testende Software gesendet, um Ausfälle und

fehler haftes Verhalten zu verursachen. Das erzeugte Fehlverhalten, wird auf seine Ursache hin

untersucht und behoben, um Zuverlässigkeit und Sicherheit zu gewährleisten.

What’s all the fuzz about?

3 Code Intelligence GmbH

Fuzz­Tests oder Fuzzing ist eine Software Testing Methode, welche Fehler im Quellcode aufdecken kann. Mit der Hilfe von Fuzzing können Robustheits­ und Sicherheitsprobleme entdeckt werden. Im Folgenden wird Fuzzing im Kontext des Software Testings näher erläutert.

Fuzzing im Kontext des Software Testings

Black­Box­, White­Box­ und Grey­Box­Tests Diese Begriffe beschreiben, welche Art von Information über die zu testende Soft­ware vorliegt bzw. im Testprozess verwendet wird.

Black-Box-Test: Beim Black­Box­Test beschränkt sich der Test­prozess auf die Beobachtung des Verhaltens des Inputs und Outputs des Systems. Der interne Betrieb des Systems bleibt völlig undurchsichtig. So können Anwendungen getestet werden, bei denen der Quellcode nicht einsehbar ist.

White-Box-Test: White­Box­Tests haben im Gegensatz zu Black­Box­Tests vollen Zugriff auf den Quellcode und die Designspezifikationen der zu testenden Software, was einen besseren Einblick in die Funktionsweise des Systems ermöglicht. Diese Informationen erhöhen oftmals die Effizienz des Testing­ Prozesses und ermöglichen es Fehler und Schwachstellen im Quellcode zu finden. White­Box­Tests machen sich sowohl statische, wie dynamische Codeanalyse zu Nutze.

Grey-Box-Test: Grey­Box­Tests stellen die Testing Methoden dar, welche zwischen Black­ und White­Box­Testing liegen. Diese Tools interagieren mit der zu testenden Software über externe Schnittstellen, nutzen aber auch den Quellcode für zusätzliche Erkenntnisse.

Statische und dynamische CodeanalyseSoftware wird sowohl mit statischen als auch mit dynamischen Testtechniken untersucht. Um das Risiko auf das gewünschte Niveau zu senken, sollte eine Kombination aus beiden Techniken genutzt werden.

4 Code Intelligence GmbH

Statische Codeanalyse: Die statische Codeanalyse ist generell in der Lage die gängigsten Fehlertypen, wie z.B. SQL Injection oder API­Fehlbenutzungen, gut zu er­kennen. Bei der statischen Analysetechnik (z.B. Fortify, Coverty) wird das Programm untersucht, ohne es auszuführen. Durch den Einsatz von Heuristiken zur Erkennung von Schwachstellen, kann der gesamte Quelltext leicht überprüft werden. Ein großer Vorteil ist es, dass der Programmcode nicht erst in Maschinensprache übersetzt werden muss, sondern direkt analysiert werden kann. Die statische Programm­analyse hat in den letzten Jahren enorme Fortschritte gemacht. Dennoch stoßen rein statische Schwachstellenanalysen systembedingt an ihre Grenzen, sobald das Vorhandensein einer Schwachstelle von Faktoren abhängt, die statisch nicht zu bestimmen sind. Dies betrifft insbesondere Abhängigkeiten von Programm­eingaben (beispielsweise durch Nutzerschnittstellen oder Eingabedateien) und von Konfigurations parametern in der Ausführungsumgebung. In der statische Analyse kommt es oft zu unnötigen und falschen Warnungen (false­positives). Eine hohe An­zahl solcher Warnungen ist problematisch, da false­positives Entwickler nicht nur demotivieren, sondern auch von den korrekten und daher wichtigen Warnungen ab­lenken.

Dynamische Codeanalyse: Die dynamische Codeanalyse unterscheidet sich von der statischen, da das Programm während der Überprüfung ausgeführt wird. Realistische Fehler und Schwachstellen können so erkannt werden. Die zu testende Software wird kontrolliert ausgeführt und mit systematisch festgelegten Eingabe­daten getestet. Nicht nur die Eingabedaten sind festgelegt auch die zu erwartenden Ausgabedaten werden vor Testbeginn definiert. Entsprechen die Vorhersagen nicht den tatsächlichen Resultaten, liegt ein Fehler vor. Der Tester ist in der Lage den Fehler zu reproduzieren und zu beheben. Wesentliche Aufgabe der einzelnen dynamischen Verfahren ist die Bestimmung geeigneter Testfälle und die manuelle Auswertung von Abweichungen. Die dynamische Codeanalyse erzeugt dadurch einen hohen manuellen Aufwand, der ineffizient ist und langfristig nicht zu sicheren und zuverlässigen Ergebnissen führt.

Was ist Fuzzing?Fuzzing ist eine dynamische Testing Methode zur Erkennung von Fehlern und Schwachstellen in Software. Im Gegensatz zur statischen Analyse, hat Fuzzing den großen Vorteil, keine False­Positives zu produzieren. Fuzzing ist in der Lage White­ Box­, Black­Box­ oder Grey­Box­Testing durchzuführen. Diese Flexibilität macht Fuzzing zu einem äußerst nützlichen Werkzeug zum Testen von Software, un abhängig von der Verfügbarkeit von Quellcode oder detaillierten internen Informationen.

5 Code Intelligence GmbH

Als Black­Box­Technik ist das Fuzzing für jeden nützlich, der die Robustheit und Zu­verlässigkeit der Systeme, die er betreibt oder einzusetzen plant verstehen möchte.Doch was passiert beim Fuzzing? Beim Fuzzing werden unerwartete Eingaben an die zu testende Software gesendet, um Ausfälle und fehlerhaftes Verhalten zu ver­ursachen. Das erzeugte Fehlverhalten wird auf seine Ursache hin untersucht und diese können behoben werden, um Zuverlässigkeit und Sicherheit zu gewähr leisten. Verursachen die erzeugten Eingaben kein Fehlverhalten werden neue Eingaben generiert, welche von den vorherigen Eingaben abgeleitet sein können. Software Lösungen, welche die Fuzzing Methode einsetzen nennt man Fuzzer. Ein Fuzzer, welcher diese Generierung bspw. ausführt, ist Radamsa.

Im Jahr 2016 verbesserte der amerikanische Fuzzy Lop (AFL) das Fuzzing, indem er die Code Abdeckung bei der Generierung neuer Eingaben berücksichtigte. Daher können AFL und andere coverage­based­Fuzzer weitaus mehr Teile eines Programms durchlaufen, als es zuvor der Fall war. Die nächste große Verbesserung im Bereich der Fuzzings kam in Form von Sanitizern. Sanitizer ermöglichen es ver­schiedene Fehlerarten zu erkennen und nicht nur, wie in der Vergangenheit, Abstürze zu registrieren. Der Address­Sanitizer überwacht beispielsweise den Speicherzugriff ähnlich wie valgrind (viel schneller), während der Thread­Sanitizer auf Laufzeit­bedingungen zwischen mehreren Thread achtet. Das Betreiben von Sanitizern mit Fuzzern wurde mit dem Aufkommen von libfuzzer, einem in LLVM eingebetteten Fuzzing­Motor, noch praktischer gestaltet, da die großen Anforderungen an den virtuellen Speicher des Address­Sanitizer intelligent umgesetzt wurden. Kurz gesagt die Kombination der Erkennung von Codeabdeckung mit Sanitizern ist das, was wir modernes Fuzzings nennen. Die Analysetechnik erlaubt es, Software kontinuierlich und zielsicher hinsichtlich realer Schwachstellen zu überprüfen.

6 Code Intelligence GmbH

Im Folgenden werden die verschiedenen Arten des Fuzzings erläutert, die Anatomie eines Fuzzers erklärt und die Vor­ und Nachteile von Fuzzing im Entwicklungsprozess vorgestellt. Des Weiteren wird darauf eingegangen, wie Unternehmen langfristig vom Einsatz profitieren können und wie sie noch heute die komplexe Technologie auch ohne IT­Security­Expertise einsetzen können.

Fuzzing

Arten des FuzzingsFuzzer können wie folgt kategorisiert werden:

Dumb Fuzzing: Ein Dumb Fuzzer erzeugt Eingaben völlig zufällig ohne Rücksicht auf die zu erwartende Form der Eingabe zu nehmen. Ein Dumb Fuzzer erfordert den geringsten Arbeitsaufwand. Trotz sehr geringer Kosten können bereits hier gute Ergebnisse erzielt werden.

Smart Fuzzing: Ein Smart Fuzzer erzeugt Eingaben, welche sich an gültigen Eingaben orientieren und eine ähnliche Struktur aufweisen. Dies ist nützlich, da manche Programme nur dann eine bestimmte Verarbeitung durchführen, wenn be­stimmte Aspekte der Eingabe vorhanden sind (z.B. Json­/XML­API). Ohne die gültige Form würde das Programm so gar nicht ausgeführt werden und könnte somit auch nicht getestet werden. Ein intelligenter Fuzzer hält sich demnach an das Eingabe­format und kann gültige Eingaben konstruieren. Diese Art des Fuzzing erfordert Detail wissen über die gültigen Eingabeformate, umso komplexer die zu testende Software, umso aufwendiger und kostenintensiver die Umsetzung.

Mutation-based Fuzzing: Beim mutation­based Fuzzing werden gültige Eingaben zufällig mutiert, um fehlerhafte Eingaben zu erzeugen. Die Eingaben sind gültigen Eingaben oft sehr ähnlich, sodass eine gute Code­Deckung erreicht werden kann.

Generation-based Fuzzing: Ein generation­based Fuzzer erzeugt Eingaben von Grund auf neu. Im Gegensatz zum mutation­based Fuzzer bedarf es bei der Generierung keiner gültiger Eingaben zur Erzeugung neuer Inputs. Wichtig ist es, dass Eingaben konstruiert werden, die für das Programm einen gewissen Sinn er­geben, damit eine entsprechende Codeabdeckung erzielt werden kann.

7 Code Intelligence GmbH

Coverage-based Fuzzing: Coverage­based Fuzzing berücksichtigt die Code­abdeckung bei der Generierung neuer Eingaben. So können coverage­based Fuzzer weitaus mehr Teile eines Programms abdecken und testen, als es zuvor der Fall war. Durch die Messung der Codeabdeckung kann der Fuzzer beispielsweise heuristisch herausfinden, welche Eigenschaften des Testfalls einen bestimmten Codebereich ausmachen, und er kann schrittweise eine Reihe von Eingaben entwickeln, die es ermöglichen den Großteil des Codes abzudecken.

White-Box-Fuzzing: White­Box­Fuzzing untersucht während der Ausführung des zu testenden Programms den Quellcode. Das ermöglicht es Fehler und Schwach­stellen im Quellcode zu finden. Ein Whitebox­Fuzzer kann sehr effektiv sein, um Fehler aufzudecken, die sich tief im Programm verstecken.

Grey-Box-Fuzzing: Grey­Box­Fuzzing kombiniert die Effizienz von Black­Box­ und White­Box­Fuzzing. Außerdem informiert der Fuzzer über die Zunahme der Code­abdeckung während des Fuzzings, was ihn besonders effizient macht.

Black-Box-Fuzzing: Beim Black­Box­Fuzzing beschränkt sich der Testprozess auf die Erzeugung von Eingaben und die Beobachtung des Verhaltens des Outputs des Systems. Das Programm selbst wird als Black­Box betrachtet.

Anatomie eines FuzzersEin Fuzzer kann in der Regel in mehrere Bestandteile unterteilt werden:

Fuzz-Targets: Die Voraussetzung für die Anwendung von Fuzzern ist das Erstellen sogenannter Fuzz­Targets. Fuzz­Targets sind kleine Programme, die von Entwicklern definierte API­Funktionen testen, ähnlich wie bei Unit­Tests. Im Unterschied zu Unit­Tests wird der Input nicht vorgegeben, sondern über den Fuzz­Generator erstellt.

Fuzz-Generator: Der Fuzz­Generator ist für die Erzeugung der unerwarteten Eingaben verantwortlich, die an die zu testende Software gesendet werden, um Ausfälle und fehlerhaftes Verhalten zu verursachen und die SUT (SUT ­ Software under Test) zu steuern. Für die Generierung gibt es verschiedene Ansätze, welche maßgeblichen Einfluss auf den Fuzzing Prozess nehmen. Während des Generierungs­prozesses werden die Eingaben auf verschiedene Art und Weise verändert. Beispiels­weise werden bestimmte Teile der Eingabe vertauscht, verändert, eingefügt oder gelöscht. Dabei spielt das Feedback der Sanitizer eine Hauptrolle.

8 Code Intelligence GmbH

Delivery-Mechanismus: Der Output des Fuzz­Generators, die unerwarteten Ein­gaben, werden anschließend vom Delivery­Mechanismus an das zu testende System weitergeleitet. Der Delivery­Mechanismus verarbeitet die Systemeingaben vom Fuzz­Generator und stellt sie der SUT zur Ausführung zur Verfügung.

Monitoring-System: Das Monitoring­System beobachtet die zu testende Software, während jede Systemeingabe verarbeitet wird, und erkennt auftretende Fehler. Das Monitoring­System spielt er eine entscheidende Rolle im Fuzzing­Prozess und beeinflusst unmittelbar, welche Fehlerklassen der Fuzzer finden kann.

Vor­ und Nachteile von FuzzingFuzzing kann sehr nützlich sein, aber es ist kein Allheilmittel. Hier werden einige der Vor­ und Nachteile der Testing Methode aufgeführt:

Vorteile

• Code kann sehr schnell getestet werden vor allem verglichen mit der manuellen Überprüfung des Quellcodes.

• Sobald ein Fuzzer in Betrieb ist, kann er für Stunden, Tage oder Monate nach Fehlern suchen ohne das weitere manuelle Interaktion notwendig werden.

• Kann Fehler aufdecken, die bei einem manuellen Audit übersehen wurden.

• Fuzzing ist skalierbar: Mehrere Instanzen eines Fuzzers können in einem Kubernetes­Cluster gestartet werden.

• Bereits existierende Unit­Tests können bei der Erstellung von Fuzz­Targets helfen.

• Coverage­based Fuzzing deckt die meisten Sicherheitslücken auf.

• Fuzzing ermöglicht es ein Gesamtbild der Robustheit der Zielsoftware abzu­bilden.

Nachteile

• Klassisches Fuzzing kann Fehler übersehen, die nicht zu einem vollständigen Programmabsturz führen (Sanitizer ermöglichen es auch andere Fehlerarten aufzudecken ­> modernes Fuzzing) und kann weniger wahrscheinlich Fehler auslösen, die nur unter sehr speziellen Umständen ausgelöst werden.

9 Code Intelligence GmbH

• Die produzierten Crash­Testfälle können schwer zu analysieren sein, da der Vor­gang des Fuzzings nicht viel Wissen darüber vermittelt, wie die Software intern funktioniert.

• Um einen intelligenten Fuzzer zu erzeugen der ausreichend Codeabdeckung erreicht, ist bei Programmen mit komplexen Eingaben ein hoher Arbeits­aufwand notwendig.

• Die Integration von Fuzzing Technologien in den Entwicklungsprozess erfordert Expertenwissen im Bereich des IT­Security­Testings.

Überschattet werden die Vor­ und Nachteile vom Fachkräftemangel, welcher es Unternehmen zusätzlich erschwert Sicherheitsanforderungen gerecht zu werden und Fuzzing Methoden in ihrem Unternehmen einzusetzen.

Von Fuzzing profitierenTrotz der Herausforderungen ist Fuzzing eine hervorragende Technik zur Lokalisierung von Schwachstellen in Software. Es kann als Werkzeug zum Schwach­stellenmanagement in Unternehmen, welche Software erstellen aber auch in Unternehmen, die Software verwenden eingesetzt werden. Entwickler setzen Fuzzing als Bestandteil eines sicheren Entwicklungsprozesses ein, während Käufer Fuzzing als wichtiges Werkzeug für die Verifizierung und Validierung verwenden. Fuzzing kann so ein integraler Bestandteil der Softwaresicherheit werden.

Fuzzing bietet nicht nur einen entscheidenden Mehrwert in Hinblick auf Sicherheits­aspekte, sondern auch finanziell gesehen kann der Einsatz große Vorteile bieten. Fuzzing spart Geld, weil es günstiger ist, Fehler zu beheben, bevor sie zu finanziellen Schäden führen. So können bspw. hohe Strafen oder Haftungssummen aufgrund von Datendiebstahl, Ausfällen im Betriebsablauf etc. vermieden werden. Der Ruf ihres Unternehmens könnte aufgrund eines Angriffs wegen mangelnder Sicherheits­standards ernsthaft in Gefahr geraten. Das Auffinden von Schwachstellen und Fehlern spart Geld, schützt Ihr Unternehmen und Ihre Kunden.

Der Einsatz von Fuzzing in Ihrem UnternehmenDie Erläuterungen zu Fuzzing und seinen Herausforderungen zeigen, dass der Ein­satz von coverage­based Fuzzing die meisten Sicherheitslücken aufdecken könnte, allerdings zu komplex ist, um ohne entsprechende Experten im Entwicklungsprozess durchgeführt zu werden. Die CI Security Suite erlaubt es jedem Unternehmen von den Vorteilen des coverage­based Fuzzings zu profitieren.

10 Code Intelligence GmbH

Ansprechpartner

Philipp Langnickel

+49 157 37 64 9114

langnickel@code­intelligence.com

www.code­intelligence.com

Die im Fokus stehende vereinfachte Benutzbarkeit der Lösung macht Security Testing für Experten effizienter und befähigt Entwickler ohne IT­Security­ Expertise dazu kontinuier liche automatisierte Sicherheits­ und Zuverlässigkeitstests durch zuführen. So kann der Entwicklungsprozess beschleunigt und ein kontinuier­liches Qualitätsmanagement realisiert werden.

Die CI Security Suite, vereint die Vorteile statischer und dynamischer Software­ Analyse­Verfahren. Durch den Einsatz von Coverage­based Fuzzing in Kombination mit Sanitizern ist es möglich das Verhalten Ihres Programms während der Laufzeit zu überwachen. Im Unterschied zu Fuzzing­Ansätzen wie AFL wird die CI Security Suite direkt in Ihre IDE implementiert. Durch die Continuous Integration­Komponente er­möglicht es die Lösung Fuzz­Tests nach jeder Code­Änderung durch zuführen.

Die Vorteile von Code Intelligence auf einen Blick:

• Sicherheit und Zuverlässigkeit Ihrer Softwarelösungen

• Benutzerfreundlichkeit ­ auch Software­Entwickler ohne ausgewiesene Expertise in Code­Testing können automatisierte Fuzz Tests durchführen

• Kostenreduzierung ­ vermeiden sie Kosten, die durch Schwachstellen in Ihrer Software entstehen

• Performance ­ testen Sie schneller und umfangreicher ohne manuelle Aus­wertungen von False­Positives

• Einsparung von Zeit ­ Reduziert die Anzahl der benötigten Manntage um ca. 66%.

• Prozessoptimierung ­ passen Sie Ihre Sicherheitstests an den agilen Entwicklungs prozess an und profitieren Sie vom kontinuierlichen Qualitäts­management

Sie möchten mehr erfahren? Sprechen Sie mit unseren IT­Sicherheitsexperten. Ger­ne stellen wir Ihnen unsere Lösung in einem persönlichen Gespräch näher vor.

Code Intelligence GmbHRheinwerkallee 6

53227 Bonn

info@code­intelligence.de

www.code­intelligence.de

QuellenRichard McNally; ,Ken Yiu; Duncan Grove; Damien Gerhardy (2012). Fuzzing: The State of the Art. DSTO Defence Science and Technology Organisation.John Neystadt (February 2008). Automated Penetration Testing with White-Box Fuzzing. Microsoft. Retrieved 2009-05-14.Ari Takanen; Jared D. Demott; Charles Miller (31 January 2018). Fuzzing for Software Security Testing and Quality Assurance, Second Edition. Artech House. p. 15. ISBN 978-1-63081-519-6.Patrice Godefroid; Michael Y. Levin; David Molnar (2008-02-08). “Automated Whitebox Fuzz Testing” (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS’08).Michael Sutton; Adam Greene; Pedram Amini (2007). Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley. ISBN 978-0-321-44611-4.Patrice Godefroid; Michael Y. Levin; David Molnar (2008-02-08). “Automated Whitebox Fuzz Testing” (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS’08).