Category

Beim Sicherheitsupdate für Microsoft Windows vom November 2016 (MS16-130, CVE-2016-7212) wurde eine kritische Sicherheitslücke behoben, welche ich gemeldet hatte (siehe Danksagung von Microsoft).

In diesem Artikel möchte ich das Vorgehen und das Tool vorstellen, mit dem die Sicherheitslücke gefunden werden konnte.

Fuzzing und AFL
Wie aus meinem früheren Artikel ersichtlich ist, bin ich ein grosser Fuzzing Enthusiast und konnte diese Sicherheitslücke von Microsoft Windows sowie auch andere Sicherheitsrelevante Softwarefehler bei anderen Firmen (CVE-2011-2989, Mozilla Advisory 2016-53) mit dieser Strategie finden.
Fuzzing ist eine alte und bewährte Strategie, Software auf Fehler zu überprüfen. Dabei werden massenhaft Eingabedaten erzeugt und manipuliert, um dann schlussendlich zu überprüfen, wie sich die Software verhält. Es gibt viele Fuzzingtools und Frameworks  (siehe Peach Fuzzer, Sulley, Radamsa), welche verschieden Techniken verwenden, Fehler in der Software zu finden.
Ein Beispiel für eine Fuzzingtechnik ist, dass das Fuzzingtool relativ „dumm“ ist und die Eingabedaten einfach nur mittels „Bit flipping“ manipuliert werden, um diese als Eingabedaten für die zu testende Software zu verwenden (siehe Fuzz testing techniques).
Seit 2014 hat sich das Fuzzingtool American fuzzy loop (kurz AFL) vor allem im Open-Source Bereich durchgesetzt und zahlreiche Sicherheitslücken und Softwarefehler gefunden. Das Besondere an diesem Tool ist, dass durch Instrumentierung von der zu testenden Software die Codepfade beobachtet werden, die durch die Eingabedaten genutzt werden. AFL verwendet dann diese Informationen, um selber weitere Eingabedaten zu erzeugen, welche verschiedene Codepfade abdecken. Wie dieses Experiment zeigt, konnte mit dieser Technik  aus einer simplen Datei mit dem Inhalt “hello”, mit der Zeit gültige Bilddaten erzeugt werden.

WinAFL
Das Fuzzingtool AFL ist nur für Linux und Unix Betriebssysteme ausgelegt. Glücklicherweise erschien Mitte diesen Jahres WinAFL, das ein Fork von AFL und für das Windows Betriebssystem ausgelegt ist.
WinAFL verwendet, im Unterschied zu AFL, einen etwas anderen Ansatz für die Instrumentalisierung. Bei AFL wird die Instrumentalisierung statisch beim kompilieren zum Programmcode hinzugefügt. Bei WinAFL wird die Instrumentalisierung dynamisch mittels DynamoRIO erreicht und kann auch bei Software verwendet werden, bei denen nur die ausführbare Binärdatei verfügbar ist (also wenn kein Programmcode vorhanden ist).

WinAFL in Action
Der Programmcode für WinAFL sowie die vorkompilierte Versionen von WinAFL in 32- und 64 Bit sind komplett auf github verfügbar.
Nach dem Klonen vom WinAFL Repository und der Installation von DynamoRIO,  kann es auch schon gleich losgehen mit dem Fuzzing.
Eine Bespielapplikation ist auch dabei, welche hier für die Demonstration verwendet wird.
Der Programmcode von der Bespielapplikation (test.exe) ist ziemlich einfach und soll die Basis-Funktion von WinAFL aufzeigen:
wenn in einem Textfile das Wort „test“ enthalten ist, soll ein Programmabsturz verursacht werden, der dann erkannt werden soll.
Für diese Demo verwende ich die 32Bit Version.

