Viren im Trojaner, Viren in Delphi - wohin soll das noch führen? Dieser Standpunkt Sicherheit sucht die Antwort.

In den Security-Hinweisen vom 17. August ging es los:

Der Trojaner Koobface lädt inzwischen nicht nur neue Versionen von sich selbst nach, sondern gleichzeitig weitere Schädlinge wie z.B. die Viren Scribble, Virut und Vetor, die sich normalerweise über infizierte Dateien verbreiten. Richard Cohen von Sophos vermutet, dass das gar keine Absicht ist, sondern dass die Update-Dateien, die Koobface von anderen mit Koobface infizierten Rechner lädt, auf diesen Rechnern durch dort bereits vorher vorhandene Viren infiziert wurden. [...]

Das erinnert irgendwie an "Mumien, Monstren, Mutationen" und führt zur Frage

Viren im Trojaner - ein neuer Verbreitungsweg?

Computerviren gibt es seit 60 Jahren, und sie zeichnen sich u.a. dadurch aus, dass sie alle Dateien infizieren, die in ihr "Beuteschema" passen: Haben sie es auf .exe-Dateien abgesehen, infizieren sie alle .exe-Dateien, für die sie Schreibzugriff haben, haben sie es auf .doc-Dateien abgesehen, alle .doc-Dateien usw. usf. (wenn man mal den Fall außer Acht lässt, dass die Entwickler für bestimmte Dateien eine "die nicht"-Funktion implementiert haben). Natürlich erwischen sie dabei auch Dateien, die bereits mit anderen Viren infiziert sind - oder die selbst Schadsoftware sind. Ein Grippevirus schnappt sich auch jeden, den er kriegen kann, egal ob der schon eine Erkältung hat oder gerade von einem Einbruch zurück kommt. Im Fall von Koobface wurde nun zufällig die Datei infiziert, die von Koobface dann als Update auf andere Rechner heruntergeladen wird. Shit happens. Die Koobface-Programmierer werden darüber nicht sehr erfreut sein. Wenn sie schon andere Schädlinge "huckepack" transportieren, möchten sie das sicher gerne bezahlt bekommen, aber sie können kaum verhindern, das ihr Programm infiziert wird. Andernfalls müssten sie ihren eigenen Virenscanner mitbringen, und das sähe doch etwas merkwürdig aus. Ist das also ein neuer Verbreitungsweg für Viren? Gibt es demnächst einen Virus, der sich gezielt z.B. in Conficker/Downadup-Dateien einnistet? Das klingt zwar verlockend, klappt aber nicht. Im Fall von Conficker/Downadup, der zuletzt am 7. April Code nachgeladen hat, haben dessen Entwickler vorgesorgt und den nachgeladenen Code verschlüsselt. Sie wollen ja nicht, dass man ihnen z.B. einen Code zum Löschen des Wurms unterschiebt. Der jetzt befallene Schädling Koobface lädt dagegen einfache ausführbare Dateien von anderen mit ihm infizierten Rechnern nach und führt die ungeprüft aus. Nachdem er dadurch das Opfer eines Virus geworden ist, werden die Entwickler sicher Schutzmaßnahmen ergreifen und den nachgeladenen Code verschlüsseln und/oder prüfen.

Dann vielleicht stattdessen Viren im Compiler?

Am Dienstag tauchte der "Delphi-Virus" auf, siehe Security-Hinweise vom 19., 20. und 21. August: Ein Virus schleust seinen Code in einige ältere Versionen der Delphi-Entwicklungsumgebung ein und sorgt dafür, dass alle danach kompilierten Programme den Virus enthalten.

Viren, die Entwicklungsumgebungen infizieren, sind theoretisch ein alter Hut. Persönlich ist mir da sofort die erste Vorlesung zur IT-Sicherheit eingefallen, die ich gehört habe - irgendwann Anfang bis Mitte der 90er Jahre des letzten Jahrhunderts (IT-mäßig also kurz nach der Steinzeit). Andreas Pfitzmann hat die Vorlesung mit dem Titel "Sicherheit in Rechnernetzen" gehalten und sowohl die transitive Ausbreitung von Fehlern als auch "transitive Trojanische Pferde" erwähnt. Eine neuere Version des Skripts ist online verfügbar, "transitive Trojanische Pferde" werden darin so definiert (S. 11):

Üblicherweise stellt man sich auch vor, daß ein Trojanisches Pferd vom Täter direkt dort untergebracht werden muß, wo es subversiv wirken soll. Auch diese Vorstellung ist falsch: Werden beim Entwurf Hilfsmittel verwendet (z.B. Compiler), so kann sowohl der Entwerfer als auch das Entwurfshilfsmittel ein Trojanisches Pferd im Entwurf unterbringen. Da mit Entwurfshilfsmitteln weitere Entwurfshilfsmittel entworfen werden, gilt dies rekursiv, so daß sich ein Trojanisches Pferd in der transitiven Hülle aller Entwürfe ausbreiten kann, an denen sein Gastgebersystem direkt oder indirekt beteiligt war [Thom_84, Pfit_89]. Ich spreche deshalb von transitiven Trojanischen Pferden.

