Windows PowerShellAbwehren von schädlichem Code

Don Jones

Erinnern Sie sich an die Zeit, als sich Windows Vista noch im Beta-Stadium befand und Gerüchte über eine sehr frühe Version einer neuen Befehlszeilenshell mit dem Codenamen „Monad“ im Umlauf waren?(Diese erhielt natürlich schließlich den Namen Windows PowerShell.)Damals gab es in den populären Medien viele Berichte über den „ersten Windows Vista-Virus“.In

Wirklichkeit war der „Virus“ lediglich ein Malwareskript zum Machbarkeitsnachweis, der auf „Monad“ abzielte.Um das Skript auszuführen, hätte „Monad“ selbst besonders konfiguriert werden müssen, denn das Skript funktionierte nicht unter den Standardeinstellungen.Zudem hatte Microsoft, als diese Berichte im Umlauf waren, bereits angekündigt, dass „Monad“ nicht im Lieferumfang von Windows Vista® enthalten sein würde.Es war praktisch viel Lärm um nichts (oder zumindest um sehr wenig).

Doch da Windows PowerShellTM immer populärer wird (das Programm wurde bereits über eine Million Mal heruntergeladen), nehmen die Chancen zu, dass jemand das Programm zum Erstellen von schädlichem Skript verwendet.Die Möglichkeit, ein potenziell schädliches Skript in Windows PowerShell zu schreiben, ist vorgegeben. Jedes Verwaltungstool, einschließlich Windows PowerShell, cmd.exe und VBScript, kann zu böswilligen Zwecken verwendet werden.Sie können also nicht davon ausgehen, dass eine bestimmte PS1-Datei harmlos ist.

Glücklicherweise ist Windows PowerShell standardmäßig so konfiguriert, dass keine Skripts ausgeführt werden, d. h. ein schädliches Skript kann nur mit Ihrer Hilfe ausgeführt werden.In diesem Monat möchte ich vorhersagen, wie dies wahrscheinlich vor sich gehen wird.Damit soll nichts Schlechtes über Windows PowerShell gesagt werden – meiner Meinung nach hat Microsoft bei der Entwicklung dieser Skripterstellungsshell, bei der viele Risiken vermieden werden, gute Arbeit geleistet.Doch eine Diskussion lohnt, damit Sie sich vorbereiten können und zur Abwehr dieses potenziellen Angriffs bereit sind.

Sicherheit als Standard

Es sollte erwähnt werden, dass Windows PowerShell die erste von Microsoft entwickelte Sprache nach der berühmten Trustworthy Computing-Initiative war.Sicherheitsguru Michael Howard (Autor des Buchs „Writing Secure Code“) war der „Sicherheitskollege“ des Windows PowerShell-Teams.Auf seine Initiative hin wurde der Code so sicher wie möglich geschrieben und – noch wichtiger – die Shell standardmäßig so sicher wie möglich konfiguriert.

Zuerst soll Ihnen ein schneller Überblick über die ursprünglichen Windows PowerShell-Sicherheitseinstellungen verschafft werden.Standardmäßig führt die Shell keine Dateien mit einer PS1-Dateinamenerweiterung aus, wenn Sie auf diese doppelklicken.Diese Erweiterung wird dem Editor zugeordnet.Tatsächlich führt die Shell aufgrund eines integrierten Features, das als Ausführungsrichtlinie bezeichnet wird, standardmäßig überhaupt keine Skripts aus. Diese Ausführungsrichtlinie beschreibt die Bedingungen, unter denen ein Skript ausgeführt wird.Es ist automatisch auf „Eingeschränkt“ gesetzt, wodurch alle Skripts an der Ausführung gehindert werden und die Shell nur zur interaktiven Verwendung aktiviert wird.Die Ausführungsrichtlinie kann mithilfe des Set-ExecutionPolicy-Cmdlets oder über eine von Microsoft bereitgestellte administrative Vorlage für Gruppenrichtlinien (ADM-Datei) geändert werden.(Sie erhalten die ADM-Datei unter go.microsoft.com/fwlink/?LinkId=102940.)Abbildung 1 zeigt die Ausführungsrichtlinien, die Sie festlegen können.

