Aktuelle Entwicklungen im Bereich der Makroviren

© 1999 Stefan Kurtzhals/VHM

VBScript-Viren auf dem Vormarsch?

VBScript ist eine "Light"-Variante von VBA (Visual Basic for Applications) und wurde mit dem Windows Scripting Host (WSH) in Microsoft Windows 98 und dem Internet Explorer 5.0 eingeführt. VBS besitzt die gleiche Funktionalität wie das bisher von den Makroviren verwendete VBA, der Programmcode liegt jedoch als ASCII-Text vor, welcher direkt vom Windows Scripting Host ausgeführt wird. Da VBScript-Dateien mit einem ASCII-Editor einfach einsehbar sind, bietet Microsoft ein Tool an, mit dem VBScript-Dateien verschlüsselt werden können, daß bearbeitete Script bleibt voll funktionsfähig. Dieses Tool nutzten die Virenprogrammierer direkt aus, um die Erkennung von VBS-Viren zu erschweren. Zum Glück läßt sich diese Verschlüsselung problemlos aufheben (die dafür notwendigen Tabellen sind übrigens ohne große Mühe in der Datei VBSCRIPT.DLL zu finden). HTML-Dokumente können ebenfalls VB-Scripte enthalten, diese werden dann beim Betrachten des Dokuments mit dem Microsoft Explorer aktiviert - womit Microsoft die Erstellung von HTML-Viren ermöglicht hat.

Mit VBS lassen sich problemlos die Registry oder Dateien verändern, womit eine ausreichende Funktionalität für die Programmierung eines Virus vorhanden ist. Insbesondere mit dem CreateObject-Befehl kann ein VBScript eine Vielzahl von Objekten wie etwa ein Dateisystemobjekt oder ein Word-Dokument erzeugen und manipulieren. Damit sind unter anderen auch Cross-Application-Viren möglich, die gleich mehrere Office-Anwendungen infizieren. Ein Beispiel hierfür ist das O97M/Hopper.E-Virus oder W97M/Coldape, welche VBS- und Word-Dateien infizieren. Während des Übergangs von VBScript nach Word kann ein VBVirus übrigens den in Microsoft Office eingebauten Virenschutz problemlos per Registrymanipulation ausschalten. Beim Ausführen von VBScript-Programmen welche ein FileSystemObject erzeugen, wird bei der Standard-Sicherheiteinstellung normalerweise ein Warnhinweis angezeigt. Einmal aktiviert kann ein solches VBScript allerdings diesen Schutz ebenfalls permanent ausschalten.

