Efficient Fuzzing. Wie es bestehende Teststrategien effizient ergänzen kann

Contents

1 Einfuhrung
1.1 Motivation
1.2 Zielsetzung
1.3 Abgrenzung
1.4 Pre-Master Thesis

2 Fuzzing Grundlagen
2.1 Teststrategien
2.2 Definition von Fuzzing
2.3 Fuzzing Strategie
2.4 Effizientes Fuzzing
2.5 Zwischenfazit

3 Fuzzing im Kontext einer Automotive Teststrategie
3.1 Grundlegende Test-Kaskade
3.2 Die Rolle von Fuzzing in der Test-Kaskade
3.3 Relevante Randbedingungen der Automotive Domane

4 Fazit
4.1 Kompensation technischer Security MaEnahmen
4.2 Mehrwert

Bibliography

1 Einfuhrung

1.1 Motivation

Um Fuzzing als die Wunderwaffe im Security Testing existiert mittlerweile ein regel- rechter Hype. Als Konsequenz daraus hat sich der Begriff Fuzzing zunehmend auch zu einem inflationar genutzten Buzzwort entwickelt. Allerdings mangelt es vielen Diskussionen an echtem Inhalt. Meist bleibt unklar, was sich dahinter tatsachlich verbirgt, und in welchem Kontext welcher Mehrwert enstehen soll. Viel zu selten wird daher neues Wissen generiert. Das liegt unter anderem daran, dass keine all- gemeingultige Definition fur Fuzzing existiert. Kritiker argumentieren auch, Fuzzing sei lediglich eine Neuvermarktung bewahrter Methoden wie Grenzwertanalyse, das Bilden von Aquivalenzklassen, oder Monkey Testing [vgl. 11]. Als Konsequenz da- raus ist der Mehrwert von Fuzzing gemeinhin nicht offensichtlich.

Die fortschreitende und exponentiell wachsende Komplexitat Safety-kritischer Soft­ware Syteme bringen etablierte Testverfahren zunehmend an die Grenzen der Be- herrschbarkeit. Trotzdem hat man in der Automotive Industrie unter anderem durch die strengen Entwicklungsvorgaben nach wie vor eine sehr konservative Einstellung zum Testen. Dies hat zur Konsequenz, dass grundlegend neue Strategien und Tech- niken eher auf Zuruckhaltung stossen.

Die Freigabe von finanziellen und personellen Mittel zur Einfuhrung und Etablierung von Fuzzing in der Unternehmenskultur erfordert von den Security-Experten und - Abteilungen in Unternehmen viel Einsatz in Uberzeugungsarbeit. Eine echte Chance dafur besteht folglich nur dann, wenn offensichtliche Fakten als Rechtfertigung prasen- tiert werden konnen, das heisst

1. explizit ein echter Mehrwert nachgewiesen werden kann und
2. daraus auch ein positiver Kosten-Nutzen-Effekt resultiert.

In Neu-Deutsch also die Generierung eines Alleinstellungsmerkmals (KPI¹ ) gegenuber der Konkurrenz mit gleichzeitigem Ratio-Effekt, als Mainahme zur Reduzierung der Kosten.

Tatsache ist, dass es genugend Beispiele aus der Praxis gibt [vgl. 8] [vgl. 10] [vgl. 12], die bereits beeindruckende Ergebnisse durch den Einsatz von Fuzzing erzielen konnten [vgl. 4]. Allerdings muss hier fairerweise auch erwahnt werden, dass diese Ergebnisse nicht automatisch allgemeingultig fur alle Software Domanen zutreffen. So unterstutzen beispielsweise aktuelle kommerzielle Fuzzer lediglich sehr wenige Embedded Targets. Deren Schwerpunkt auf Kommandozeilen-basierten Tools fur Windows- beziehungsweise Linux-basierte Systemen [vgl. 15, Tabelle 1.1 auf Seite 7], die sich nach dem Durchlauf selbst terminieren und dem Benutzer keine weitere Moglichkeit der Interaktion bieten.

Deeply Embedded Devices in der Automotive Domane, also Komponenten ohne einen direkten Link in Netzwerke ausserhalb des Fahrzeugs, bilden eine sehr spezielle Spezies. Diese sind meist relevant im Sinne der Funktionalen Sicherheit². Diese wur- den in den letzten Jahren vermehrt Angiffsziel sehr prominenter Fahrzeug-Hacks von Security Forschern³ und sind erst dadurch in den Fokus der Product Security geruckt. In der Vergangenheit besaien sie, wenn uberhaupt, als Absicherung nur sehr rudi- mentare Security Mechanismen. Daher war es Security-Forschern uberhaupt erst moglich, der Offentlichkeit erfolgreiche Hacks auf Basis dieser Security Schwach- stellen zu prasentieren. Dies ist ein ewiges Katz-und-Maus Spiel, und basiert auf dem Prinzip Hoffnung, dass die Entwickler den Hackern stets einen Schritt voraus sind.

