Bedrohung

Skriptviren

Schwarzweißmalerei

Von Ralph Dombach, München

Spätestens die LoveLetter-Lawine im Mai hat gezeigt, dass der Windows Scripting Host in der Standardkonfiguration erhebliches Risiko- und Missbrauchspotenzial aufweist. Auch wer nicht gleich zur Radikalkur "Deinstallation" greifen will oder kann, hat jedoch Möglichkeiten, die Gefahren zu verringern.

Wer auf die Nutzung des Windows Scripting Host (WSH) verzichten kann, fährt am sichersten, indem er diese Systemkomponente gar nicht erst installiert bzw. die Defaultinstallation unter Windows 98 und Windows 2000 zurücksetzt und den WSH entfernt (siehe [1]). Denn ohne den WSH-Interpreter sind auch zerstörerische VB-Scripts nur eine harmlose Ansammlung von Textzeichen. Diese Tatsache blieb leider während der Hysterie um LoveLetter unerwähnt. So hätte zwar ein "Liebesbrief" einen Anwender ohne WSH erreichen können, auf dessen PC wäre es dem Wurm aber nicht möglich gewesen, sich im System einzunisten, Dateien zu löschen oder sich an andere Anwender via E-Mail zu verschicken. Was bleibt, ist relativ harmloser Datenmüll. Denn ein Doppelklick per Maus auf die Dateianlage LOVE-LETTER-FOR-YOU.TXT.vbs führt nur zu einer Fehlermeldung bzw. Benutzeranfrage, wenn der Namenserweiterung ".VBS" keine Anwendung zugeordnet ist.

Wer seine Systeme ohne WSH betreibt, ist also vor VBS-Schädlingen wie LoveLetter sicher. Allerdings ist solche Schwarzweißmalerei nicht sehr hilfreich. Denn der WSH stellt ein äußerst nützliches Werkzeug dar, auf dessen Möglichkeiten Systemadministratoren und Benutzerservice lange warten mussten. Denn mit eigenen Visual-Basic-Scripts (VBS) ist es erstmals möglich, auch komplexe Systemarbeiten (Software-Verteilung, Programmanpassungen, Backup-Routinen usw.) relativ einfach zu programmieren und so Betreuungsaufwand und -kosten zu reduzieren. Und wie das Sprichwort schon sagt, gibt es zwischen Weiß (auf WSH verzichten) und Schwarz (den WSH nutzen) noch viele Grautöne, welche die Nutzung des WSH erlauben und gleichzeitig die Bedrohung durch Viren und Würmer reduzieren.

MS Patches

Ein nahe liegender Schritt sind zwei von Microsoft offerierte Updates für Outlook 98 und 2000 (nicht Outlook Express). Das voluminöse Service Release 1 (SR1) für MS Office enthält bereits einen Patch für Outlook, der die Möglichkeit entfernt, Dateien direkt aus dem Mailprogramm zu öffnen. Auf Dateianhänge, die per Mausklick direkt ausführbar sind, erhält der Anwender nach Installation des Updates keinen direkten Zugriff mehr. Sie können aus Outlook heraus nicht mehr gestartet oder angezeigt, sondern nur noch gespeichert werden. Als "unsichere" Dateianlagen gelten rund 40 vordefinierte Namenserweiterungen: u.a. BAS, BAT, COM, EXE, HLP, INF, JS, LNK, REG, SHS, URL, VB, VBE, VBS und WSH.

Ebenfalls von dieser Maßnahme betroffen sind ZIP-Dateien. Die Definition zusätzlicher Achivformate (LHA, RAR, PAC usw.) ist über Registry-Keys möglich. Beim Zugriff auf die gespeicherten Archiv-Inhalte können dann die üblichen Virenschutzprogramme zumindest versuchen, bekannte Gefahren zu erkennen.

