Haben Sie ein Skript oder ein Modul aus der Gallery heruntergeladen oder aus einer anderen Quelle erhalten, können Sie es sehr schnell einem ersten Plausibilitätscheck unterziehen. Bei Modulen funktioniert das, zumindest solange es sich dabei um Skriptmodule handelt, das heißt, die aus dem Modul exportierten Cmdlets sind selbst in PowerShell geschrieben und nicht aus einer .NET-Sprache zu einer DLL kompiliert.

PowerShell-Code mit AST prüfen

Der erste Schritt einer solchen Prüfung ist die Auswertung, welche Befehle das Skript oder Modul überhaupt enthält. Dafür können Sie auf den PowerShell-eigenen Parser zurückgreifen, indem Sie den "Abstract Syntax Tree" (AST) auswerten, ein Beispiel zeigt Listing 1.

Damit erhalten Sie die vollständige Liste aller Befehlsaufrufe im untersuchten Quelltext. Diese können Sie beispielsweise nach gefährlichen Verben wie "Set" oder "Remove" filtern. Ein Skript, das eigentlich nur Daten über die Maschine sammeln soll, auf der es läuft, sollte keine solchen "ändernden" Cmdlets beinhalten und auch nicht mit anderen Systemen kommunizieren. Falls sie doch vorkommen, vergewissern Sie sich, dass es sich dabei um das Skript-eigene "Aufräumen" handelt, beispielsweise um das Löschen der Logdatei, falls keine Fehler aufgetreten sind. Weitere Befehle, auf die Sie achten sollten, sind:

• Add-Type: Damit können beliebige .NET-Assemblies geladen und deren Methoden ausgeführt werden.
• Invoke-Command: Ermöglicht einen Skript-Block, der beispielsweise aus dem Internet nachgeladen wurde, zu starten.
• Invoke-WebRequest und Invoke-RestMethod: Falls das Skript oder Modul für den erklärten Einsatzzweck keine HTTP-Interaktion benötigt, kann es sich hierbei um Nachladen von Code oder Exfiltration von Daten handeln.
• Install-Module: Damit kann ein Skript zur Laufzeit Module nachladen, sofern Verbindungsmöglichkeit zum jeweiligen Repository besteht.

Falls in Ihrer Umgebung AppLocker beziehungsweise Windows Defender Application Control (WDAC) implementiert ist, sind Sie bei unbekannten Skripten und Modulen möglicherweise dadurch geschützt, dass sie im Constrained Language Mode laufen und dadurch viele gefährliche Sprachelemente gar nicht möglich sind. Allerdings sind unter diesen Umständen die meisten Skripte nicht vollständig lauffähig, sodass Sie um die Code-prüfung und die anschließende Zulassung in Ihrer Application-Whitelisting-Richtlinie in der Regel nicht herumkommen.

Signatur prüfen

Nicht nur das Internet hält PowerShell-Skripte und -Module bereit, manchmal bekommen Sie PowerShell-Code von Dritten zugesandt oder finden sogar alte Skripte von längst ausgeschiedenen Kollegen auf Fileservern in Ihrer eigenen Organisation. Häufig ist dieser Code nicht dokumentiert und auch nicht besonders gut lesbar geschrieben – es ist jedoch bekannt, dass er zu einem früheren Zeitpunkt seinen Zweck erfüllt hat. Doch ist es immer noch dasselbe Skript oder wurde es inzwischen verändert?

Wohl dem, der seine Skripte signiert hat, sobald sie ausgetestet und voll funktionsfähig waren. Damit lässt sich auch Jahre später noch überprüfen, ob sich das Skript seit dem Signieren verändert hat. Auch wenn die PowerShell-eigenen Ausführungsrichtlinien keinen wirklich wirksamen Schutz gegen gezielten und absichtlichen Missbrauch bieten, können Sie sich doch mittels Signaturprüfung immerhin von der Integrität des Skriptcodes überzeugen, bevor Sie ihn auf produktiven Systemen ausführen. Verwenden Sie dafür den Befehl

Get-AuthenticodeSignature -FilePath <Pfad zum Skript oder Modul>

um die Gültigkeit der Signatur zu überprüfen. Das Attribut "Status" enthält das Ergebnis der Prüfung, und sollte es sich dabei nicht um "Valid" oder "NotSigned" handeln, bietet das Attribut "StatusMessage" eine erweiterte Erklärung darüber, warum die Signatur für ungültig befunden wurde. Das Cmdlet kann übrigens auch die Signatur binärer ausführbarer EXE- oder DLL-Dateien überprüfen. Schlägt die Signaturprüfung mit dem Status "HashMismatch" fehl oder ist das Skript gar nicht signiert, bleibt Ihnen nichts anderes übrig, als den Code in Detail zu untersuchen.

Im dritten Teil schauen wir uns an, wie Sie fremde Skripte in einer abgeschlossenen Testumgebung unter die Lupe nehmen. Im ersten Teil sind wir darauf eingegangen, warum Sie in der PowerShell Gallery nicht zu vertrauensselig sein sollten.

Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management sowie VMware Certified Implementation Expert für Datacenter-Virtualisierung.