Abbildung 1** Auswählen einer sicheren Ausführungsrichtlinie **(Klicken Sie zum Vergrößern auf das Bild)

Die Ausführungsrichtlinie weist lediglich einige Ausnahmen auf.Selbst wenn die Shell auf „Eingeschränkt“ gesetzt ist, kann sie einige bestimmte XML-Konfigurationsdateien importieren, die von Microsoft bereitgestellt und zusammen mit der Shell installiert werden.Diese Dateien dienen zum Bereitstellen bestimmter Funktionen, beispielsweise Erweiterungen zu Microsoft® .NET Framework-Typen und Standardformatierungslayouts für die meisten .NET-Objekttypen.Es sind also Dateien, die die Shell auf jeden Fall beim Starten laden sollte.

Obwohl diese Dateien ausführbaren Code enthalten können und ihn auch enthalten, wurden sie digital von Microsoft signiert.Jegliche Manipulation lässt die Signatur nutzlos werden, und wenn dies geschieht, importiert die Shell die Dateien nicht beim Starten.Aufgrund dieses Entwurfs sind die Dateien vor Malware, die versuchen könnte, schädlichen Code in sie einzufügen, ziemlich sicher.

Selbstverständlich verhindert die auf „Eingeschränkt“ gesetzte Ausführungsrichtlinie auch, dass Ihre eigenen Windows PowerShell-Profilskripts beim Starten ausgeführt werden.Windows PowerShell erstellt ein Profilskript nicht standardmäßig, sondern sucht an vier bestimmten Speicherorten nach bestimmten Dateinamen, und wenn diese gefunden werden, versucht das Programm, sie bei jedem Start der Shell auszuführen.(Die zusammen mit Windows PowerShell installierte Dokumentation stellt Details über den Ordner und die Dateinamen bereit, die für Profilskripts verwendet werden.)Das Profil ist der Schlüssel zum hier erläuterten Exploit.

Ändern der Ausführungsrichtlinie

Cmdlet des Monats

Das Partnercmdlet zu Set-AuthenticodeSignature ist Get-AuthenticodeSignature.Dieses Cmdlet soll ein digital signiertes Skript untersuchen und Ihnen Einzelheiten über die Signatur vermitteln.Zeigen Sie damit auf die betreffende Datei, und Sie sehen nicht nur, ob eine Datei signiert wurde, sondern auch, ob die Signatur unversehrt ist, welches Zertifikat zum Signieren der Datei verwendet wurde und so weiter.Dieses Cmdlet arbeitet nicht nur mit Windows PowerShell Skripts, sondern auch mit signierten ausführbaren Dateien, und zwar so:

PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *

Durch Ausführen dieses Befehls können Sie sehen, dass die ausführbare Datei von der Microsoft Corporation mit einem Zertifikat signiert wurde, das von der Microsoft Codesignatur-Zertifizierungsstelle ausgestellt wurde.

Befehlsergebnisse  (Klicken Sie zum Vergrößern auf das Bild)

Es soll an dieser Stelle betont werden, dass es unter Standardbedingungen sehr schwierig, wenn nicht sogar unmöglich ist, Windows PowerShell irgendeinen Code, von schädlichem Code einmal ganz abgesehen, ausführen zu lassen.Erst durch Ändern der Ausführungsrichtlinie wird das Ausführen von schädlichen Skripts überhaupt ermöglicht.Es soll ganz klar gesagt werden, dass dieser Artikel keine Alarmglocke bezüglich Sicherheitslöchern in Windows PowerShell ist. Vielmehr sollen einige bewährte Methoden vermittelt werden, damit Ihre Systeme abgesichert bleiben.