Das Testprogramm (test.exe) und das Fuzzingtool (afl-fuzz.exe) sind im Ordner Bin32 zu finden.
Bevor aber angefangen werden kann, muss die Funktion, die das WinAFL Fuzzingtool aufrufen soll, als Konsolen-Parameter in Form von einem Offset (target_offset) mitgegeben werden, den man am besten mit dem WinDbg Tool von Microsoft herausfinden kann.

Nachdem WinDbg gestartet wurde, kann die Bespielapplikation (test.exe) mit dem WinDbg Tool geöffnet werden:

In diesem Beispiel möchten wir einfach die „main“ – Methode mittels WinAFL überprüfen.
Dazu muss folgender WinDbg – Befehl eingegeben werden:
x test!main

Der Offset kann ermittelt werden, indem der Wert von B (Anfangsadresse von test.exe) vom Hex-Wert von A (Adresse von main-funktion) abgezogen wird:

target_offset = A – B = 0x01241010 – 0x01240000 = 0x1010

Achtung! Dieser Offset kann auf einem anderem Computersystem unterschiedlich sein und muss daher individuell ermittelt werden.

Als nächstes stellen wir sicher, dass die Beispielapplikation fehlerfrei ausgeführt werden kann.
Dazu erstellen wir ein Textfile mit einem beliebigen Inhalt und rufen test.exe mit diesem Textfile als zusätzlichem Parameter auf:

Um einen Crash bei der Beispielapplikation zu verursachen muss als Input das Wort „test“ im Textfile vorhanden sein. Dazu ändern wir den vorherigen Inhalt von „noser“ auf „test“ und führen die Beispielapplikation erneut auf:

Wie man sieht konnten wir den Crash erfolgreich auslösen.

Als nächsten Schritt kann nun überprüft werden, ob mit DynamoRIO die Instrumentalisierung und der ermittelte target_offset funktionieren.
Dazu ändern wir unsere Textdatei wieder so um, dass die Beispielapplikation nicht abstürzt („test“ auf „noser“) und rufen unsere Beispielabblikation wie folgt auf:

c:\DynamoRIO-Windows-6.2.0-2\bin32\drrun.exe -c winafl.dll -debug -target_module test.exe -target_offset 0x1010 -fuzz_iterations 5 -nargs 2 — test.exe test.txt

Nachdem auch das geklappt hat sind wir nun bereit unsere Bespielapplikation mit dem WinAFL Fuzzingtool zu testen.

Dazu muss unsere Beispielapplikation wie folgt aufgerufen werden:

C:\winafl\bin32>afl-fuzz.exe -i in -o out -D c:\DynamoRIO-Windows-6.2.0-2\bin32 -t 20000 —
-coverage_module test.exe -fuzz_iterations 1000 -target_module test.exe -target_offset 0x1010 -nargs 2 — test.exe @@

Nach einigen Durchläufen wird WinAFL verschiede Programmpfade finden und sogar der Crash konnte relativ schnell gefunden werden.

Wenn wir das File anschauen im out/crashes Ordner, dann werden wir ein File mit dem Inhalt „test“ finden, welches die Ursache vom Crash ist:

Fazit
Mit WinAFL konnten schon erfolgreich sicherheistrelevante Software-Fehler gefunden werden. Darum kann der Einsatz von WinAFL,  um Software auf Softwarefehler zu untersuchen, durchaus eine Variante sein.
Ein Beispiel, wie so eine Teststrategie aussehen könnte, ist bei SQLite zu finden, welche Fuzz Testing mit AFL standartmässig in ihrer Teststrategie integriert haben. Dies könnte sicher auch für Software auf Windows Systemen mit WinAFL adaptiert werden.

Happy Fuzzing!