Die rasant fortschreitende Vernetzung und zusatzliche Cloud Services transformieren das Gesamtsystem Fahrzeug in ein IoT⁴ -System auf Radern [vgl. 1]. Damit ver- groiet sich die Angriffsflache und folglich auch die Bedrohung fur Fahrzeuge durch Remote-Angriffe. Als Antwort auf diese Entwicklungen wurden mittlerweile zusat- zliche Vorschriften⁵ und neue Standards⁶ auf den Weg gebracht. Weitere, zusatzliche Regularien befinden sich weltweit noch in Arbeit.

Um diese zu erfullen ist ein Wettlauf der Fahrzeughersteller entbrannt, kontinuier- lich neue Features zu entwickeln und in die samtliche Komponenten zu integrieren. Einige davon zielen dabei explizit lediglich auf den Eigenschutz als Second-Level-of- Defense, falls einzelne Features doch gebrochen werden sollten. Vereinzelt entsteht daher der Eindruck, dass wider jeglicher rationaler Analyse das Prinzip Je-mehr- desto-besser angewendet wird. Man konnte es aber auch so sehen, dass zusat- zlichen Massnahmen als Kompensation mangelnder Absicherung eingefuhrt wer- den, beziehungsweise aus der Angst und dem Wissen heraus, dass bestehende Ab- sicherungsmainahmen mitnichten ausreichend sind.

Letzendlich soll diese Arbeit dazu beitragen ein Verstandnis dafur zu generieren, dass Product Security eben nicht nur die Entwicklung und Integration technischer Security Mainahmen, sondern domanenspezifische Test-Methoden eine gleichwer- tig Daseinsberechtigung erlangen. Das strategische Ziel jeder Produktentwicklung muss es sein, den Bedarf an technischen Mainahmen moglichst gering zu halten, und dennoch dem ermittelten Stand-der-Technik im Sinne der Produkthaftung zu genugen!

1.2 Zielsetzung

Im Rahmen dieser Studienarbeit soll daher erortert werden, wie Fuzzing bestehende Teststrategien effizient erganzen kann. Ebenso wird versucht zu analysieren, ob sich durch Fuzzing der tatsachliche Aufwand im Testing generell reduzieren lassen konnte. Im Fazit soll es moglich sein Aussagen daruber treffen zu konnen,

1. wann der Einsatz von Fuzzing in der Teststrategie wirklich sinnvoll ist, und
2. inwieweit der effiziente Einsatz von Fuzzing den zusatzlichen Bedarf an tech- nischen Security Mainahmen kompensieren konnte.

1.3 Abgrenzung

Die Analyse, beziehungsweise die Erorterung des Nutzens von Fuzzing im Test- prozess, wird exemplarisch im Kontext der automotive Domane nach den Grund- satzen des ASPICE⁷ Prozess Reifegradmodells durchgefuhrt. Daher wird in dieser Ausarbeitung vorausgesetzt, dass die entsprechenden Techniken, vor allem in der Produktabsicherung, gemai den Anspruchen von ASPICE ohnehin angewendet wer- den.

Diese Arbeit enthalt keine Details zu ASPICE und den in diesem Kontext etablierten Testverfahren. Diese werden als Grundwissen vorausgesetzt und gegebenfalls nur kurz vorgestellt, sofern sie im Kontext dieser Arbeit relevant sind, jedoch weder naher erlautert noch bewertet.

Ebenso darf hier nicht unerwahnt bleiben, dass Fuzzing nur eine mogliche Technik ist, Schwachstellen zu finden. Situativ mogen andere Techniken praktikabler und effizienter sein. Daher ist es von essentieller Bedeutung, diesen Aspekt bei der Def­inition eines Security Testing Konzeptes mit zu berucksichtigen [vgl. 15, Kapitel 1]. Dies wird im Rahmen dieser Ausarbeitung aber nicht weiter verfolgt.

Fuzzing ist im Gegensatz zu Penetration- oder Pen-Testing eine zyklisch wiederkehren- der Test⁸ wahrend der Entwicklungsphase und gegebenfalls daruber hinaus. Pen­Tests hingegen sind singulare Events zu festgelegten Meilensteinen wahrend der En- twicklungsphase.