Die niedrigste Ausführungsrichtlinie ist „Nicht eingeschränkt“, d. h. alle Skripts können ohne Einschränkung oder Frage ausgeführt werden, was im Wesentlichen das gleiche unerwünschte Szenario bietet, das jahrelang bei VBScript und Batchdateien existierte.Wenn Sie die Shell auf „Nicht eingeschränkt“ setzen, dient dies praktisch als Einladung für ein schädliches Skript, Schaden anzurichten.Wenn Sie „Nicht eingeschränkt“ als Einstellung auswählen und ein Skript Schaden anrichtet, sollten Sie rechtfertigen können, warum Sie sich für diese Einstellung entschieden haben, und Sie sollten Ihre Entscheidung eingestehen, wenn Sie erklären müssen, wie ein Virus Ihre Umgebung ausgelöscht hat!

Fairerweise sollte erwähnt werden, dass Windows PowerShell weiterhin versucht, aus dem Internet heruntergeladene Skripts zu entdecken, und Sie vor ihrer Ausführung warnt, selbst wenn die Einstellung „Nicht eingeschränkt“ lautet.Es ist jedoch generell keine gute Idee, eine Ausführungsrichtlinie auf „Nicht eingeschränkt“ zu setzen.

Signieren von Skripts

Die sicherste Ausführungsrichtlinie, die das Ausführen von Skripts zulässt, ist AllSigned.Diese Einstellung führt, wie der Name schon sagt, nur Skripts mit einer unversehrten digitalen Signatur aus, die mit einem vertrauenswürdigen Zertifikat erstellt wurde (irgendeine Signatur reicht also nicht aus).Zum Signieren von Skripts müssen Sie sich ein digitales Zertifikat der Klasse III beschaffen, genauer gesagt ein codesigniertes Microsoft Authenticode-Zertifikat.Solche Zertifikate sind bei der internen Public Key-Infrastruktur (PKI) Ihres Unternehmens erhältlich, wenn eine solche vorhanden ist, oder sie können von kommerziellen Zertifizierungsstellen (Certification Authority, CA) wie CyberTrust, Thawte und VeriSign erworben werden.

Wenn Sie wissen möchten, ob auf Ihrem Computer Zertifikate installiert sind, die zum Signieren von Skripts verwendet werden können, können Sie sich dies durch das folgende Cmdlet anzeigen lassen:

Get-ChildItem CERT: -recurse –codeSigningCert

Nach Installation des Zertifikats auf Ihrem Windows®-Computer verwenden Sie das Set-AuthenticodeSignature-Cmdlet zum Erstellen und Anwenden einer digitalen Signatur, die als eine Reihe von scheinbar unsinnigen Kommentarzeilen am Ende des Skripts angezeigt wird.Einige Skripteditoren bieten die Option, eine Signatur auf eine Skriptdatei anzuwenden, einschließlich der Möglichkeit, Skripts automatisch beim Speichern zu signieren, was praktisch sein kann.

AllSigned ist die beste Ausführungsrichtlinie für eine Produktionsumgebung.Obwohl damit schädliche Skripts nicht sofort verhindert werden, wird sichergestellt, dass ein schädliches Skript signiert ist und damit der Autor des Skripts ausfindig gemacht werden kann (vorausgesetzt, Ihre Windows-Computer sind so konfiguriert, dass sie nur vertrauenswürdigen CAs vertrauen, doch dieses Thema geht über den Rahmen dieses Artikels hinaus).Interessanterweise kann Windows Script Host (WSH) 5.6 oder höher mit einer ähnlichen TrustPolicy-Einstellung konfiguriert werden, für die ebenfalls digitale Signaturen erforderlich sind, doch ich kenne nur wenige Administratoren, die diese Einstellung verwenden.

