Ein Tag im Leben eines Viren-Programmierers Marc Ruef | 18.08.2008 Schon fast ein bisschen mit Stolz darf ich behaupten, dass ich mit etwa 13 Jahren meinen ersten Computervirus geschrieben habe. Nichts Besonderes: Ein kleiner Overwriting-Virus in Qbasic, der sich auf dem Dateisystem meines MS DOS 3.1 gütlich getan hat. Den Code dazu habe ich vorzugsweise aus verschiedenen C64-Lehrbüchern zusammenkopiert: Lediglich in einigen wenigen Fällen musste ich eine systembedingte Portierung einbringen. Dabei musste ich lediglich verstehen, wie sich rekursiv durch das Dateisystem bewegt werden will und wie sich etwaige Trägerdateien (com und exe) infizieren lassen können. Eine Aufgabe, der sich heutzutage wohl jeder Informatik-Student im zweiten Semester gewachsen sieht. 1993 war es aber ein Abenteuer sondergleichen. Heutzutage verdiene ich mit diesem Wissen Geld. Nein, nicht dass ich nun irgendwelche Botnetze für dubiose "Firmen" aus dem Ostblock (z.B. Russian Business Network) entwickeln würde, damit diese Spam verbreiten und Erpressungen mit DDoS durchsetzen (http://www.20min.ch/digital/multimedia/story/19754588) können. Viel mehr ist mein Wissen und meine Erfahrung gefragt, wenn es um das Anfertigen von Proof-of-Concepts geht. Viele Firmen, vorzugsweise Finanzinstitute, wollen durch eine individuelle Hintertür bewiesen haben, ob und inwiefern sie jemand effektiv auf elektronischer Ebene angreifen könnte - Trotz einem 6 Millionen Franken IT-Security Budget. Hier komme also ich ins Spiel. Schon so manchen Auftrag habe ich in diesem Bereich erfolgreich durchgeführt. Und ich muss gleich zu Beginn vorausschicken, dass sie alle früher oder später erfolgreich ausgegangen sind (manchmal halt nur einfach mit ein bisschen mehr Aufwand). Doch ein Auftrag wird mir ganz bestimmt in Erinnerung bleiben. Einer unserer Kunden, eine Privatbank, setzt alles daran, ihre Kunden und deren Vermögen vor Angriffen zu schützen. Das Budget spielt dort, im Gegensatz zu vielen anderen Firmen, keine grosse Rolle. Die Sicherheit geniesst eine derartig hohe Priorität, dass man hier nicht jeden Euro zwei Mal wälzt. Eine der effektiven Schutzmassnahmen des Unternehmens ist, dass die internen Mitarbeiter keinen Zugriff aufs Internet haben. Will jemand das World Wide Web nutzen, muss er sich zusätzlich auf einem Citrix-Server, er befindet sich in einer speziellen Zone, einloggen und dort den Browser nutzen. Kann nun ein Angreifer diese Sitzung übernehmen, wird er jedoch nicht in Kontakt mit sensitiven Informationen kommen. In dieser Citrix-Zone finden sich lediglich "unwichtige" Daten für den Webzugriff. Die einzige Möglichkeit, wie in beschränktem Masse Daten von und zum internet transferiert werden können, besteht via Email. Durch das Nutzen er Outlook/Exchange-Umgebung können Nachrichten ohne Attachments(!) verschickt werden. Es wird also alles daran gesetzt, dass kein potentiell bösartiger Verkehr von oder zu einer Zone, die sensitive Daten enthalten könnte, stattfinden kann. Ich war und bin jedes Mal beeindruckt, dass ein wirtschaftlich orientiertes Unternehmen derart an den soliden Grundsätzen der modernen Informationssicherheit festhält. Viele andere Firmen könnten sich hiervon ein Stück abschneiden! Der Vorteil meines Kunden sollte nun aber mein Nachteil sein: Denn so bestand ja nun genau meine Aufgabe darin, dass ich sensitive Daten aus dem internen Netz einem meiner Hostile-Computers im Internet zuschicken lassen sollte. Ein Trojanisches Pferd, das über Social Engineering eingebracht wurde, sollte diese Aufgabe erledigen. Eine rein technische Methode sah ich nicht. Wie bei jedem Projekt dieser Dimension bin ich darum bemüht, dass bei der effektiven Durchführung absoluter Perfektionismus vorherrscht: Alles muss reibungslos und möglichst effizient funktionieren. Jede Millisekunde und jedes Byte, das ich sparen kann, empfinde ich als unendliche Genugtuung. Aus diesem Grund wird vor der ersten Infektion ein realitätsnaher Testdurchlauf gemacht. Durch das absichtliche Infizieren eines Systems sollen die Nebeneffekte frühzeitig identifiziert und auf sie reagiert werden. Dieses Feintuning ist sehr intensiv. So gilt es unterschiedliche Betriebssystem-Versionen als solche wahrzunehmen und auf ihre Eigenheiten zu reagieren. In manchen Fällen, bei denen es um die Echtzeit-Manipulation von Programmausgaben geht (z.B. bei einer Bankenapplikation), müssen bisweilen kleinste Details wie Bildschirmauflösungen berücksichtigt werden. Keine leichte Aufgabe, da hier auf einer hochgradig komplexen und dynamischen Ebene gearbeitet wird. Im genannten Fall musste ich eine Fehlermeldung, die ich nicht verhindern konnte, durch ein Fenster ohne Rahmen (Overlay-Frame) überdecken. Dadurch sollte die Nachricht abgeändert werden, so dass der Benutzer zu keinem Zeitpunkt verdacht schöpfen sollte. Das erste Problem bestand darin, dass je nach Installation eine andere Version der Applikation zum Einsatz kam. Und jede Version pflegte andere Prozess- sowie Fensternamen einzusetzen. Ich musste also dynamisch reagieren, jenachdem mit welcher Version ich es zu tun hatte. Hinzu kam, dass auf gewissen Rechnern ein Newsfeed installiert war, der sich an den Rand des Bildschirms band. Zu meinem Erstaunen führte dies dazu, dass die ausgelesene Bildschirmauflösung sich veränderte. und zwar wurde der Bereich, der durch das Frame eingenommen wurde, subtrahiert. Jenachdem ob dies nun angezeigt wurde oder nicht, befand sich die Mitte des Bildschirms wo anders. Ich musste jedoch die exakte Mitte kennen, da in einem spezifischen Bereich die Fehlermeldung angezeigt werden würde. Würde ich mein Overlay-Frame nicht darauf anpassen, wäre es verschoben dargestellt und täte natürlich das Misstrauen der Opfer wecken. Ein weiteres Problem war, dass ich kurzfristig (für ca. 0,2 Sekunden) temporäre Dateien anlegen musste. Bei meinen üblichen Applikationen schreibe ich diese ins Anwendungsverzeichnis. Dies war hier jedoch nicht möglich, da die Hintertür auf einem schreibgeschützten Netzwerklaufwerk ausgeführt werden würde (also konnte ich nicht schreiben). So wollte ich zuerst pauschal nach C:\ schreiben, um dann zu merken, dass auf den neuen Windows XP-Clients der Schreibzugriff dafür nicht gegeben war. Logischerweise wollte ich auf das globale %temp% (das Standard-Verzeichnis für temporäre Dateien auf einem System) ausweichen. Das nächste Problem bestand aber nun darin, dass meine API-Calls das Dollarzeichen nicht mochten bzw. keine Namensauflösung durchführen konnten. So galt es zuerst über einen weiteren API-Call auf kernel32.dll das temporäre Verzeichnis in Erfahrung zu bringen. Klar, das ist keine komplexe Angelegenheit - Dennoch etwas, was meine Backdoor verkomplizieren sollte - Und Komplexität ist etwas, was man bei einem solchen Projekt möglichst vermeiden will. Das Entwickeln von Viren, Würmern, Hintertüren und Botnetzen ist keine allzu schwierige Angelegenheit. Wirklich schwierig wird es aber, wenn man dies professionell durchsetzen will. Auf verschiedene Eigenheiten des Hostsystems muss man vorbereitet sein. Ist man es nicht, wird der korrupte Programmcode nicht funktionieren, gar eine Fehlermeldung ausgeben und sich damit verraten oder eventuell ungewollten Schaden anrichten. Das alles ist natürlich nicht im Sinn des Entwicklers. Die professionelle Viren-Entwicklung bleibt deshalb Leuten vorbehalten, die sehr viel Wissen, Zeit und Knowhow haben. Alle anderen werden lediglich stümperhafte Code-Knäuel zusammenschustern können. Ich würde so ein Projekt jedenfalls sicher nicht mit einem Hobby-Programmierer durchführen. Bei professionellen Proof-of-Concepts können dies wahre tickende Zeitbomben sein: Was ist, wenn die Infektion ausser Kontrolle gerät?