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.

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/Speicherzerstörung

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.