NPA: Fuzzing AusweisAPP

zugehöriger Vortrag vom 01.10.2010

Fuzzing (chapter in work)

Was ist Fuzzing

Grundsätzlich lässt sich Fuzzing als automatisierte Eingabemanipulation verstehen.

Das dem Fuzzing am nähesten kommende Verfahren, die "boundary value analysis" ist eine Methode bei der die Aunahmebehandlung mit Testwerten um die Grenze zwischen guten und schlechten Werten herum überprüft wird.

Zusätzlich zu den Grenzwerten sind für das Fuzzing aber generell alle Werte interessant die undefiniertes oder unsicheres Verhalten hervorrufen können.

Fuzzing nach Sutton et al.

„... method for discovering faults in software by providing unexpected input and monitoring for exceptions ...“ [MSAGPA S.22]

Weiterhin hat Fuzzing Ähnlichkeit mit bekannten Testverfahren wie "Black Box Testing" und Gray Box Testing", wobei Zweiteres dank Systemwissen einen deutlich höhreren Erfolg verspricht.

Entstehung

Die erste Refernz zu Fuzzing ist aus dem Jahr 1989, als Prof Barton Miller von der UW-Madison Robustheitstests von Unix Anwendungen durchführen ließ. Dabei wurden Zufällige Zeichen und Zeichenketten an die Applikationen gesendet. Ziel war die Qualität des Codes und Zuverlässigkeit der Programme zu erhöhen.

Der nächste Meilenstein war 1999 die PROTOS Testsuite der Oula University, die für diverse Protokolle fehlerhafte nicht dem Protokoll entsprechende Pakete erzeugte.

In den Jahren ab 2002 machte sich das gesteigerte Interesse an Fuzzing durch die Veröffentlichung diverser Fuzzing Frameworks bemerkbar. Dazu gehören u.a. Spike und das kommerzielle Codenomicon.

Phasen

• Identify Target

Neben der Wahl der Anwendung an sich ist das eigentliche Einfallstor, wie eine Datei, eine Schnittstelle oder eine Bibliothek interessant;wobei vielfach verwendete wegen ihrer großen Verbreitung vorzuziehen sind.

Bei der Zielauswahl sind bereits bekannte Schwachstellen des selben Herstellers (auch in anderen Produkten) besonders interessant.

• Identify Inputs

Schwachstellen entstehen fast immer durch ungenügende Eingabedatenprüfung, diese können neben direkten Nutzereingaben unter anderem Header, Dateinamen, Umgebungsvariablen oder Registry Einträge sein.

• Generate Fuzzed Data

Je nach Ziel und Datenformat sollten Daten jeweils automatisiert vorausgewählt, aus sich heraus mutiert/verändert oder dynamisch neu generiert werden.

• Execute Fuzzed Data

Der eigentliche Prozess des Sendens vom Paketes, Öffnens der Datei oder Startens des Prozesses.

• Monitor for Exceptions

Die Fehlererkennung dient dann zur Eingrenzung des Problemfalles oder der Testfälle, sollte etwa die Reihenfolge/Abfolge eine Rolle spielen. Ohne sie weiß man zwar von der Existenz eines Fehlers, kann ihn aber nicht lokalisieren.

• Determine Exploitability

Mit der Fehlerursache kann, je nach Ziel, von einem Sicherheitsspezialisten der Fehler direkt behoben werden oder nach Folgefehlern gesucht werden. Im Gegensatz zu den anderen Phasen ist diese nicht automatisiert.