Es folgt eine kurze Wiederholung der bisher bereitgestellten Informationen.Mit einer auf „Eingeschränkt“ gesetzten Ausführungsrichtlinie sind Sie vor schädlichen Skripts sicher, aber es können auch keine nützlichen Skripts ausgeführt werden.Wenn Ihre Ausführungsrichtlinie als „AllSigned“ konfiguriert ist, lässt die Shell signierte Skripts zu, was recht sicher ist, da nur wenige Autoren von schädlichem Skript wünschen, dass eine überprüfte, nachverfolgbare Identität für ihre Arbeit vorliegt.Die Einstellung „Nicht eingeschränkt“ andererseits ist äußerst unsicher, und bei ihrer Verwendung ist zu erwarten, dass irgendwann ein schädliches Skript ausgeführt wird.(Beachten Sie, dass ich die Einstellung „Nicht eingeschränkt“ nicht als besonderes Sicherheitsrisiko betrachte, denn sie gibt nicht vor, sicher zu sein. Wenn Sie diese Einstellung verwenden, wissen Sie vermutlich, worauf Sie sich einlassen.)

Durch den Nebeneingang

Es gibt noch eine weitere Ausführungsrichtlinie:RemoteSigned.Diese wird meines Wissens nach heute von den meisten Administratoren verwendet, da sie einfach als sicherer als „Nicht eingeschränkt“ und weniger problematisch als „AllSigned“ empfunden wird.Bei „RemoteSigned“ ist keine Signatur für lokale Skripts erforderlich.PS1-Dateien, die sich auf Ihren lokalen Laufwerken befinden, werden ohne Signatur ausgeführt.Remoteskripts (hauptsächlich jene, die Sie mithilfe von Internet Explorer® oder Outlook® aus dem Internet herunterladen) werden nur ausgeführt, wenn sie signiert sind. Beide Anwendungen markieren heruntergeladene Dateien mit einem speziellen Kennzeichen.

Doch die RemoteSigned-Einstellung kann Ihnen ein falsches Gefühl der Sicherheit vermitteln.Zum einen ist es einfach, Remoteskripts herunterzuladen, ohne dass das spezielle Kennzeichen angewendet wird.Nicht-Microsoft-Browser beispielsweise setzen dieses Kennzeichen in der Regel nicht, was auch bei den meisten Nicht-Microsoft-E-Mail-Clients der Fall ist.Es gilt zu beachten, dass Windows PowerShell heruntergeladene Skripts ohne dieses Kennzeichen als lokale Skripts behandelt, was bedeutet, dass eine Signatur nicht erforderlich ist.Dennoch sehe ich dies nicht als bedeutendes Sicherheitsrisiko an.Sie müssten das Skript herunterladen, Windows PowerShell öffnen und das Skript manuell ausführen, damit es ausgeführt werden kann.Es dürfte ziemlich schwierig sein, jemanden dazu zu bringen, alle diese Schritte durchzuführen, und Administratoren – in der Regel die einzigen Benutzer in einem Netzwerk, bei denen Windows PowerShell installiert ist – sollten es eigentlich besser wissen.

Bei „RemoteSigned“ ist jedoch ein „Nebeneingang“ von Bedeutung, durch den sich Malware einschleichen kann.Erinnern Sie sich an die Windows PowerShell-Profilskripts?Wenn sie vorhanden sind (egal, ob von Ihnen oder einer Malware erstellt), werden sie jedes Mal beim Ausführen von Windows PowerShell ausgeführt.Gemäß der RemoteSigned-Ausführungsrichtlinie müssen Ihre Profilskripts, die lokal sind, nicht signiert werden.

Hier ist das Szenario:

1. Eine Malware gelangt in Ihr System und erstellt ein Shellprofilskript oder fügt schädlichen Code in ein vorhandenes Profilskript ein.Malware wird in der Regel unter Ihrem angemeldeten Benutzerkonto ausgeführt, das Ihr Profilskript normalerweise ändern darf.
2. Sie öffnen Windows PowerShell, wobei Sie nicht erkennen, dass Ihr Profilskript erstellt oder geändert wurde und nun schädlichen Code enthält.Der Code wird ausgeführt, und der Schaden ist angerichtet.Der Schaden ist noch schlimmer, wenn Sie Windows PowerShell gewöhnlich unter Ihren Administratoranmeldeinformationen öffnen. Dies ist eine häufige Praxis, denn wenn Sie die Shell verwenden, benötigen Sie Administratorrechte, um die Aufgaben durchzuführen, für die die Shell vorgesehen ist.