Bisher waren VBS-Viren kaum verbreitet, dies hat sich in letzter Zeit geändert, da mit dem Erscheinen von Microsoft Office 2000, Internet Explorer 5.0 und Windows 2000 (Release Candidates) der Windows Scripting Host automatisch mitinstalliert wird und damit den VBS-Viren ein weitere Verbreitung als bisher ermöglicht. VBS/Freelink ist bis jetzt der erste VBS-Virus der im größeren Umfang bei Anwendern aufgetreten ist. VBS/Freelink verwendet eine einfache Verschlüsselung für alle enthaltenen Strings (dem Autor war offenbar nicht der VBS-Encryptor von Microsoft bekannt). Das Virus erzeugt im SYSTEM-Verzeichnis eine Kopie des Virus unter dem Namen "RUNDLL.VBS" und trägt diese Datei in Registry ein damit der Virus bei jedem Systemstart ausgeführt wird. Ähnlich wie W97M/Melissa enthält das Virus ein Mass-Mailing-Funktion und verschickt sich selbst als Attachment (mit dem Namen "LINK.VBS") an alle Einträge im Email-Adressbuch des Benutzers. Zusätzlich sucht VBS/Freelink nach aktiven Netzwerkverknüpfungen und erzeugt im Root dieser Laufwerke ein Kopie von sich selbst. Außerdem werden die IRC-Chatclients mIRC und pIRCH mit entsprechenden .INI-Dateien infiziert, welche VBS/Freelink verbreiten sobald der Anwender ein IRC-Channel betritt.
Ein weiterer bekannter VBS-Virus ist VBS/BubbleBoy, welches im Gegensatz zu den Pressemitteilungen mancher Antiviren-Firmen bisher nicht In The Wild aufgetreten ist. Eigentlich ist VBS/BubbleBoy kein besonders interessanter Makrovirus - allerdings nutzt es eine Sicherheitslücke in Microsoft Outlook und Outlook Express aus, welche ein Aktivieren des VBScripts ohne jeden Warnhinweis ermöglicht. Der Virus wird bereits beim Betrachten der Mail aktiviert und muß nicht erst, wie bisher üblich, über ein Attachment aktiviert werden. Unter Outlook Express reicht sogar das Betrachten der Mail im Vorschaufenster um den Virus zu aktivieren. Geschieht dies, erzeugt der Virus über eine ActiveX-Komponente (die offenbar als "sicher" markiert ist) eine infizierte .HTA-Datei im Autostart-Ordner. Hierbei wird allerdings der Verzeichnisname fest vorgegeben, daher ist VBS/BubbleBoy nur unter der englischen Version von Windows 9x funktionsfähig (Installation in "C:\WINDOWS"). Wie VBS/Freelink enthält VBS/BubbleBoy eine Mass-Mailing-Funktion und verteilt sich selbst per Email an andere Anwender. Das Virus führt die Mailverbreitung jedoch nur einmal pro infiziertes System aus.
Beide Viren stammen vom selben Autor und sind auf dessen Homepage zu finden, was leider nach den Pressemitteilungen über VBS/BubbleBoy dazu führen wird, daß viele andere Virenprogrammierer ebenfalls die erwähnte Sicherheitslücke ausnutzen werden. Ein Patch von Microsoft, der diese Sicherheitslücke behebt ist schon länger vorhanden, allerdings nicht auf jeden System installiert.

Probleme bei der Erkennung von Office 97/2000-Makroviren

Mit dem Umstieg von Office 95 auf Office 97 führte Microsoft die gemeinsame Makrosprache VBA5 ein und ersetzte damit WordBasic (Word95) und VBA3 (Excel95). Der interne Aufbau von VBA5 weitaus komplexer als der von WordBasic und unterscheidet sich leider auch recht stark von VBA3. Microsoft gibt keine brauchbaren Informationen über das interne Dateiformat frei, so daß bis heute kein Antiviren-Programm VBA5-Makros wirklich korrekt bearbeiten und erkennen kann.

Alle Office-Dokumente (bis auf Access-Datenbanken) werden im sogenannten OLE COM-Format (Compound Object Model) gespeichert. OLE COM-Dateien sind intern wie eine FAT-Festplatte strukturiert und in Sektoren, FAT, Dateien (Streams) und Unterverzeichnisse (Storages) unterteilt. Schon alleine um dieses Dateiformat zu verstehen, benötigten die Antiviren-Firmen lange Zeit und leider waren ältere Versionen der für OLE-Dateien zuständigen Systemdatei "OLE32.DLL" fehlerhaft. Durch diesen Fehler wurden unter Word95 Makros unter bisher nicht geklärten Umständen geringfügig beschädigt. Dies führte zu eine großen Anzahl von "natürlichen" Virenmutationen, wie die vielen hundert Varianten der WM/CAP und WM/Npad-Familie zeigen. Mit Windows 2000 hat Microsoft das OLE COM-Format erweitert und erlaubt eine variable Sektorengröße - was viele Antiviren-Programme bis jetzt noch nicht korrekt handhaben können.

Der grundlegende Aufbau eines Word95-Dokuments mit Makros wird in Bild 1 gezeigt. Alle benötigten Daten befinden sich in einem Stream ("WordDocument") und sind relativ leicht interpretierbar. WordBasic verwendet Tokens und läßt sich leicht analysieren und "decompilieren".

