| Abstrakt: |
Skripting-Kolumne im Windows 2000 Magazin
Liebesbriefe unerwünscht!
Der Ruf des Windows Script Host (WSH) ist angeknackst seit der Love-Letter-Wurm der IT-Welt gezeigt hat, dass Windows Scripting nicht nur mächtig ist, sondern auch gefährlich sein kann. Dieser Artikel unserer Skripting-Kolumne zeigt die Sicherheitsvor- kehrungen, die der WSH 5.6 inzwischen enthält.
Bild 1. Zum Signieren eines Skripts wendet man „signcode.exe“ an. Zu den wichtigsten Einstellungen des Assistenten gehört die Auswahl des Zertifikats, die hier gezeigt wird.
Bild 2. Bei Gebrauch des Zertifikatsmanagers ist in jedem Fall die Festlegung des Zertifikatszwecks „Codesignatur“ wichtig: Dazu muss ein Zertifikat ausgewählt werden, bevor man dann, wie hier gezeigt, auf „Erweitert“ klickt.
WSH-Skripte sind reine Textdateien im Dateisystem. Sie sind sehr leicht eingeschleust, man kann sie sehr leicht (bösartig) verändern und man braucht nicht viele Kenntnisse, um großen Schaden anzurichten. Wenn man den WSH nicht komplett deaktivieren kann, weil man einige gutartige Skripte für den (Administrator-) Alltag braucht oder die Benutzeranmeldung skriptbasiert verbessert hat, dann bleibt nur die selektive Auswahl der Skripte.
Wer aus einem Pool von vorgefertigten Skripten ein Skript starten darf, kann der Administrator sehr einfach über die NTFS-Dateisystemrechte steuern. Zum Start eines Skripts sind minimal die Rechte wie „Datei lesen“, „Attribute lesen“ und „Berechtigungen lesen“ notwendig. Das Recht „Datei ausführen“ wird nicht benötigt, da die ausführende Instanz beim WSH entweder wscript.exe oder cscript.exe ist (siehe auch [3], Seite 27).
Die NTFS-Sicherheit wirkt nur auf vorhandene Skripte. Sie ist kein Schutz vor Skripten, die Benutzer über Disketten, USB-Sticks übertragen oder gegen solche Skripte, die aus dem Netzwerk eingeschleust und von der Festplatte oder einem mobilen Medium ausgeführt werden.
Mit Windows Script Host Version 5.6 hat Microsoft daher digitale Signaturen für Skripte eingeführt, mit denen Authentizität und Integrität von Skripten geprüft werden können. Ein Administrator oder Skriptautor kann Skripte digital signieren und gleichzeitig Windows dazu bewegen, nur (von ihm) digital signierte Skripte auszuführen. In allen Windows-Versionen vor Windows XP ist die Steuerung der erlaubten Signaturen jedoch nur sehr grob über die Registrierung vertrauenswürdiger Zertifizierungsstellen möglich. Ab Windows XP steht mit den Software Restriction Policies (SRP) ein geeignetes Instrument zur Verfügung, um auf der Ebene einzelner Signaturen oder sogar Hash-Werten einzelner Skripte die Zugriffsrechte zu steuern.
Für die Arbeit mit signierten Skripten sind als zusätzliche Software neben dem WSH die Microsoft CryptoAPI-Tools erforderlich, die es kostenlos unter [1] gibt. Die Crypto-Tools bestehen aus sieben Kommandozeilenwerkzeugen und einem GUI-Werkzeug; die wichtigsten unter ihnen sind:
· signcode.exe zum Signieren eines Skripts,
· makecert.exe zum Erstellen eines Zertifikats,
· chktrust.exe zum Prüfen einer Signatur und
· certmgr.exe zum Verwalten der Zertifikate.
Um ein Skript digital signieren zu können, benötigt der Skriptautor ein Schlüsselpaar und ein Zertifikat für den öffentlichen Schlüssel aus diesem Schlüsselpaar. Ein solches Zertifikat bekommt er von einem Windows-Server mit installiertem Zertifikatsdienst, von einem externen Zertifikatsanbieter im WWW oder von makecert.exe. Mit dem folgenden Befehl erzeugt man ein Schlüsselpaar und ein Zertifikat. „HSchwichtenberg.cer“ enthält dann nach der Ausführung das Zertifikat mit dem öffentlichen Schlüssel und „HSchwichtenberg.pvk“ als den privaten Schlüssel.
makecert HSchwichtenberg.cer -n „CN=Dr. Holger Schwichtenberg“ -sv HSchwichtenberg.pvk
Um mit diesem Test-Zertifikat arbeiten zu können, muss man auch das Vertrauen in die Test-Zertifizierungsstelle aktivieren:
setreg 1 TRUE
Zum Signieren eines Skripts wendet man dann „signcode.exe“ an. Dabei hat man die Wahl zwischen einem GUI-basierten Assistenten und einer Steuerung per Kommandozeilenoptionen. Die wichtigsten Einstellungen des Assistenten sind die Auswahl der Skriptdatei, des Zertifikats (Bild 1) und des privaten Schlüssels. Sofern der WSH 5.6 installiert ist, können hier nicht nur die binären Dateitypen .exe, .dll, .ocx, sondern auch sämtliche Skriptdateitypen (.vbs, .vbe, .js, .jse, .wsf) ausgewählt werden.
Der Assistent, der auch in Bild 1 zu sehen ist, hängt nach Abschluss aller Einstellungen die Signatur an die Skriptdatei an. Das Listing auf der Seite 29 zeigt ein Skript in einer XML-strukturierten .wsf-Datei. Die digitale Signatur steckt in dem Element . Bei nicht-XML-strukturierten Skriptdateien wird die Signatur in Kommentarzeilen verborgen, sodass die Skriptspracheninterpreter nicht über die Signatur stolpern. Ob das Signieren erfolgreich war, kann man mit dem folgenden Befehl prüfen:
chktrust e:HSTestSkript.wsf
Nur wenn die Integrität der Skriptdatei und das Zertifikat in Ordnung sind, meldet ChkTrust „test.wsf: Succeeded“ zurück. Leider hat der Benutzer in der Standardeinstellung auch im Fehlerfall die Möglichkeit, das Skript dennoch zu akzeptieren und damit ein „Succeeded“ zu erzeugen. Nur wenn der Benutzer die Warnung des Systems nicht ignoriert, lautet der Rückgabewert „test.wsf: Failed: The subject is not trusted for the specified action.“
Die Signierung aller Skripte, die ausgeführt werden können, ist jedoch nur die halbe Arbeit. Denn in der Standardeinstellung führt der WSH alle Skripte aus, unabhängig davon, ob diese signiert sind und von wem diese signiert sind. Man muss also das Betriebssystem dazu bringen, bei jedem Start eines Skripts die Prüf-routine auszuführen, die auch „chktrust.exe“ verwendet. Microsoft macht es dem Administrator nicht einfach: Der passende Registry-Schlüssel ist nicht nur undokumentiert, sondern auf einigen Systemen auch mit dem falschen Datentyp vorbelegt. Der entscheidende Schlüssel ist:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows Script HostSettings] „TrustPolicy“=dword:00000002“
In diesem Schlüssel muss dann „TrustPolicy“ auf den Wert 0, 1 oder 2 gesetzt werden:
· Der Wert „0“ ist die Standardeinstellung und bedeutet, dass alle Skripte laufen.
· Um dem Benutzer bei unsignierten Skripten die Wahl zu lassen, gehört eine „1“ in die TrustPolicy.
· Um grundsätzlich die Ausführung aller Skripte zu unterbinden, die unsigniert sind, deren Integrität verletzt ist oder bei denen es Unzulänglichkeiten hinsichtlich der Zertifizierungsstellen oder der Vertrauenskette gibt, ist „2“ der richtige Wert.
Die letzte Einstellung („2“) bedeutet, dass der Benutzer sich der Vertrauenswürdigkeit der Zertifizierungsstellen ausliefert. Welche Zertifizierungsstelle man in die Liste der vertrauenswürdigen Zwischen- und Stammzertifizierungsstellen aufnimmt, sollte also wohl überlegt sein.
Den Zertifikatsmanager erreicht man über „certmgr.exe“ oder im Internet Explorer über „Extras/Internetoptionen“ und den Button „Zertifikate“ in der Registerkarte „Inhalt“. Zertifikatsdateien (beispielsweise .cer, .crt, .spc, .p7b) lassen sich von dort oder auch direkt über ihr Kontextmenü importieren. Wichtig ist in jedem Fall die Festlegung des Zertifikatszwecks „Codesignatur“ im Zertifikatsmanager. Dazu muss ein Zertifikat ausgewählt werden, bevor man dann auf „Erweitert“ klickt, wie in Bild 2 gezeigt.
Die Liste der vertrauenswürdigen Zwischen- und Stammzertifizierungsstellen enthält bereits eine Reihe von Zertifizierungsstellen, die für den Zweck „Codesignatur“ freigegeben sind. Es bleibt also die Schwachstelle, dass jemand, der ein Zertifikat eines dieser öffentlichen Zertifizierungsstellen besitzt, ein böses Skript schreibt. Die öffentlichen Zertifizierungsstellen zu löschen, könnte zu Problemen beim Installieren von Anwendungen, beim E-Mail-Empfang und beim Surfen im WWW führen.
Diese letzte Lücke lässt sich leider nur in Windows XP und Windows Server 2003 mit Hilfe der dort vorhandenen Richtlinien für Softwarebeschränkungen (alias Software Restriction Policies – SRP) schließen. Die Richtlinien für Softwarebeschränkung erlauben es, Programme (und Skripte) selektiv auf Basis des Zertifikats oder anderer Kriterien zu aktivieren oder zu deaktivieren. In einer lokalen Richtlinie oder einer Gruppenrichtlinie kann festgelegt werden, dass nur mit bestimmten einzelnen Zertifikaten signierte Skripte (und andere Anwendungen) erlaubt sein sollen.
Zwar kann man Zertifikatsregeln auch so definieren, dass man die Ausführung eines Programmcodes mit bestimmten Zertifikaten verbietet, doch ist dies im Allgemeinen nicht sinnvoll, da man ja die Zertifikate der Angreifer nicht kennt. Sinnvoll ist es, die SRP-Grundeinstellung auf „Alles verbieten“ zu setzen und dann für einzelne Zertifikate den Zugriff zu ermöglichen. (fms)
von Dr. Holger Schwichtenberg |