Thom_84 ist der Artikel 'Reflections on Trusting Trust' von Ken Thompson, auf den an mehreren Stellen in Hinblick auf den Delphi-Virus verwiesen wird, z.B. in einem Eintrag im Handler's Diary des ISC, in dem diese PDF-Version des Artikels verlinkt ist.

Delphi-Virus in harmlosen Programmen und Trojanern - es klappt!

Der Delphi-Virus wurde außer in einer Vielzahl harmloser Programme auch in mehreren Banking-Trojanern gefunden, wie z.B. Graham Cluley von Sophos berichtet hat. Das Prinzip "Verbreitung durch Infizierung des Compilers" klappt also allen Anschein nach sehr gut. Was jetzt nur noch fehlt, ist eine schädliche Nutzlast. Und aus Sicht der Cyberkriminellen wäre es sicher auch wünschenswert, aktuellere Entwicklungsumgebungen zu infizieren. Ach ja, eine Tarnfunktion für den Schadcode wäre auch nicht schlecht, der aktuelle Virus lässt sich sehr leicht erkennen, über den stolpert ja jede noch so simple Signaturerkennung. Aber das sind alles Probleme, die sich mit mehr oder weniger viel Aufwand lösen lassen. Und getreu dem Motto "Wo ein Proof of Concept ist, ist bald auch ein Schädling" wird so ein "Entwicklungsumgebungs-Virus" mit Schadfunktion früher oder später auftauchen. Die spannende Frage: Kann man eine Infizierung der Entwicklungsumgebung verhindern? Für die Antwort schalten wir um zu Radio Eriwan: "Im Prinzip ja, aber..."

1. "aber": Um zu verhindern, das ein Virus Libraries manipuliert, kann man die Verschlüsseln oder Prüfsummen dafür berechnen - dann kann der Virus aber die Entschlüsselungs- oder Prüffunktion manipulieren und dadurch den Schutz umgehen.

2. "aber": Man könnte dem Prinzip der geringstmöglichen Privilegierung folgend das Schreiben der zur Entwicklungsumgebung gehörenden Libraries verbieten, aber dann kann sich der Virus immer noch in die zum jeweiligen entwickelten Programm gehörenden Libraries einschleusen, und die müssen für den Benutzer beschreibbar sein.

3. "aber": Selbst wenn man eine Manipulation der Binärdateien verhindert, kann der Virus sich immer noch in die Quelltexte der jeweiligen entwickelten Programme einschleusen. Notfalls, indem er den Editor infiziert.

Es gibt noch mehr "aber", aber da der Text schon lang genug ist, kürze ich es ab: Man kann nicht mit 100%iger Sicherheit ausschließen, dass die Entwicklungsumgebung infiziert werden kann. Aber man kann durch geeignete Maßnahmen, vor allem natürlich aktuelle Virenscanner und vorsichtigen Umgang mit fremden Dateien, verhindern, dass Schädlinge die Entwicklungsumgebung bzw. das System, auf dem sie läuft, überhaupt erreichen. Die Mühe hat sich bisher niemand gemacht, aber jetzt ist es an der Zeit, sich darüber Gedanken zu machen und diese Gedanken dann auch umzusetzen. Ebenso ist nun vor der Veröffentlichung des fertigen Programms eine Prüfung auf Virenbefall notwendig - auch das war bisher eigentlich überflüssig und wurde kaum gemacht, und wohin das führt, sieht man ja.

Fazit

Um das Problem der mit Viren infizierten Schadsoftware werden sich die Cyberkriminellen schon kümmern. Uns kann es eigentlich egal sein, ob ein Schädling nun solo durch die Netze kreist oder ob er noch ein paar blinde Passagiere dabei hat - schon der erste Schädling ist unerwünscht.

Anders sieht es bei den Viren für Entwicklungsumgebungen aus, um die muss sich in Zukunft jeder Entwickler kümmern. Jede Datei, die auf ein System mit einer Entwicklungsumgebung kopiert wird, muss in Zukunft auf Schädlingsbefall geprüft werden. Und ebenso muss jedes erstellte Programm vor der Weitergabe auf Schädlingsbefall geprüft werden. Nur, weil man selbst keine Schadfunktion geschrieben hat, bedeutet das noch lange nicht, das nicht ein Dritter eine eingeschmuggelt hat.

Carsten Eilers