PowerShell: Sicherer Einsatz fremder Skripte und Module (3)
Die PowerShell feiert 2026 ihren 20. Geburtstag. Die PowerShell-Gemeinde hat in dieser Zeit Millionen von Skripten, Modulen und Code-Snippets produziert. Doch wie können Admins sicher sein, dass der fremde PowerShell-Code genau das tut, was sie erwarten, und keinen Schaden anrichtet? Wir geben hierzu einige Handlungsempfehlungen. Im dritten Teil schauen wir uns an, wie Sie fremde Skripte in einer abgschlossenen Testumgebung unter die Lupe nehmen.
Den ultimativen Test fremder Skripte können Sie natürlich in einer – von der Produktion möglichst gut abgeschotteten – Testumgebung durchführen. Lassen Sie dabei unbedingt das Logging und die Transkription mitlaufen, um alle Operationen mitzubekommen, die das Skript ausführt. Das hilft auch bei Code, der in Form von Base64-kodierten Strings übermittelt wird, denn diese werden für das Script Block Logging aufgelöst. Denken Sie dabei daran, dass die Gruppenrichtlinien und Konfigurationseinstellungen für Transkription und Logging unterschiedlich sind, je nachdem, ob sie die bordeigene "Windows PowerShell" oder die Nachfolgerin "PowerShell" einsetzen.
Testen ist am besten
Damit die Tests funktional aussagekräftig sind, muss die Testumgebung alle Systeme beinhalten, auf die das Skript zugreifen soll. Das können Dateifreigaben, Datenbanken oder beispielsweise Exchange oder andere Anwendungsserver sein. Andernfalls kann es passieren, dass Sie nur eine Untersuchung für einen Logikzweig erhalten – nämlich den, wo der Zugriff auf diese Systeme geprüft und das Skript bei Fehlschlagen des Zugriffs bereits früh beendet wird.
Auch von der AMSI-Integration können Sie bereits bei diesem Test profitieren, sofern das in der Testumgebung eingesetzte Antimalware-Werkzeug AMSI unterstützt. Allerdings wird AMSI nur bei wirklich schwerwiegenden Sicherheitsproblemen anschlagen – die Antimalware warnt Sie nicht davor, dass das Skript falsche oder zu viele Zeilen aus einer Datenbanktabelle löscht.
Falls Sie auch in Ihrer Produktivumgebung auf den AMSI-Schutz zurückgreifen wollen, sollten Sie akribisch darauf achten, dass das PowerShell-2.0-Subsystem nirgends aktiv ist, denn dieses erlaubt eine einfache Umgehung von AMSI. Erfreulicherweise benötigen immer weniger Anwendungen die veraltete PowerShell-Unterstützung. Den Status des 2.0-Subsystems können Sie auf Client-Betriebssystemen mit
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 | Where-Object State -eq Enabled
überprüfen. Auf Server-Betriebssystemen lautet der Befehl
Get-WindowsFeature -Name "PowerShell-V2" | Where-Object InstallState -eq 'Installed'
In beiden Fällen entspricht die sichere Konfiguration ohne PowerShell 2.0 einem leeren Ergebnis des Aufrufs.
Ist ein Skript oder Modul sowohl funktional als auch sicherheitstechnisch positiv getestet, können Sie es in Ihr hausinternes Arsenal aufnehmen, indem Sie es im internen, vertrauenswürdigen Repository veröffentlichen. Falls der Autor den Code nicht signiert hat, sollten Sie es mit Ihrem eigenen Zertifikat absichern, um nachträgliche Änderungen abfangen zu können.
Fazit
Das Internet bietet einen geradezu unerschöpflichen Schatz an Skripten und Modulen, damit Sie in Ihrer täglichen Administration sich auf die eigentliche Aufgabe konzentrieren können, statt das Rad neu zu erfinden. Allerdings ist PowerShell-Code aus öffentlich verfügbaren Quellen wie der PowerShell Gallery keiner Qualitätskontrolle unterworfen und kann Fehler oder sogar bösartige Elemente beinhalten. Da die Codeuntersuchung nicht immer möglich oder zumutbar ist, helfen letztendlich nur Tests, mit entsprechender Protokollierung und Überwachung durch AMSI. Nutzen Sie für das Verteilen von PowerShell-Code ein eigenes Repository, um die Möglichkeiten der unabsichtlichen Einschleusung von fremdem Code zu begrenzen. (jp/ln)
Im ersten Teil unseres Workshops sind wir darauf eingegangen, warum Sie in der PowerShell Gallery nicht zu vertrauensselig sein sollten. Im zweiten Teil haben wir erklärt, wie Sie PowerShell-Code im Parser auf Plausibilität prüfen und warum auch ein Check der Skriptsignatur nicht fehlen sollte.
Ü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.