Wer kennt das nicht – das Release Datum für die neue Software steht vor der Tür und man muss die gerade erstellte Software „nur“ noch Testen…
Zum Glück wurden alle Testcases schon im Voraus definiert und man kann nach Testdrehbuch alle vorgesehenen Tests abarbeiten und alle automatisierten Tests durchführen. Wenn alle Tests „grün“ sind, kann man sagen, dass die Software getestet wurde und somit bereit ist für die Verteilung.
Was ist aber wenn ein wichtiger Testcase vergessen wurde, und der Kunde meldet, dass die Software ständig abstürzt? Oder noch schlimmer: was ist, wenn der Kunde meldet, dass durch eine Lücke in der neuen Software ein Angreifer in das System vom Kunden eingebrochen ist?

Die Antwort auf diese Fragen ist, dass man mühselig den Fehler beheben und eine neue Version dem Kunden ausliefern muss. Bei sicherheitsrelevanten Fehlern muss dieser Prozess möglichst schnell passieren!
Besser wäre, wenn man schon im Vorhinein solche Bugs beheben könnte, bevor die Software beim Kunden ausgeliefert wird.
Es ist eher unwahrscheinlich, dass man alle Fälle mit entsprechenden Tests abdecken kann. Es gibt aber eine gute Methode, wie man ohne grossen Aufwand Software auf ihre Robustheit und Sicherheit überprüfen kann – das Stichwort heisst Fuzzing.