Der Header (FIB) enthält unter anderen die Angaben ob die Datei ein Dokument oder eine Vorlage ist und die Position und Größe des TDT-Blocks. Der TDT-Block enthält alle Angaben über die einzelnen Makros (Name, Größe, Position innerhalb des WordDocument-Streams, Verschlüsselungs-Byte usw.)

VBA5 unterscheidet zwischen Modulen oder Klassen und Makros. Innerhalb eines Moduls können mehrere Makros enthalten sein. In VBA5-Dateien sind die Informationen für die Module bzw. Makros über mehrere Streams verteilt. Der "1Table"-Stream enthält jetzt unter anderen die TDT (welche bei der Reinigung korrigiert werden muß). Alle anderen Makro-relevanten Daten befinden sich im "VBA"-Storage (dieser ist in der Regel selber in einen weiteren Storage ablegt, z.B. "Macros" bei Word97). Die "dir"- und "__VBA_PROJECT"-Streams enthalten beide fast identische Informationen, wobei diese im "dir"-Stream in komprimierter Form gespeichert sind. Hier befinden sich unter anderen die Namen aller vorhandenen Module und die direkten Symbole für den PCode. "ThisDocument" (der Name ist abhängig von der Sprache und von der Office-Anwendung und kann z.B. auch "DiesesDokument" oder "ThisWorkbook" lauten) ist ein Klassenmodul und ist in jedem Office-Dokument mit Makros enthalten.
Der eigentliche Programmcode befindet sich in einen eigenen Modul-Stream, wurde das Makro ausgeführt und danach das Dokument gespeichert, befinden sich mehrere "__SRP"-Streams in der Datei. Diese enthalten den fertig compilierten Programmcode, den Office zur beschleunigten Ausführung der Makros beibehält. In dem Modulstream befindet sich der PCode, welcher aus Tokens aufgebaut ist und zusätzlich Informationen aus den Tabellen mit den direkten Symbolen (__VBA_PROJECT-Stream) und den indirekten Symbolen benötigt. Hier tritt bereits das erste Problem bei vielen Virenscannern auf. Durch die Komplexität der Strukturen sind viele Antiviren-Firmen nicht in der Lage oder nicht gewollt den PCode vollständig zu bearbeiten. So kann es vorkommen das ein Antiviren-Programm die folgenden Codezeilen nicht unterscheiden kann:

Der Modulstream beinhaltet zusätzlich noch den vollständigen, komprimierten Quelltext der Makros in ASCII-Form. Damit existieren in einer Datei zwei bzw. drei Kopien eines Virus und es ist nicht ohne weiteres festzustellen, welche davon von Microsoft Office wirklich ausgeführt wird. Fast alle Antiviren-Programme überprüfen lediglich den PCode, der bisher als eigentlicher Programmcode galt. Der ASCII-Quelltext wird nicht für die Ausführung verwendet, selbst für die Anzeige des Quelltexts im VBA-Editor nicht. Sind __SRP-Streams vorhanden, kann es sein das Microsoft Office diese ausführt und den PCode völlig ignoriert. Entscheidend ist die VBA-Versionsnummer im __VBA_PROJECT-Stream und die Version von Office die der Anwender einsetzt. Stimmen beide Versionsnummern überein, wird ein vorhandener __SRP-Stream ausgeführt, ansonsten der PCode. Stimmen die Versionsnummern nicht überein, verwendet Office den komprimierten Quelltext um den PCode erneut zu erzeugen. Dies ist offenbar ein Mechanismus um Makros zwischen den verschiedenen Office-Versionen auszutauschen, denn damit ist Office97 in der Lage, Office 2000-Makros zu lesen und umgekehrt. Allerdings ist dies für die Antiviren-Programme problematisch, denn nun kann nicht mehr eindeutig festgestellt werden, welche Kopie des Virus letztendlich zur Ausführung kommt. Wird z.B. durch ein Fehler der OLE32.DLL der PCode beschädigt, stellt dies unter Office 97 eine neue Variante des Virus dar - unter Office 2000 jedoch nicht. Kein Antiviren-Programm überprüft zur Zeit, ob PCode und Sourcecode mit dem eigentlichen Virus übereinstimmen. Die __SRP-Streams sind nur temporär und werden gar nicht überprüft, leider aber auch von einigen wenigen Antiviren-Programmen nicht bei der Reinigung entfernt. So sind z.B. Fälle bekannt geworden, in dem nach der Reinigung die Modul-Streams entfernt, die __SRP-Streams aber erhalten blieben. X97M/Laroux war nach dieser Reinigung noch funktionsfähig, die betroffene Datei wird aber von keinen Virenscanner als infiziert erkannt. Ein weiteres Beispiel ist eine W97M/Melissa.U-infizierte Datei, die ebenfalls fehlerhaft gereinigt wurde. Der PCode wurde komplett entfernt, mehrfach fehlerhafte Quelltexte an falscher Position eingefügt und die VBA-Versionsnummer auf einen ungültigen Wert gesetzt. Damit wird der Sourcecode als eigentlicher Viruscode aktiviert - der Virus ist nicht gereinigt. Solche Beschädigungen bleiben nach der weiteren Verbreitung eines Virus normalerweise nicht erhalten, W97M/Melissa allerdings besitzt eine Mass-Mailing-Funktion und verschickt dabei das ursprüngliche Dokument - in diesem Fall die modifizierte Datei, in der etliche Virenscanner den Virus nicht mehr erkennen können.

