Perl gilt als Schweizer Taschenmesser unter Programmiersprachen – dieser Titel wird Perl nun durch PowerShell (PS) unter Windows streitig gemacht. PowerShell ist eine Kommandozeilen- und Skriptsprache, die mit Fokus auf Verwaltung von Systemen entwickelt wurde. PowerShell basiert auf dem .NET Framework, ist tief im Betriebssystem integriert und verfügt über einen enormen Funktionsumfang. Kurz gesagt: Wenn ein Angreifer auf einem System Zugriff auf PowerShell hat, erhält dieser ein mächtiges Werkzeug, das seinen Handlungsspielraum erhöht und es ihm ermöglicht, vorgesehene Einschränkungen zu umgehen. Im Anschluss an eine Sicherheitsüberprüfung wird mir oft die Frage gestellt, wie die Ausführung von PowerShell kontrolliert oder blockiert werden kann. In diesem Labs werde ich mich mit dieser Frage auseinander setzen.

Zieldefinition

Als Angreifer kenne ich Tricks, wie ich trotz Einschränkungen Befehle ausführen und auf Informationen zugreifen kann, auf die ich nicht zugreifen sollte. Die Ausgangslage ändert sich aus Sicht eines Systemadministrators. In dieser Rolle will ich genau solche Tricks verhindern und das System so sichern, dass eine unerwünschte Ausführung von Programmen nicht möglich ist. Es gibt im Falle der Blockierung von PowerShell aber weitere Anforderungen als die simple Deaktivierung des Tools. PowerShell ist für die Systemadministration sehr nützlich und wird vermutlich innerhalb einer IT-Infrastruktur bereits in Skripts eingesetzt. Möglicherweise funktioniert das eine oder andere Programm ohne PowerShell-Unterstützung nicht mehr richtig. Es ist demzufolge nötig, die Ursprungsfrage in weitere Unterfragen aufzuteilen:

• Wie kann die Ausführung von PowerShell blockiert werden?
• Können bestimmte Benutzer/Gruppen PowerShell weiterhin verwenden?
• Können PS-Skripte trotz Verbot weiterhin ausgeführt werden?

Eigentlich könnte der Labs hier bereits zu Ende sein, denn PowerShell kennt sogenannte Execution-Policies. In meinem Labs über die Grundlagen von PowerShell habe ich mich bereits mit diesen Richtlinien auseinandergesetzt und dabei festgestellt, dass diese keine wirkungsvolle Schutzmassnahme darstellen. Ich muss also einen anderen Weg zur Einschränkung von Anwendungen finden.

Mein Ziel dabei ist es, die bereits in das Betriebssystem integrierten Funktionen zu verwenden. Darum habe ich mich dazu entschieden, das Sicherheitstool Microsoft AppLocker einzusetzen.

Umsetzung

Meine Windows Testumgebung ist einfach aufgebaut: Zwei virtuelle Maschinen, ein Windows Server 2008 R2 als Domain Controller und als Client-Computer eine Windows 7 Professional VM. Da folgt schon das erste Problem: Applocker und Lizenzen. Windows 7 Professional kann nur zur Definition von AppLocker-Regeln verwendet werden. Diese werden aber erst ab Lizenzstufe Enterprise/Ultimate auch durchgesetzt. Somit kann meine Client-VM für die Tests nicht einsetzen. Mit Windows 8 hat Microsoft die Lizenzpolitik überarbeitet und laut AppLocker-FAQ wird jede Windows 8 Edition vollständig unterstützt. Also erweitere ich meine Testumgebung um eine Windows-8.1-Client-VM.

Für die Verteilung des AppLocker-Regelwerks setze ich eine Gruppenrichtlinie ein. Das Regelwerk wird unter dem Pfad Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker definiert. Für den ersten Versuch habe ich die Standardregeln generieren lassen und eine Deny-Regel für das PowerShell Verzeichnis %SYSTEM32%\Windows\PowerShell\*) hinzugefügt.

Durch die Definition des Verzeichnispfads wird nicht nur die Ausführung von powershell.exe sondern auch des PowerShell Editor (powershell_ise.ex) deaktiviert. Für den ersten Test habe ich diese Policy allen Benutzern und Gruppen der Domäne zugeteilt. Es sollte also grundsätzlich nicht mehr möglich sein PowerShell auszuführen. Die Regel hält genau das was sie verspricht – ich kann nun auf dem Windows Client weder die PowerShell Shell öffnen noch Skripte ausführen. Die Frage zur Blockierung von PS ist hiermit beantwortet.