Gegen eine geringe Gebühr bietet Microsoft das 26-40MB große SR1 alternativ zum Download auch auf einer CD an - allerdings mit 6 bis 8 Wochen Lieferzeit. Die WWW-Site  http://www.microsoft.com/germany/office/office2000sr-1/ informiert im Detail über die Ergänzungen und Installationsvoraussetzungen und ermöglicht den direkten Download.

Ein separates Sicherheitsupdate, das aber die Installation des SR1 voraussetzt, geht noch einen Schritt weiter: Nach dem Einspielen ist bereits der Empfang ausführbarer Dateien als Attachment (Mail-Anhang) gesperrt. Der Anwender erhält dann lediglich einen Hinweis auf die fehlenden Teile der Nachricht. Laut Microsoft können Administratoren die Einschränkungen mit den Policy-Tools beeinflussen. So könnte man damit z.B. auch den Eingang von Dateianlagen verhindern, die aus anderen Gründen unerwünscht sind.

Adressbuchschutz

Weiterhin überwacht das Sicherheitsupdate das Microsoft Adressbuch: Um virulentem Programmcode die Nutzung der MAPI-Schnittstelle (Message Application Program Interface) zum E-Mail-Versand aus Outlook zu erschweren, kann eine E-Mail beim Zugriff auf das Adressbuch prinzipiell nur noch verschickt werden, wenn der Anwender das per Klick auf eine "Senden" -Schaltfläche bestätigt. Makrofunktionen, welche dies automatisieren, sind blockiert. Die zusätzliche Abfrage erscheint natürlich nach dem Update auch bei erwünschtem Serien- Mail-Versand aus anderen Anwendungen (z.B. Word) heraus, kann aber auf Anweisung des Benutzers für ein bestimmtes Zeitfenster ausgesetzt werden.

Ein weiterer Schutzfaktor des Updates besteht darin, für Outlook die Sicherheitseinstellungen der "Eingeschränkten Sites" zu aktivieren. Normalerweise gelten für die E-Mail die Einstellungen der "Internetzone" , die in der Standardinstallation auf "mittlere Sicherheit" gesetzt sind und nahezu jegliche aktiven Inhalte erlauben. Für die "Eingeschränkten Sites" gilt von Anfang an die so genannte "hohe Sicherheit" , was allerdings noch immer die Ausführung von Active Scripting (JavaScript, VB-Script usw.) sowie das Scripting von ActiveX-Steuerlementen, die "für Scripting sicher" sind erlaubt. Gerade hierbei kam es in der Vergangenheit zu Sicherheitsmängeln auf Grund von fehlerhaften Unbedenklichkeitsbescheinigungen durch Microsoft.

Einen drastisch erhöhten Schutz gegen aktive Inhalte in E-Mails erzielt man hier erst, wenn man über die benutzerdefinierten Einstellungen der Sicherheitszonen jegliche aktiven Inhalte deaktiviert (Systemsteuerung/Internetoptionen/Sicherheit). Wichtig ist dabei zu beachten, dass damit aber noch kein Schutz gegen Attachments erzielt wird: Sobald diese als Datei auf der Festplatte vorliegen (und sei es in einem temporären Verzeichnis), gelten die Einstellungen für den eigenen Arbeitsplatz bzw. das "Lokale Intranet" .

Ob die Einschränkungen der Outlook-Funktionen in Bezug auf Dateianhänge einen Sicherheitsgewinn darstellen oder den Benutzer nur unnötig bevormunden (und zur Umgehung animieren) oder womöglich sogar in seiner Produktivität behindern, muss jeder Administrator aufmerksam abwägen. Auch Microsoft empfiehlt derartige Radikalkuren nicht pauschal, sondern nur nach sorgfältiger Prüfung für größere Netze, in denen bestimmte Arbeitsplätze üblicherweise nicht mit Attachments umgehen müssen.