Das Profil bietet beliebigem und schädlichem Code dann eine Möglichkeit, ohne Ihr Wissen ausgeführt zu werden, und die RemoteSigned-Ausführungsrichtlinie lässt dies zu.

Schutz für das Profil

Es gibt nur eine gute Möglichkeit, Ihr Profil zu schützen:Verwenden Sie die AllSigned-Ausführungsrichtlinie.Unter „AllSigned“ müssen selbst Ihre Profilskripts digital signiert werden, andernfalls führt Windows PowerShell sie beim Start nicht aus.Wenn Sie Ihre Profilskripts signiert haben, zerstören schädliche Änderungen an ihnen die digitalen Signaturen, sodass sie nicht ausgeführt werden können. Windows PowerShell macht Sie sogar beim Starten auf dieses Problem aufmerksam.„AllSigned“ ist im Grunde die einzig sichere Einstellung der Ausführungsrichtlinie in Produktionsumgebungen, in denen das Ausführen von Skripts möglich sein muss.

Es gibt einen weiteren Ansatz, der jedoch komplizierter und weniger vertrauenswürdig ist.Sie können leere Profilskriptsdateien für alle vier Dateien erstellen, nach denen Windows PowerShell sucht.Verwenden Sie ein neues Benutzerkonto (ich bezeichne es als „Profileditor“), um diese Dateien zu erstellen, und legen Sie die NTFS-Berechtigungen der Dateien so fest, dass nur das Profileditorkonto sie ändern kann.Für andere Konten kann ein schreibgeschützter Zugriff eingerichtet werden.

Melden Sie sich jedoch nie bei Ihrem Computer mit dem Profileditorkonto an, es sei denn, Sie wollen Ihr Profil bearbeiten.Bei dieser Vorgehensweise können die normalen Benutzerkonten Ihre Profilskripts nicht ändern.Malware, die ausgeführt wird, während Sie mit einem normalen Konto angemeldet sind, ist ebenfalls nicht in der Lage, die Skripts zu ändern.Was geschieht, wenn Malware ausgeführt wird und Sie gerade als Profileditor angemeldet sind?Da Sie als Profileditor angemeldet sein werden, um Ihre Profilskripts zu bearbeiten, sollten Sie die Änderungen bemerken.

Sie können Ihr eigenes Sicherheitsnetz spannen, indem Sie ein Profilskript für alle Benutzer erstellen, das, wie gerade beschrieben, mit strengen Dateiberechtigungen gesteuert wird.Innerhalb dieses Skripts schreiben Sie Code, der das Get-AuthenticodeSignature-Cmdlet zum Prüfen der digitalen Signaturen in den anderen Profilen verwendet, nach denen die Shell sucht.Damit können Sie praktisch Signaturen bei Profilskripts anfordern, ohne dass sie für andere Skripts erforderlich sind.

Die AllSigned-Ausführungsrichtlinie ist jedoch eine gründlichere Möglichkeit zum Schutz Ihres Profils.Es ist zu empfehlen, dass die Ausführungsrichtlinie jedes Computers, der mit Ihrem Netzwerk verbunden ist, auf „Eingeschränkt“ gesetzt wird, was vorzugsweise über die Gruppenrichtlinie vorgenommen wird.Diese setzt lokale Einstellungen außer Kraft und stellt sicher, dass neue Domänencomputer automatisch so eingestellt werden, dass Skripts nicht zugelassen sind.Computer, auf denen Skripts zugelassen werden müssen, sollten eine andere Gruppenrichtlinie haben, die die AllSigned-Ausführungsrichtlinie festlegt.Sie müssen alle Skripts digital signieren, aber Sie können sich darauf verlassen, dass nur vertrauenswürdige Skripts von identifizierbaren Autoren in Ihrer Umgebung ausgeführt werden.

Don Jones ist der führende Experte für die Skripterstellung bei SAPIEN Technologies und Mitverfasser von Windows PowerShell:TFM (SAPIEN Press, 2007).Sie erreichen ihn unter www.ScriptingAnswers.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.