NPA: Fuzzing AusweisAPP: Difference between revisions

From
Jump to navigation Jump to search
Line 81: Line 81:


===Fuzzer Typen===
===Fuzzer Typen===
Je nach Zielanwendung kann man Fuzzer in verschiedene Typen einordnen.
Je nach Zielanwendung kann man Fuzzer in verschiedene Typen einordnen. Gemein haben sie eine Weiterverwendung von ungeprüften Daten, die über die verschiedenen Eingabemöglichkeiten an das Ziel gelangen.
*Kommandozeile
Modifikation von Kommandozeilenparametern
*Umgebungsvariable


'''Kommandozeile''' TODO<br>
*Dateiformat
Es wird an den Übergabeparametern an die Anwendung gefuzzt. Bsp: zulang/kurz
*Fernzugriff
*Netzwerk Protokoll
*Web Anwendung
*Web Browser
*Speicher


'''Umgebungsvariable'''<br>
Vom Programm genutzte Umgebungsvariablen werden modifiziert.


'''Dateiformat'''<br>
*Frameworks
Eine Datei wird in sich, auch hinsichtlich des Dateiformats, präpariert um beim Auslesen und Verarbeiten durch die Zielanwendung unnormales Verhalten zu erzeugen.

'''Fernzugriff'''<br>

'''Netzwerk Protokoll'''<br>

'''Web Anwendung'''<br>

'''Web Browser'''<br>

'''Speicher'''<br>
Der Arbeitsspeicher wird eingefroren, an der bekannten Adresse für die Eingabe werden die Daten des Fuzzers geschrieben


'''Frameworks'''<br>
Fuzzing Frameworks abstrahieren oft benötigte Komponenten von Fuzzern und sind so Wiederverwendbar für die verschiedensten Typen von Fuzzern. Durch das konzentrierte und breit Anwendbare Wissen in einem Framework kann eine Community entstehen die es für ihre jeweiligen eigenen Interessen pflegt und weiterentwickelt.
Ein Nachteil ist die hohe Komplexität, welche die Vielseitigkeit ermöglicht, und der damit verbundene Einarbeitungsaufwand.


===Effektivität===
===Effektivität===

Revision as of 13:33, 2 November 2010

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.

Grenzen

Fuzzing kann nur ganz bestimmte Schwächen im Ziel herausfinden und es ist auch begrenzt was die Arten von Schwächen angeht. Im folgenden erläutert an einigen Schwächeklassen.

Zugriffskontrolle
Selbst wenn ein Fehler gefunden wird kann der Fuzzer nicht unbedingt unterscheiden ob der Zustand den er erreicht hat durch eine Zugriffskontrolle geschützt war, er also im admin Bereich war oder nicht. Dazu müsste er speziell darauf ausgelegt sein.

Schwacher Logikentwurf
Eine Funktion die in ihrer Grundheit an sich unsicher ist wie ein offener Fernzugriff in irgend einer Form kann so einfach nicht erkannt werden wenn es kein Fehlerfall in der Software ist und es z.B. vergessen wurde diesen Zugriff vor der Veröffentlichung wieder zu entfernen.

Hintertüren
Ein Backdoor unterscheidet sich für den Fuzzer nicht von einer anderen Eingabemöglichkeit und wenn ihm die Logik zur Steuerung dessen fehlt kann er damit auch nicht viel anfangen. Selbst wenn er Zugriff erhält muss er das schon mitbekommen. Einen Absturz dagegen würde er bemerken.

Memory Corruption
Speicherfehler können, ohne Debugger im Zielprozess, nicht erkannt werden wenn der Fehler abgefangen und behandelt wird.

Schwachstellenkombination
Kombinationen von Schwachstellen für einen Zugriff oder auch wenn die Reihenfolge wichtig ist sind von Fuzzern nicht sinnvoll herauszufinden.

Funktionsweise

Generell unterscheidet man Fuzzer in die folgenden beiden Klassen.

Mutationsbasiert
Es werden vorhandene Daten genommen und kontinuierlich verändert.

Erzeugungsbasiert
Die Daten werden nach Regeln jedes mal von neu generiert, je nach Ziel z.B. ein Paket oder eine Datei.


Es gibt aber noch weitere Arten, die mehr oder minder Effizient sind, wie Fuzzer funktionieren können.

  • Bereits im Vorhinein per Hand erstellte Testfälle
  • komplett Zufällig
while [1]; do cat /dev/urandom | nc -vv target port; done
  • Manuelle Protokoll Mutation
Was soviel bedeutet wie dass der Forscher selbst die möglichen Fehlerhaften Daten eingibt und nur noch der Prozess drum herum automatisiert ist.

Fuzzer Typen

Je nach Zielanwendung kann man Fuzzer in verschiedene Typen einordnen. Gemein haben sie eine Weiterverwendung von ungeprüften Daten, die über die verschiedenen Eingabemöglichkeiten an das Ziel gelangen.

Kommandozeile TODO
Es wird an den Übergabeparametern an die Anwendung gefuzzt. Bsp: zulang/kurz

Umgebungsvariable
Vom Programm genutzte Umgebungsvariablen werden modifiziert.

Dateiformat
Eine Datei wird in sich, auch hinsichtlich des Dateiformats, präpariert um beim Auslesen und Verarbeiten durch die Zielanwendung unnormales Verhalten zu erzeugen.

Fernzugriff

Netzwerk Protokoll

Web Anwendung

Web Browser

Speicher
Der Arbeitsspeicher wird eingefroren, an der bekannten Adresse für die Eingabe werden die Daten des Fuzzers geschrieben


Frameworks
Fuzzing Frameworks abstrahieren oft benötigte Komponenten von Fuzzern und sind so Wiederverwendbar für die verschiedensten Typen von Fuzzern. Durch das konzentrierte und breit Anwendbare Wissen in einem Framework kann eine Community entstehen die es für ihre jeweiligen eigenen Interessen pflegt und weiterentwickelt. Ein Nachteil ist die hohe Komplexität, welche die Vielseitigkeit ermöglicht, und der damit verbundene Einarbeitungsaufwand.

Effektivität

Datenerzeugung

Analyse der AusweisApp

Laufzeitanalyse

Statische Analyse

Funktionsweise

Kommunikation der AusweisApp

Fuzzing der Ausweisapp

Mitschnitt Kommunikation

Fuzzing Frameworks

weiterführende Ansätze

Software

Literatur