Die Microsoft-Updates erschweren zwar das Eindringen von gefährlichem "Mobile Code" per E-Mail. Riskante VB-Script-Programme lassen sich aber auch per WWW-Download, Diskette oder CD einschleppen. Daher sollte auf jeden Fall ein erprobter Virenscanner auf dem System laufen. Möglichst auch als Wächter im Hintergrund, der jede Datei vor dem Öffnen auf bekannte Gefahren hin abklopft - leider ist das nicht bei allen Scannern die Voreinstellung.

Virenwächter

Die größte Schwachstelle der Virenwächter liegt aber darin, dass in der Regel nur bekannte Gefahren gefunden werden: Ein Scanner kann einen Virus, Wurm oder ein Trojanisches Pferd erst als solche identifizieren, wenn der Übeltäter bereits analysiert wurde und eine Signatur für die Suche existiert. Zwar haben die Hersteller von Antiviren-(AV-)Software viel dazugelernt und reagieren inzwischen mit großer Schnelligkeit, aber dass dies angesichts der minimalen Vorwarnzeiten gerade der Script-Viren immer noch zu langsam ist, konnte man beim LoveLetter leidvoll miterleben.

Die meisten AV-Produkte verfügen zwar auch über eine so genannte heuristische Suchmethode, bei der nach virulenten Eigenschaften gesucht wird, aber solche Methoden sind gerade bei VBS-Viren und Würmern nur schwer anzuwenden. Denn der Programmcode eines VB-Scripts ist ein normaler ASCII-Text, und es muss sehr genau analysiert werden, ob es sich um ein Virus oder die Beschreibung eines hilfreichen Makros handelt. Hier fehlt es offensichtlich noch an einschlägigen Erfahrungen.

Trotz allem sollte ein Virenscanner, der stetig mit aktuellen Signaturen versorgt wird, so selbstverständlich auf einem System laufen, wie man im Auto den Sicherheitsgurt anlegt. Genauso wenig wie ein Sicherheitsgurt zu unvorsichtigem Fahren verleiten sollte, darf man sich aber auch nicht allein auf den Scanner verlassen und im Vertrauen darauf eingehende Dateien achtlos starten.

Skript-Umleitung

Wird der WSH produktiv genutzt, so kann es z.B. für die eigene Arbeitsumgebung schon genügen, wenn man die Ausführung fremder, nicht erwünschter VB-Scripts verhindert. Die einfachste Art dies zu erreichen besteht darin, die Verknüpfung zum Interpreter WSCRIPT.EXE aufzulösen, indem man mit dem Systemwerkzeug REGEDIT. EXE (Start/Ausführen: regedit) im Registry-Zweig HKEY_CLASSES_ROOT das Kürzel ".VBS" sucht und durch eine selbst gewählte, bislang unbenutzte Erweiterung ersetzt (z.B. ".ZZU" ). Künftig kann der Anwender dann nur noch WSH-Scripts mit der Erweiterung ZZU per Mausklick starten. Ein Doppelklick auf eine .VBS-Datei führt nur zur Frage nach einer Anwendung, welche die Erweiterung VBS bearbeiten kann.

Das Umbenennen der WSH-Dateierweiterungen schützt vor versehentlichem Start fremder Scripts.

Durch diese Maßnahme können auch scheinbare .TXT-Dateianlagen (wie im Fall LoveLetter) nicht mehr versehentlich gestartet werden, da die Zuordnung zu WSCRIPT.EXE fehlt. Eine einfache Methode mit hohem Wirkungsgrad, aber einem gewissen Verwirrungs-Potenzial. Neben .VBS sind - je nach Konfiguration - häufig auch die Erweiterungen VBE, JS, JSE, WSF und WSH mit dem Scripting Host verknüpft. Sie sollten dann ebenfalls umgelenkt werden. Zu überlegen ist weiterhin, gleichzeitig den WSH-DOS-Interpreter CSCRIPT.EXE umzubenennen oder zu löschen, da sonst auf Befehlszeilenebene noch .VBS-Dateien ausgeführt werden können.

Sicherheitsabfrage