Optimal wäre eine Überprüfung aller drei möglichen Positionen des Virus: PCode, SourceCode und Execode (__SRP-Streams). Dies würde allerdings den Suchvorgang der Virenscanner erheblich verlangsamen und bei der bereits existierenden Anzahl von VBA5/6-Makroviren (ca. 5000) ist eine Aktualisierung der Signaturdatenbanken ein nicht zu unterschätzender Aufwand.

Pseudo-Parasitische Makroviren - "Sandwiches"

Mit dem Service Release 1 (SR1) für das Microsoft Office97-Packet funktionierte der bis dahin übliche Ansatz eines Makrovirus zum Kopieren seines eigenen Modules nicht mehr:

Application.OrganizerCopy Source:=NormalTemplate.FullName, Destination:=ActiveDocument.FullName, Name:="Virus"

Das direkte Kopieren von Modulen aus der globalen Vorlage NORMAL.DOT in weitere Dokumente wurde unterbunden und damit alle hochkonvertierten WM-Viren und die älteren W97M-Viren funktionsunfähig. Die Virenprogrammierer erkannten jedoch schnell, wie sie diese Begrenzung umgehen konnten. Anstatt das komplette Virenmodul zu übertragen, kopieren die neueren Office97/2000-Makroviren den Quelltext. Dabei gibt es vier Möglichkeiten, den Sourcecode zu übertragen:

 .Import/.Export - Ersetzt den gesamten Quelltext im Modul
 .AddFromString  - Fügt Text am Ende des Quelltexts an
 .AddFromFile    - Fügt Text am Ende des Quelltexts an
 .InsertLine     - Fügt Text am Anfang des Quelltexts ein