1.4 Pre-Master Thesis

Diese Arbeit dient als Grundlage fur meine Masterarbeit The effect of Fuzzing to boost efficiency within a Unit-Test Environment am Institut Systemsicherheit der RUB. Diese befasst sich mit der Ermittlung einer Datengrundlage als Nachweis fur die in dieser Arbeit aufgestellten Thesen zu den Potentialen der Effizienssteigerung durch Fuzzing beim Unit-Test.

2 Fuzzing Grundlagen

2.1 Teststrategien

Beim Fuzzing handelt es sich klassisch um einen Software Test. Durch Testing soil grundsatzlich die Robustheit, Qualitat und Zuverlassigkeit von Software gesichert und verbessert werden. Durch Fuzzing im Speziellen soil zusatzlich die Resilienz der Software gezielt uberpruft werden. Dies zielt auf die Robustheit der Software gegen unerwartete, das heisst nicht explizit definierte, Ereignisse und Stim­ulation ab.

Black-Box (BB)

Fur BB Fuzzing liegen keinerlei Informationen zu Interna vor. Die Aktivitat wahrend des Testens beschrankt sich auf das Beobachten von Ein- und Ausgabewerten. Da­her bedarf es zu deren Durchfuhrung auch keinerlei spezieller Expertise uber das DUT⁹. BB Fuzzing zeichnet sich auch dadurch aus, dass es sich sehr leicht replizieren lasst. Damit kann beispielsweise ein reprasentativer Test auf eine standardisierte Schnittstelle oder Port uber mehrere Produkten und Implementierungen sehr ef- fizient und im direkten Vergleich¹⁰ durchgefuhrt werden.

Zielsetzung dieser Teststrategie ist es, dass die Software des DUT entweder absturzt oder aufhangt, analog einem (D)DoS¹¹ Angriff. Das Resultat ist das gleiche: das DUT ist nicht mehr in der Lage seine eigentliche Funktionalitat auszufuhren.

Durch das nicht vorhandene Wissen uber Details existiert damit auch implizit kein Anhaltspunkt uber die Abdeckung¹² der Testprozedur. Diese ist aber ausschlaggebend fur die Gute der implementierten Testsequenz. Bevorzugte Anwendungsbereiche dieser Methode sind komplexe DUTs, die auf Eingaben nicht deterministisch reagieren, das heisst fur jede Anfrage immer eine unterschiedliche Antwort generieren. [vgl. 2]. Daher kann BB Fuzzing nur an der Oberflache kratzen, da lediglich offensichtliche Schwachstellen mit etwas Erfahrung und Best-Practice einfach gefunden werden kon- nen. Allerdings erfordern tiefer liegende Schwachstellen komplexe Stimuli, wofur zwangslaufig weiteres Wissen essentiell erforderlich ist.

White-Box (WB)

Beim WB Fuzzing liegen zur Durchfuhrung nicht nur samtliche Informationen zum DUT vor, es besteht auch Zugriff auf die entsprechenden Entwickler¹³. Damit ist der Zugang zu Expertenwissen und jeglichen Details zum DUT sichergestellt. Aus Testing-Aspekten bietet sich damit die bestmogliche Ausgangslage, um die Pfadab- deckung systematisch zu ergrunden.

Das umfangreiche Wissen hat allerdings zur Folge, dass damit die Generierung von Testfallen entsprechend komplex ist, wenn man nicht von vorn herein Approximatio- nen in Betracht ziehen mochte. Der Einsatz statischer Analysetools unterstutzt die Beherrschung der Komplexitat. Dies ermoglicht in einem ersten Schritt die Aufdeck- ung nicht erreichbarer Pfade¹⁴, sogenanntem toten Code¹⁵, um diesen bereits vor dem Fuzzing systematisch entfernen zu konnen.

Es kann mit Sicherheit angenommen werden, dass Softwareprodukte, die im Kontext Security relevant sind, die Gro£e dessen deutlich uberschreiten, was noch manuell uberprufbar ware. Die Schwierigkeit mit Analysetools ist jedoch nach wie vor, dass deren Ergebnisse immer noch manuell von Experten analysiert werden mussen um False-Positives auszuschlieien. Wurde dies nicht getan, konnte dies genau ins Gegen- teil uberschlagen, indem das Produkt durch resultierenden zusatzlichen Code zur vermeintlichen Beseitung gefundener Schwachstellen verschlimmbessert wurde.

Grey-Box (GB)

