Mehr Gedanken zum ‚Race-to-Zero-Contest‘

Nach Eugene möchte auch ich einige Gedanken zur diesjährigen Defcon loswerden. Letztes Jahr habe ich auf der Defcon einen Vortrag gehalten, und ich muss sagen, dass diese Veranstaltung schon etwas ganz Besonderes ist – hier treffen sich kluge Köpfe mit unkonventionellen Ideen zum Erfahrungsaustausch. Aber die Defcon bietet nicht nur den Zugang zu neuen Ideen, sondern man spürt hier auch den Geist der modernen Cyberkultur.

Meiner Meinung nach war die Ausrichtung von Wettbewerben wie Race to Zero nur eine Frage der Zeit. Jetzt, da der Anfang einmal gemacht ist, können wir auch in Zukunft mit Ähnlichem rechnen – ob es uns nun gefällt oder nicht. Natürlich darf man das Gesetz nicht brechen, daher denke ich, dass die genaue Form des Wettbewerbs noch vor Beginn der Defcon geändert wird, um den gesetzlichen Vorschriften zu entsprechen.

Ich bin aber der Meinung, dass die Organisatoren des Race to Zero-Contests die Spielregeln in eine ganz andere Richtung ändern könnten, so dass alle Beteiligten etwas davon hätten. Ich will das einmal kurz erklären:

Was sollen die Wettbewerbsteilnehmer bei dem Contest eigentlich manipulieren? Ihnen wird der Code existierender Anwendungen sowie vermutlich einige vorbereitete Nopcode-Sets zur Verfügung gestellt. Nopcode („no operation“ code) ist eine spezielle Software, die weder den Zustand des Rechners beeinträchtigt noch das System verändert. Es gibt viele verschiedene Obfuskations-Techniken, doch fast alle beruhen auf demselben Prinzip: Der betroffene Code wird umstrukturiert und mit Nopcode vermischt. In Abhängigkeit von dem verwendeten Algorithmus zur Vermengung der beiden Codes ist es entweder besonders schwierig, den Code zu lesen/zu bearbeiten oder der Code ist vor Entdeckung durch signaturbasierte AV-Scanner geschützt.

Obfuskierter Code ist durchaus geeignet, AV-Herstellern Kopfzerbrechen zu bereiten: Er ist geringfügig schwerer manuell zu analysieren, es bedarf größerer Ressourcen zur Pflege einer Datenbank von obfuskierten Samples, die sich bezüglich ihres Verhaltens nicht voneinander unterscheiden, und die Analyse eines obfuskierten Samples mit automatisierten Tools dauert länger als die von nicht obfuskierten Mustern. Daher arbeiten AV-Anbieter verstärkt an der Entwicklung von Deobfuskations-Tools.

Es gibt also zwei Probleme: Obfuskation und Deobfuskation – zwei Techniken, die sich hinsichtlich ihrer Komplexität ein wenig unterscheiden. Stellen Sie sich einfach einen Eimer Zucker und einen Eimer Sand vor. Sie können den Inhalt der beiden Eimer in verschiedenen Verhältnissen mischen – das sind die verschiedenen Arten der Obfuskation. Der umgekehrte Prozess ist die Deobfuskation, d.h. das Zurücksortieren der Mischung in ihre zwei Bestandteile Zucker und Sand. Stellen Sie sich nun diese zwei Eimer vor: Es geht sehr schnell, deren Inhalt miteinander zu vermischen, aber das Auseinandersortieren ist langwierig und ermüdend!

In mancherlei Hinsicht ist es nicht besonders schwierig, Obfuskationsalgorithmen anzuwenden und eine Anwendung so zu präparieren, dass sie von AV-Software nicht erkannt wird – es ist ein White-Box-Problem. Man verfügt über die Quelldaten, die AV-Software und hat zudem die Möglichkeit, den zerlegten Code zu analysieren, so dass man seine eigene Anwendung zur Veränderung der Daten entwickeln kann. Jeder Teil des selbst entwickelten Prozesses und der Mechanismen kann nachvollzogen werden.

Deobfuskation dagegen ist etwas völlig anderes. Man verfügt über einige Teile des Codes, der mittels Obfuskation verändert wurde – wobei die Anwendung zur Obfuskation nicht bekannt ist. Daher kann man die Deobfuskation noch nicht einmal als Black-Box-Modell bezeichnen. Denn bei Black-Box-Tests besteht immerhin die Möglichkeit, einen Mechanismus so oft wie gewünscht einzusetzen, selbst wenn man keinen Einblick in die Funktionsweise hat. Bei der Deobfuskation stehen einem nur die Daten zur Verfügung, die aus diesem Mechanismus resultieren. Die Daten müssen dann untersucht werden, um ihre einzigartigen/allgemeinen Merkmale zu bestimmen und daraufhin kann man seine eigenen Schlüsse darüber ziehen, wie die hypothetische Black Box tatsächlich funktioniert.

Meiner Ansicht nach erfordert Deobfuskation ein weitaus höheres Maß an Vorstellungskraft und zudem größere Fertigkeiten. Würden die Organisatoren von Race to Zero die Prinzipien ethischen Hackings beachten und den Wettbewerb auf Deobfuskation ausweiten, würden alle Beteiligten ihren Spaß an der ganzen Veranstaltung haben und wertvolle Erfahrungen mitnehmen können.

Um es noch einmal klar zu stellen: Um die Problematik der Obfuskation/Deobfuskation zu untersuchen, bedarf es keiner neuen Malware und auch bereits bestehende Schadprogramme müssen zu diesem Zweck nicht modifiziert werden. Das ist schlicht und ergreifend nicht nötig. Dieser Wettbewerb ist nicht nur ein technische, sondern gleichermaßen eine moralische Herausforderung. Es bleibt zu hoffen, dass sich jeder für die richtige Seite entscheidet, so dass wir alle unseren Nutzen daraus ziehen können.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.