Mittlerweile verwenden die moderneren Makroviren nicht mehr die .Import/.Export-Methode, da diese von jeder Heuristik erkannt wird. Die drei anderen Methoden haben jedoch unter Umständen einen nicht beabsichtigten Nebeneffekt. Geht der Virenprogrammierer davon aus, daß im Zielmodul kein Code vorhanden ist, oder vergißt er eventuell vorhandenen Anwendercode zu löschen, dann arbeiten Makroviren mit den oben genannten drei Infektionsmethoden pseudo-parasitisch. Bisher gibt es nur ein erfolglosen Versuch, einen parasitischen Makrovirus zu schreiben (W97M/Intended/Flesh), aber durch die oft fehlerhafte Programmierung der Makroviren können auch normale Makroviren parasitisch infizieren. Eine Kombination mehrerer Makroviren innerhalb eines Moduls wird "Sandwich" genannt, in vielen Fällen funktionieren diese Kombinationen aber nicht mehr. Der Grund hierfür ist der Umstand, daß VBA es nicht erlaubt, innerhalb eines Moduls zwei gleichnamige Sub/Function-Namen zu verwenden. Unter VBA wird zwischen Auto-Modulen (Modulen mit Namen wie AutoOpen und einer Sub "Main"), Auto-Makros (Sub AutoOpen()) und Event-Handler (Sub Document_Close()) unterschieden.
Ist ein gleichnamiges Auto-Makro und ein Auto-Modul vorhanden, wird das Auto-Modul nicht ausgeführt. Enthält das aktuelle Dokument ein Auto-Makro, und die NORMAL.DOT ebenfalls ein gleichnamiges Auto-Makro, wird eine Fehlermeldung von Microsoft Office angezeigt. Auto-Makros haben höhere Priorität als Event-Handler, eine Sub AutoOpen() wird also vor Document_Open() ausgeführt. Infizieren zwei Makroviren das gleiche Modul (häufig ist z.B. "ThisDocument") und benutzen beide den gleichen Event-Handler (z.B. Document_Close()) ist das Resultat nicht mehr replikationsfähig (und wird auch von vielen Virenscannern nicht mehr erkannt).
Verwenden beide Viren unterschiedliche Makronamen, entscheidet in der Regel die Reihenfolge der Infektion oder die Priorität der Makros, ob das Resultat ein funktionsfähiger Virus sein kann. Viele Makroviren verändern bei der Infektion Programmzeilen, z.B. wird der Name des Aktivierungsmakros von Document_Open() in Document_Close() geändert. Nennen wir einen solchen Virus "A" und nehmen wir an, daß bereits ein Virus "B" in "ThisDocument" vorhanden ist und Virus "A" ".AddFromString" verwendet. Damit wird der Virencode von Virus "A" an Virus "B" angefügt. Virus "A" adressiert jedoch die Programmzeilen die es manipulieren will direkt über Zeilennummern. Diese liegen jetzt jedoch im Bereich des Codes von Virus "B". Je nachdem ob an dieser Stelle wichtiger Programmcode liegt, ist das Resultat ein Beschädigung des Virus "A" so daß dieser in der Regel nicht mehr funktioniert. Noch problematischer sind polymorphe Makroviren der "W97M/Class"-Familie. Diese ersetzen jede 2. Programmzeile durch zufällig generierte Kommentare. Wird ein Modul jetzt von einem Virus wie etwa W97M/Brenda.A und einer Class-Variante (z.B. Class.D) infiziert, befindet sich Class.D an zweiter Stelle im Modul und durch die polymorphe Veränderung wird jede 2. Zeile von Brenda.A überschrieben. Einige Makroviren verwendet als Selbsttest eine Textabfrage, wie etwa ob die Zeile 5 des Quelltexts den Text "Rem Ich bin ein Virus" enthält. Verwendet einer der Viren in einem "Sandwich" diese Methode, kommt es zur Reinfektion des Virenmoduls, da der Infektionsmarker des einen Virus durch die Doppelinfektion verschoben wurde. So kann es vorkommen, daß ein Sandwich zwei Kopien des ersten und eine Kopie des zweiten Virus enthält (Reihenfolge Virus 1, Virus 2, Virus 1). Durch den doppelten Makronamen des einen Virus ist ein derartiger Sandwich nicht mehr funktionsfähig.

Die großen Probleme mit der Erkennung der solcher Kombinationen von Makroviren sind erstens die momentan gängige Methode der Virenerkennung der Antiviren-Programme. Diese arbeiten fast ausschließlich Modul-orientiert und nicht Makro-orientiert.
Das zweite Problem ist die Unberechenbarkeit solcher Makroviren-Kombinationen. Durch die häufig auftretende Beschädigung des einen Virus durch die polymorphe Funktion des zweiten Virus ist das Ergebnis oft nicht mehr exakt identifizierbar.