GB Fuzzing versucht den Spagat zwischen BB und WB Fuzzing zu schaffen. Es liegen zwar wie beim WB Fuzzing alle Informationen vor, allerdings wird nur ein Teil davon tatsachlich verwendet und bewusst mit Approximationen geabeitet. Der Trade-Off ist dann ein bisschen Genauigkeit gegenuber sehr viel besserer Ausfuhrbarkeit.

Das Prinzip dabei ist, dass jeder Stimulus des DUT ein Feedback generiert, das aus- gewertet wird. Dabei wird beobachtet, welche Codepfade in einer Datei durch bes- timmte Eingaben genutzt werden um die Fuzzing-Strategie entsprechend dynamisch anzupassen [vgl. 8]. Der Fuzzer versucht also systematisch, sich immer weiter einzu- graben, um damit neue Branches zu entdecken und damit die Coverage zu erhohen. GB Fuzzer sind in der Lage, die dafur notwendigen Informationen wahren der Tes- tausfuhrung durch den Einsatz spezieller Algorithmen zu ermitteln und durchlaufene Pfade zu erkennen.

Bevorzugte Anwendungsbereiche dieser Methode sind DUTs, die in sich abgeschlossen sind und auf Eingaben deterministisch reagieren, das heisst fur jede Anfrage stets

2.2 Definition von Fuzzing

die gleiche Antwort generieren [vgl. 2]. Der bekannteste Vertreter dieser Kategorie ist AFL¹⁶.

Zusammenfassung

Eine Schlussfolgerung, dass eine Teststrategie generell besser als eine andere sei, ist grundsatzlich falsch. Vor allem diejenige, dass WB gegenuber BB Testing ef- fizienter ware. Vielmehr ist es essentiell, die einzelnen Teststrategien wahrend der Entwicklung geschickt zu kombinieren um eine moglichst vollstandige Pfad—Abdeckung zu erzielen [vgl. 15, Kapitel 1].

Es ist entscheidend, zu jedem Zeitpunkt der Entwicklung die Expertise und das vorhandene Wissen so zu nutzen um daraus die maximale Wertschopfung zu gener- ieren.

Fuzzing ist ein Prozess, der uber den Ansatz etablierter Techniken wie der Grenz- wertanalyse beim Erstellen von Testfallen hinausgeht. Diese beschreibt ganz generell die Prufung, ob eine Applikation auch gegen Eingaben ausserhalb des erwarteten, spezifizierten Wertebereichs resilient ist. Vielmehr umfasst Fuzzing jegliche Eingabe, die einen undefinierten oder unsicheren Zustand des DUT provozieren kann.

Generell ist Fuzzing definiert als

1. automatisiertes (Security) Testen [vgl. 15, Kapitel 1] und
2. auf das DUT jeden nur denkbaren Testvektor abzufeuern und dessen Verhalten als Resultat darauf zu beobachten [vgl. 15, Kapitel 1]. Anders formuliert ist es das Stimulieren eines DUT mit nicht erwarteter beziehungsweise spezifizierter Eingabe und die Beobachtung¹⁷ auf auffalliges Verhalten¹⁸ [vgl. 15, Kapitel 2].

Eine andere Definition ist von der Aussage ahnlich, wird aber konkreter: Fuzz­Testing oder Fuzzing ist eine BB Software Testing Technik, welche mehr oder weniger darauf basiert, Implementierungsfehler unter Anwendung von automatisierter ungultiger Eingangsparameter zu finden [vgl. 3].

[...]

¹ Key Performance Indicator

² Functional Safety nach ISO 26262

³ Exemplarisch seien hier nur die Hacks von Miller und Valasek eines Jeep Cherokee erwahnt

⁴ Internet of Things

⁵ UNECE R155

⁶ ISO/SAE 21434 beschreibt Fuzz-Tests ale eine mogliche Verifikations-Methode

⁷ Automotive SPICE ist eine domanenspezifische Variante der ISO/IEC 15504

⁸ Allerdings ist die Verbreitung von zyklischem Fuzzing im Automotive Bereich noch nicht sehr weit verbreitet.

⁹ Device Under Test

¹⁰ engl. Benchmark

¹¹ (Distributed) Denial of Service

¹² engl. Coverage

¹³ Dies ist zwar durch die Academia nicht vorgesehen, in der Praxis jedoch trotzdem ublich.

¹⁴ engl. Branches

¹⁵ engl. DeadCode

¹⁶ https://github.com/google/AFL

¹⁷ engl. Monitoring

¹⁸ sog. Anomalien