Eine recht pfiffige Lösung bietet Chris Combs mit seinem ANTIVBS an ( http://aardvarko.com welches das Betriebssystem so modifiziert, dass Mausklicks auf eine .VBS-Datei nicht den Interpreter WSCRIPT aktivieren, sondern einen Batchjob, der vor der Ausführung dieser Datei warnt. Möchte man trotzdem das Tool ausführen, klickt man mit der rechten Maustaste und wählt dann im eingeblendeten Kontextmenü die Option "Execute" aus. Das Skript lässt sich ohne großen Aufwand auf deutsche Menüeinträge umschreiben und stellt eine einfache Maßnahme dar, die den Anwender über eine mögliche Gefahr informiert und zumindest dafür sorgt, dass eine .VBS-Datei versehentlich ausgeführt wird.

Chris Combs AntiVBS ändert per Installationsskript die VBS-Verknüpfungen.

Die Grundidee von Chris Combs kann man auch ohne sein Skript für eigene Warnmeldungen durch ein "Umbiegen" der VBS-Verknüpfung verwenden [3]. Dazu ist folgende Vorgehensweise erforderlich:

• Doppelklick auf "Arbeitsplatz" ,
• in der Menüzeile "Ansicht" die "Ordneroptionen" auswählen,
• die Karteikarte "Dateitypen" auswählen,
• in der Listbox für die "Registrierten Dateitypen" nach dem Eintrag "Skriptdatei für VBScript" oder "VBScript-Skriptdatei" suchen und die Schaltfläche "Bearbeiten" anwählen,
• den Vorgang "Öffnen" anwählen und die Schaltfläche "Bearbeiten" anklicken,
• im nachfolgenden Editierfenster den Defaultwert "C:\Windows\WSCRIPT..." durch einen eigenen Programmaufruf ersetzen.

Über die Ordneroptionen kann man ein anderes Programm mit .VBS verknüpfen und erst daraus - nach einer Warnung oder Prüfung - das Skript starten.

Idealerweise sollte das aufgerufene eigene Programm eine Funktion enthalten, die sicherstellt, dass nur vertrauenswürdige .VBS-Dateien zur Ausführung gelangen. Um dies zu erreichen, sind mehrere Ansätze möglich:

• Der einfachste Fall gibt lediglich eine Warnung aus, die den Anwender informiert, dass er eine .VBS-Datei startet. Dies lässt sich beispielsweise durch einen Batchjob erreichen, der erst die Warnmitteilung ausgibt und nach einer Bestätigung durch den Anwender die .VBS-Datei ausführt (siehe Kasten).
• In einem fortgeschrittenen Stadium wäre es denkbar, in der ersten Zeile einer Datei nach
• einem Copyright-Vermerk zu suchen (etwa "© XYZ GmbH; Internes VB-Script magic 8&7338" ) und das Script automatisch zu starten, wenn und nur wenn genau der erwartete Vermerk gefunden wurde.
• Will man ganz sicher gehen und nur dann ein VB-Script starten, wenn es sich mit hoher Wahrscheinlichkeit um eine als vertrauenswürdig eingestufte Routine handelt, dann sollte man anhand einer digitalen Signatur oder zumindest eines einfachen Prüfkriteriums auch die Integrität der Programmdatei verifizieren. Im einfachsten Fall kann dies die Dateigröße sein, schon besser ist eine Prüfsumme, als wirklich sicher kann aber nur eine kryptographische Signatur gelten.

@echo off
echo *** Wollen Sie das VBS-Programm %1 wirklich ausführen?
choice /c:JN ausführen?
if errorlevel 2 goto nein
start wscript.exe "%1"
:nein rem Start verhindert

Der große Vorteil der Verknüpfungsumleitung besteht darin, dass beliebige Aktionen ausgeführt werden können, bevor die VBS-Datei selbst startet. Hiermit lässt sich auch leicht ein spezifischer "On-Access-Virenscanner" einrichten, der zielgerichtet nur VB-Scripts vor dem Aufruf prüft, ohne die Systemperformance oder -stabilität durch einen generellen Hintergrundwächter zu beeinflussen (allerdings bleibt die Mahnung bestehen, dass damit derzeit nur bekannte Script-Viren abzufangen sind).

Durchblick für Anwender

Bei der Erkennung potenziell gefährlicher Skripte helfen aber bereits weit weniger aufwändige Maßnahmen, die beim kundigen Anwender für klare Sicht sorgen: LoveLetter konnte sich u.a. deshalb so weit und schnell ausbreiten, weil der Dateianhang dem Anwender vorgaukelte, eine reine Textdatei (.TXT) zu sein, die man bekanntlich gefahrlos öffnen darf. Dass die "Erweiterung" .txt bei LOVE-LETTER-FOR-YOU.TXT. vbs zum Dateinamen gehörte und nicht die echte Namenserweiterung darstellt, erkennt man nur schwer auf Windows-Systemen im Auslieferungszustand, die bekannte Dateierweiterungen (wie .TXT oder .VBS) normalerweise nicht anzeigen.

Damit der Anwender eine eingegangene Datei richtig einschätzen kann, braucht er die Anzeige der Dateierweiterung.

Die Identifikation über das dargestellte Icon bietet auch keinen verlässlichen Anhaltspunkt: Mit ein paar Programmzeilen mehr hätte LoveLetter allen befallenen Dateien (.txt.VBS, .jpg.VBS usw.) auch noch das richtige "Aussehen" bescheren können. Erst wenn man die Option aktiviert, um Dateinamen immer in voller Länge anzuzeigen, kann man sicher erkennen, um welchen Dateityp es sich handelt. Dazu sollte man im Windows-Explorer unter dem Menüpunkt Ansicht/Ordneroptionen (W98) bzw. Extras/Ordneroptionen (W2000) in der Karteikarte "Ansicht" die Option "Dateinamenerweiterung bei bekannten Dateitypen ausblenden" deaktivieren. Leider gibt es Ausnahmen von der Regel: Für .SHS-Dateien zeigt Windows prinzipiell keine Dateierweiterungen an, solange man nicht einen speziellen Registry-Key löscht (HKEY_ CLASSES_ROOT\ShellScarp\NeverShow Ext).

Bei Scrap-Dateien (.SHS) zeigt Windows unabhängig von den Ordneroptionen keine Dateierweiterung an.

Erst wenn man den Registry-Key "NeverShowExt" löscht, kann man auch SHS-Dateien sicher erkennen.

All das bewirkt natürlich nur dann etwas, wenn der Blick auf eine potenziell gefährliche Extension beim Betrachter die Alarmglocken schrillen lässt. Im Allgemeinen steht und fällt der Schutz des eigenen Rechners oder Netzwerks aber ohnehin mit der letzten Bastion "Anwender" . Wer in seinem Unternehmen Benutzer beherbergt, die achtlos jegliche eingehenden Dateien starten, handelt sich einen enormen technischen und personellen Aufwand ein, um die "gefährlichen Benutzer" von gefährlichen Inhalten abzuschirmen.

Zudem darf man orakeln, dass alle Schutzmaßnahmen irgendwann und auf unvorhersehbare Weise von einem cleveren Virusprogrammierer wieder überwunden werden dürften. Schutzmechanismen auf Anwendungsebene sind zudem wirkungslos, wenn die Übeltäter sich auf die Systemebene begeben und die installierten Vorrichtungen einfach unterlaufen. Der wirkungsvollste Schutz besteht daher immer noch darin, die zu schützenden Anwender mit ins Boot zu holen und umfassend über die Bedrohung aufzuklären. Die jüngste Geschichte belegt hier eklatante Versäumnisse: Eigentlich hätte der LoveLetter-Wurm ein gutes Jahr nach nach dem Melissa-Virus nicht wieder zu einem derartigen Desaster führen dürfen.

Ralph Dombach ist Sicherheitsberater in München.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2000, Seite 8

Zurück zum Inhalt