Fuzzing ist eine bewährte Methode, Software auf ihre Robustheit zu testen sowie um eventuelle Sicherheitslücken aufzuspüren (Siehe auch https://de.wikipedia.org/wiki/Fuzzing).
Viele Hersteller setzen auf diese Methode um Software zu testen, vor allem bei Software, bei der das Schadensausmass sehr hoch wäre, wie zum Beispiel bei Browsern oder Office Anwendungen.
Hier ist ein Beispiel einer kritischen Sicherheitslücke, welche ich mit Hilfe von Fuzzing aufdecken konnte (https://www.mozilla.org/en-US/security/advisories/mfsa2011-29/ ).

In diesem Artikel möchte ich kurz zeigen, wie einfach eine Software mit Hilfe von Fuzzing auf Robustheit und potentielle Sicherheitslücken getestet werden kann.

Die zu testende Applikation

Als Beispiel werde ich einen Klassiker der Sicherheitslücken zeigen, welchen wir mit Hilfe von Fuzzing aufdecken werden.
Unsere zu testende Beispielapplikation in C/C++  ist nicht sonderlich komplex. Sie hat einzig die Aufgabe einen Wert einzulesen und diesen wieder in einer bestimmten Form anzuzeigen. Konkret soll die Applikation einen Namen einlesen und den Benutzer mit „Hallo“ begrüssen. Der Name wird der Applikation als Argument beim Programmstart übergeben.

Hier das Codebeispiel:

#include "stdafx.h"
#include <iostream>
using namespace std;

void printInput(char* input)
{
	char buf[20];
	strcpy(buf, input);
	printf("Hallo %s\n", buf);
}

int _tmain(int argc, _TCHAR* argv[])
{
	if (argc > 1)
	{
		printInput(argv[1]);
	}
	
	return 0;
}

Um dieses Beispiel mit Visual Studio kompilieren zu können, müssen in den Projekteinstellungen folgende Einstellungen zurückgesetzt werden:

Schon hier sollte jeder Entwickler stutzig werden, wenn an dieser Konfiguration etwas verändert werden muss. Aber in diesem Beispiel geht es ja genau darum, wie man es nicht machen sollte.
An dieser Stelle sei erwähnt, dass der Compiler eine Meldung Zeigen würde, dass etwas an diesem Code nicht in Ordnung ist:

Warning 1 warning C4996: ‘strcpy’: This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

Anschliessend muss noch „Character Set“ auf „Not Set“ gesetzt werden und unsere Demo Applikation kann kompiliert und verwendet werden.
Als positiv Test geben wir den Namen „noser“ als Argument mit und erhalten den erwarteten Output:

Der Fuzzer

Es gibt viele verschiedene Arten von Fuzzer und die meisten sind leicht über Google auffindbar.
Für das Testen unserer Demo Applikation verwenden wir Radamsa (https://github.com/aoh/radamsa).
Für Windows kann eine experimentelle Version verwendet werden, welche hier gefunden werden kann (https://code.google.com/archive/p/ouspg/downloads)
Die Verwendung von Radamsa ist ziemlich einfach. Ich verwende hier die Konsolen-Applikation für die Generierung der Testfälle.

Hier ein Beispiel wie so ein Testfall aussehen könnte:

echo noser | radamsa-0.4.exe

Als Eingabewert verwende ich das Wort „noser“. Dieser wird über eine Pipe-Anweisung „|“ an Radamsa übergeben. Dort wird das eingegeben Wort zu einer zufälligen Ausgabe umgewandelt/mutiert.
Genau diese zufällige Ausgabe brauchen wir um unsere Demo Applikation zu testen.

Für vier Testfälle musst der Befehl vier Mal manuell in der Konsole eingeben werden. Wenn man viele Tests durchführen will und die Demo Applikation automatisch testen möchte, kommt man mit der manuellen Eingabe nicht weit.
Aus diesem Grund habe ich ein PowerShell-Script erstellt, welches genau das macht was wir brauchen.
Ein Wert wird an Radamsa übergeben, und die Ausgabe von Radamsa wird direkt unserer Demo Applikation als Argument übergeben:

for($x=0; $x -le 10;$x++)
{
    $var= echo noser | .\radamsa-0.4.exe
    echo $x
    echo $var
    .\TestApplicationFuzzing.exe $var
}

Der Wert in der For-Schleife kann natürlich noch erhöht werden, wenn man mehr Testfälle ausführen will.
Jetzt kann unsere Demo Applikation mit dem PowerShell Script automatisch auf Robustheit und Sicherheitslücken getestet werden:

Schon bei der Ersten Ausführung von unserem Script stürzt die Demo Applikation ab.
Der Testfall 8 scheint in diesem Fall einen Absturz zu verursachen. (Die anderen Testcases ignorieren wir mal)

Versuchen wir den Absturz manuell zu reproduzieren, um sicher zu sein, dass dieser Testfall tatsächlich zum Absturz geführt hat:

Tatsächlich führ dieser Testcase zu einem Absturz. Anscheinend verträgt unsere Applikation folgende Eingabe nicht:

Oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooser
Hallo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooser

Die Analyse

Der Grund für den Absturz kann einfach mit WinDbg (siehe hier: https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) eruiert werden.

Ein „stack buffer overrun“ ist der Grund für den Absturz.
Solche Fehler sind immer als kritisch zu betrachten und müssen auf jeden Fall behoben werden
(siehe hier https://en.wikipedia.org/wiki/Stack_buffer_overflow und hier https://en.wikipedia.org/wiki/Buffer_overflow)!

Ein Blick in den Code zeigt uns was die Ursache des Problems ist:

Der allozierte Speicher (buf[20]) reicht gerade mal für 20 Zeichen (inkl. String Termination = ‘\0’, siehe hier https://en.wikipedia.org/wiki/C_string_handling )
Wenn als Argument ein String mitgegeben wird, der länger ist als 20 Zeichen, führt dies zu einem Puffer überlauf, weil die Funktion strcpy, welche in diesem Beispiel verwendet wird, keine Längenüberprüfung vom Input macht.

Fazit

Fuzzing ist eine sehr gute Methode, um eine Software auf Fehler und Sicherheitslücken zu überprüfen. Der Einsatz von Fuzzing-Tools ist einfach und schnell in jedem Entwicklungsprozess integriert.
Es gilt aber noch zu erwähnen, dass Fuzzing alleine nicht ausreicht um Fehler in einer Software zu finden und daher ist es wichtig, dass die bisherigen Testmethoden wie zum Beispiel Unit- und Integrationstests weiterhin durchgeführt werden und Fuzzing als eine weitere, unterstützende Testing-Methode verwendet wird.