Software-Sicherheit – Teil 1 Programme per Debugging, Fuzzing und Reverse Engineering analysieren

Autor / Redakteur: Marcell Dietl / Stephan Augsten

Während sich die Zahl der Betriebssysteme seit Jahren kaum verändert hat, ist die Zahl der verfügbaren Applikationen schier explodiert. Doch ihre Sicherheit lässt oft sehr zu wünschen übrig. Dieser Artikel zeigt verschiedene Möglichkeiten, wie sich die Sicherheit einer lokalen Anwendung bewerten lässt.

Auf Drittanbieter-Software sollte man immer ein wachsames Auge werfen.
Auf Drittanbieter-Software sollte man immer ein wachsames Auge werfen.
( Archiv: Vogel Business Media )

Hacking-Versuche zielen meist nicht mehr auf zentrale Firmen-Server ab, sondern häufiger auf die Computer der Mitarbeiter. Jedes darauf installierte Programm stellt in den Augen der Angreifer eine potentielle Lücke dar.

Spektakuläre Windows-Exploits, welche es erlauben, die Kontrolle über ein System aus der Ferne zu übernehmen, sind selten. Und dennoch werden jedes Jahr Millionen neuer Schadprogramme gefunden. Allein 2010 registrierte AV-Test knapp 20 Millionen neue – Tendenz stark steigend.

Firewalls und Intrusion-Detection-Systeme sind ein wichtiger Schritt in die richtige Richtung. Doch Kriminelle bedienen sich vermehrt Techniken aus dem Bereich des Social Engineerings, um ihr Ziel zu erreichen. Häufig versenden sie E-Mails mit harmlosem Inhalt und einem Link, den der Anwender öffnen soll.

Tut er dies, hat der Angreifer auf alle Plugins und Add-Ons des Browsers Zugriff. Von Audio- und Video-Formaten bis hin zum PDF-Reader, bieten sich anschließend verschiedenste Angriffsvektoren. Um sich aus der Schusslinie zu bringen und Kosten zu sparen, setzen Behörden, Unternehmen und auch Privatpersonen immer häufiger auf alternative Software-Lösungen.

Doch wie steht es um deren Sicherheit? Die Suche nach bereits bekannten Problemen stellt einen sinnvollen ersten Schritt dar – reicht jedoch für eine endgültige Bewertung kaum aus. Besser ist es, sich Techniken der Bug Hunter zu bedienen und die Applikationen aus der Sicht eines solchen anzugreifen.

Inhalt

  • Seite 1: Software als Einfallstor
  • Seite 2: Debugger, Disassembler und Decompiler
  • Seite 3: Verhaltensmuster in einer Sandbox analysieren

Debugger, Disassembler und Decompiler

Ob Programmierer oder Reverse Engineer: Ein Debugger muss sein! Mit ihm lassen sich Befehlsfolgen schrittweise ausführen und falls gewünscht, jederzeit pausieren. Solche Haltepunkte (engl. Breakpoints) können je nach Debugger an eine festgelegte Stelle gesetzt oder an eine Bedingung geknüpft werden – etwa den Inhalt eines CPU-Registers.

Da aber in den meisten Fällen der Quellcode einer Applikation nicht bekannt ist, sind Debugger häufig auch vollwertige Disassembler. Bei der Ausführung hängen sie sich an den gewünschten Prozess und zeigen dessen Befehlsfolge mit mnemonischen Symbolen (kurz Mnemonics) an. Die Lesbarkeit des gewonnenen Assembler-Codes hängt jedoch stark von der Programmiersprache und dem verwendeten Compiler ab.

Im besten aller Fälle handelt es sich um ein Java- oder .NET-Programm, dessen Objektdatei noch viele zusätzliche Informationen enthält. Diese können von einem Decompiler dazu verwendet werden, den ursprünglichen Quellcode funktional nachzuempfinden. Generell gilt: Je mehr Debug-Informationen und je weniger Compiler-Optimierungen, desto leichter lässt sich ein Programm im Nachhinein analysieren und verstehen.

Applikationen mittels Fuzzing unter Beschuss nehmen