Wie bereits erwähnt habe ich die GPO der Gruppe Everyone zugewiesen und natürlich kann ich diese Zuweisung so anpassen, dass die AppLocker Richtlinien nur für bestimmte Benutzer/Gruppen gelten. Für mich gilt in diesem Fall der Ansatz weniger ist mehr, sprich je weniger Ausnahmefälle desto besser für die Sicherheit der Systeme. Da die Richtlinien innerhalb von Gruppenrichtlinien verteilt werden können, ist es möglich verschiedene Richtlinien zu definieren und je nach Einstufung der Zielobjekte entsprechend zuzuweisen. So kann ich ein sehr restriktives AppLocker-Regelwerk definieren und dies Systemen zuweisen, die so weit als möglich eingeschränkt werden sollten (Beispiel Terminal-Server). Bei anderen Systemen kann dann ein Regelwerk mit definierten Ausnahmen verwenden. Die Frage zur Verwendung von PowerShell für bestimmte Gruppen aufheben wäre somit ebenfalls beantwortet.

Nun zur letzten Frage, was passiert wenn bei der Anmeldung eines Benutzers ein oder mehrere PS-Skripte ausgeführt werden sollen, die Ausführung von PowerShell aber für den Benutzer verboten ist. Da die Login-Skripte unter dem Account des Benutzers ausgeführt werden, wird die Ausführung dieser durch AppLocker blockiert. Damit die Skripte weiterhin verwendet werden können, ist eine Ausnahme im Regelwerk notwendig. Grundsätzlich können mit AppLocker drei Kategorien von Regeln angelegt werden:

1. Executables Rules
2. Windows Installer Rules
3. Script Rules

Bisher habe ich eine Deny-Regel für das PowerShell-Verzeichnis angelegt (sogenannte Executables Rule). Nun definiere ich eine zusätzliche Ausnahmeregel für ein Login-Skript (sogenannte Script Rule). Grundsätzlich gilt, dass eine Deny-Regel höher gewichtet wird. Wenn demzufolge die Ausführung von PowerShell verboten ist und zugleich das Logon-Skript erlaubt wird, dann greift zuerst die Deny-Regel und die Ausführung des Skripts wird trotz der zweiten Regel blockiert. Zudem kann in einer Executables Rule keine Ausnahme für ein Skript angelegt werden.

Das Fazit hier lautet also, wenn für einen Benutzer die Ausführung von PowerShell blockiert wird, kann auch kein Skript ausgeführt werden. Die Antwort zur Frage können PS-Skripte trotz Verbot der Ausführung weiterhin eingesetzt werden muss somit verneint werden. Wenn weiterhin PS-Skripte eingesetzt werden sollen, muss also ein anderer Weg gefunden werden. Falls jemand einen solchen Weg kennt, würde ich mich über ein Feedback freuen.

Während meiner Recherche nach einem solchen Weg habe ich ein interessantes Tool namens PS2EXE gefunden. Das Tool kapselt PowerShell-Code mit einem in C# geschriebenen PowerShell-Host Objekt und generiert daraus eine EXE-Datei. Diese EXE enthält alle Funktionen um PowerShell durch ein .NET Objekt auszuführen, kann aber nicht ohne eine installierte Version von PowerShell und dem .NET Framework ausgeführt werden. Da eine solche generierte EXE bei der Ausführung aber nicht auf powershell.exe zugreift, wird die AppLocker Regel umgangen und es ist dennoch möglich PowerShell Code auszuführen. Dies ist natürlich nur dann der Fall, wenn der Benutzer die entsprechenden Rechte hat, eine EXE-Datei auszuführen. Es wäre nun also möglich, für jedes PS-Skript eine solche Datei zu generieren und diese als Ausnahme in der Executables Rule zu definieren. Zudem kann das Tool eingesetzt werden, um eine Blockierung von PowerShell zu umgehen.

Umfeld auch beachten

Die Geschichte vom Versuch, PowerShell zu blockieren findet hier ein Ende. Es ist möglich mit Windows Bordmitteln PowerShell zu blockieren. Dies geschieht aber nicht ohne Preis. So stehen einige Funktionen, unter anderem die Verwendung von PS-Logon-Skripts, nicht mehr zur Verfügung. Zu beachten gilt, dass es nicht ausreicht, nur PowerShell zu deaktivieren, sondern auch das Umfeld im System muss entsprechend eingeschränkt werden. Ein Benutzer sollte keine beliebigen Programme ausführen dürfen, sondern nur Programme starten, die explizit erlaubt wurden oder aus einem vertrauenswürdigen Verzeichnis stammen. Die Standardregeln von AppLocker definieren die Verzeichnisse C:\Program Files (%PROGRAMFILES%) sowie C:\Windows (%WINDIR%) als vertrauenswürdig. Bei allen definierten Verzeichnissen muss zudem sichergestellt sein, dass der Benutzer keine Schreibrechte hat, um eigene Dateien darin zu platzieren.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://ps2exe.codeplex.com/
• https://technet.microsoft.com/en-us/windows/applocker.aspx
• https://technet.microsoft.com/library/ee619725%28v%3DWS.10%29.aspx#BKBK_WhichOSeditions