Sobald der Code in disassemblierter oder auch dekompilierter Form vorliegt und verstanden wurde, folgt der wohl wichtigste Schritt: Interessante Stellen lokalisieren und isolieren. Aus der Sicht eines Bug Hunters sind dies all jene Orte im Programm, an denen externe Daten (weiter)verarbeitet werden. Von Dateien, die gelesen werden bis hin zu Umgebungsvariablen, variieren die möglichen Angriffsvektoren enorm.

Sind sie allerdings gefunden, kommen häufig so genannte Fuzzing-Werkzeuge zum Einsatz. Diese generieren zufällige Daten, die dann als Eingabewerte in das Programm gespeist werden und dieses aus dem Tritt bringen sollen. Allzu zufällig dürfen sie jedoch häufig auch nicht sein, da viele Programme sie sonst direkt wieder verwerfen. Ist dieser Spagat endlich gelungen, heißt es warten.

Der am meisten kritisierte Aspekt dieser Technik, ist die Ungewissheit. Es ist völlig unabsehbar, ob und wann genau ein Fehler gefunden wird. Wer sicher gehen will, kommt an einer manuellen Bewertung des disassemblierten Codes nicht vorbei. Unternehmen wie Immunity oder Zynamics haben dieses Problem erkannt und spezielle Debugger entwickelt, die das Auffinden von Software-Fehlern stark vereinfachen sollen.

Inhalt

  • Seite 1: Software als Einfallstor
  • Seite 2: Debugger, Disassembler und Decompiler
  • Seite 3: Verhaltensmuster in einer Sandbox analysieren

Verhaltensmuster in einer Sandbox analysieren

Vor allem für Viren-Experten ist es wichtig, verdächtige Programme in einem sicheren Kontext ausführen zu können. Dazu nutzen sie spezielle virtuelle Umgebungen, die das Verhalten eines echten Betriebssystems möglichst genau nachbilden. Alle Veränderungen, die ein Schadprogramm anschließend am System vornimmt, können so in Ruhe aufgezeichnet und ausgewertet werden.

Die Applikation befindet sich im übertragenen Sinne in einem abgeschirmten Sandkasten (engl. Sandbox). Eine solche Testumgebung ist für einen Reverse Engineer von großem Vorteil – sie spart Zeit und Kosten. Vor allem Änderungen an der Windows-Registry und ähnlich kritischen Punkten sollten genau unter die Lupe genommen werden.

Eine der wohl bekanntesten Sandbox-Lösungen bietet das 1984 in Norwegen gegründete Unternehmen Norman. Deren Funktionalität richtet sich gezielt an Malware-Analysten und Reverse Engineers. Und dank automatisierter Analyse-Verfahren, liegen erste Reports binnen kürzester Zeit bereit.

Windows Sysinternals zur manuellen Diagnose einsetzen

Ähnlich den Wegen nach Rom, gibt es auch bei der Untersuchung von Applikationen verschiedenste Ansätze – jeder mit eigenen Vor- und Nachteilen. Die meisten der kommerziellen Lösungen setzen auf einen hohen Grad an Automatisierung, um Zeit und Kosten zu sparen. Demgegenüber bietet ein guter Reverse Engineer vor allem Erfahrungswerte und ein Gespür für Fehler, die durch einfache Raster gefallen wären.

Speziell für Windows-Systeme lohnt sich ein Blick auf die Sysinternals-Tools von Mark Russinovich und Bryce Cogswell. Unterteilt in mehrere Kategorien, stehen Programme zur Analyse diverser Komponenten des Systems zum freien Download bereit. So erlaubt allein der „Process Monitor“ das Überwachen von Dateisystem-, Registrierungs-, Prozess-, Thread- und DLL-Aktivitäten.

Im nächsten Teil dieser Artikelreihe zeigt Security-Insider.de Mittel und Wege, wie Programme auf Fehler untersucht werden können, deren Quellcode zur Verfügung steht.

Inhalt

  • Seite 1: Software als Einfallstor
  • Seite 2: Debugger, Disassembler und Decompiler
  • Seite 3: Verhaltensmuster in einer Sandbox analysieren

(ID:2050210)