Mit der PowerShell ist nahezu jede Aufgabe in der Systemadministration und IT-Automatisierung lösbar. Und es gehört auch zu den Grundprinzipien der Automatisierung, das Rad nicht jedes Mal neu zu erfinden. Wer über die Sachkenntnis verfügt und vielleicht sogar durch die Richtlinien seiner Organisation dazu gezwungen ist, seinen Skript-Code original zu entwickeln, sorgfältig zu testen und in einem entsprechenden Verwaltungssystem (Source Control oder Version Control) aufzubewahren, muss sich über die Funktionalität und Sicherheit der intern verwalteten Skripte grundsätzlich keine Gedanken machen.

Schädlicher Code lauert vielerorts

Doch auch in solchen Skripten kann Code enthalten sein, der einfach per Copy und Paste aus Blog-Artikeln, Community-Antworten auf Stack-Overflow oder anderen, nicht verifizierten Quellen übernommen wurde. Durch einen Kommentar mit Nennung der Quelle inklusive Internetadresse verleiht der Autor des Skriptes diesen Programmzeilen eine gewisse Legitimität, die diese leider nicht immer verdienen. Nicht jeder Administrator und nicht jedes IT-Team verfügt jedoch über das notwendige Wissen und die Erfahrung, um entsprechenden PowerShell-Code aus dem Ärmel zu schütteln. Hier greifen IT-Verantwortliche regelmäßig zu Modulen und Skripten, in deren Quellcode sie in den meisten Fällen gar nicht erst hineinschauen, sondern blind darauf vertrauen, dass er den beschriebenen Zweck erfüllt und keinen Schaden anrichtet.

Die Verbreitung vermeintlich intelligenter Chatbots wie ChatGPT samt ihrer Fähigkeit, plausibel klingenden Code in einer Vielzahl von Sprachen inklusive PowerShell zu produzieren, tut ihr Übriges. Wer den vom Chatbot generierten Code ungeprüft in seiner produktiven Umgebung laufen lässt, riskiert zumindest Downtime und Datenverlust. Es kann jedoch noch schlimmer kommen – nämlich dann, wenn der Chatbot nicht den kompletten Code selbst erzeugt, sondern die Installation und den Import fremder Module vorschlägt.

Nicht selten kommt es dabei zu "KI-Halluzinationen", die Module vorschlagen, deren Namen für den im Prompt mitgeteilten Zweck plausibel klingen, die es jedoch unter dieser Bezeichnung gar nicht gibt. Stellt ein potenzieller Angreifer fest, dass ein verbreiteter Chatbot auf bestimmte Anfragen ein und denselben Modulnamen herbeihalluziniert, kann er dieses Modul, allerdings mit schädlichem Inhalt, in das jeweilige Repository hochladen. Danach bleibt für ihn nichts weiter zu tun als zu warten, bis ein gutgläubiger Chatbot-Benutzer den Code ungeprüft übernimmt und das Modul installiert.

Nicht zu vertrauensselig in der PowerShell Gallery

Doch es gibt durchaus vertrauenswürdige Quellen für PowerShell-Code. Wenn ein Systemhersteller, dessen kompilierten Code Sie in Ihrer Umgebung bereits ausführen, Ihnen Skripte oder Module für die Konfiguration oder Administration seines Produkts zuliefert, die von ihm signiert sind, gibt es keinen Grund, diesem Skriptcode nicht zu vertrauen. Oft kommen solche Komponente in Form eines MSI-Installationspakets oder einer ZIP-Datei zu Ihnen. Sie müssen dann mit den in Ihrer Organisation üblichen Verteilungsmechanismen dafür sorgen, dass die PowerShell-Komponenten auf die Zielsysteme gelangen und dort auch auf dem aktuellen Stand bleiben, falls der Hersteller neue Versionen veröffentlicht. Die Verwendung des PowerShell-Codes ist also mit einem nicht zu unterschätzenden Aufwand verbunden.

Im PowerShell-Ökosystem hat sich die Verbreitung von Skripten und Modulen über Repositories bewährt. Ein solches liefert bereits die Installation der PowerShell mit – die von Microsoft betriebene PowerShell Gallery (PSGallery). Diese wird zwar nicht als vertrauenswürdig registriert, sie ermöglicht dennoch das Auffinden, die Installation und eine spätere Aktualisierung von Skripten und Modulen mittels einfacher Befehle aus dem PowerShellGet-Modul.

Sowohl die Microsoft-eigenen Produktgruppen als auch viele namhafte Hersteller wie VMware, Oracle oder DELL veröffentlichen Ihren PowerShell-Code in der Gallery, damit die Administratoren vor Ort ihn einfach mit Install-Module <Name> auf den gewünschten Systemen installieren und mit Update-Module <Name> aktuell halten können – sogar inklusive aller Abhängigkeiten. Allerdings bietet die Gallery selbst kaum Schutzmechanismen, um das Vorgaukeln einer falschen Vertrauenswürdigkeit zu unterbinden, was zu dem bereits 2023 veröffentlichten Blog-Artikel über vermeintliche Anfälligkeiten der Gallery und ihren möglichen böswilligen Missbrauch als Supply-Chain-Angriffsvektor führte.

Microsoft wies darauf hin, dass die PSGallery nie als vertrauenswürdig angesehen oder beworben wurde und jede Typosquatting- oder Spoofing-Attacke letztendlich ein Versuch des Social Engineering gegenüber allzu vertrauensseligen Endanwendern darstellt. Gleichzeitig arbeitet Redmond an zusätzlichen Verifizierungsmechanismen, die zwar das Veröffentlichen von Modulen und Skripten etwas erschweren würden, dafür jedoch das Spoofing deutlich einschränken sollen.

Bei PowerShell-Code aus der PSGallery sollten Sie also unbedingt das Prinzip "trust but verify" anwenden:

• Auf keinen Fall sollten Sie die PSGallery als vertrauenswürdiges Repository auf Ihren Endgeräten eintragen.
• Verwenden Sie das Save-Module- statt des Install-Module-Cmdlets und untersuchen Sie die heruntergeladenen Komponenten auf ihren Ursprung und ihre Integrität hin, denn die Gallery prüft weder bei der Veröffentlichung noch beim Download die Gültigkeit von Codesignaturen.
• Haben Sie eine bestimmte Version eines in der PSGallery veröffentlichten Pakets erfolgreich überprüft, sollten Sie auf den betroffenen Endgeräten genau diese Version installieren. Verwenden Sie für diesen Zweck den Parameter "-Version" der PowerShellGet-Cmdlets, denn ohne diesen Parameter laden Sie stets die aktuellste Version aus der Gallery herunter.

Sie können auch auf Nummer sicher gehen und die PSGallery mit UnregisterPSRepository auf allen PowerShell-fähigen Systemen in Ihrer Umgebung abmelden. Um dennoch von der Einfachheit der auf PowerShellGet basierenden Verteilung profitieren zu können, legen Sie ein eigenes Repository für Ihre Organisation an, registrieren dieses als vertrauenswürdig und platzieren dort ausschließlich Artefakte, die Sie auf Herz und Nieren geprüft haben. Im einfachsten Fall kann es sich dabei um eine Dateifreigabe auf einem zentralen Server handeln. Dort müssen Sie die Schreibrechte rigoros einschränken, denn jeder, der in diese Freigabe schreiben darf, kann Module und Skripte dort veröffentlichen. Falls Sie bereits über DevOps-Ressourcen und -Know-how verfügen, können Sie jedes DevOps-System, das einen NuGet-v2-Feed anbietet, als PowerShell-Repository verwenden. Emanuel Palm erklärt in seinem Blog, wie Sie dies mit Azure DevOps bewerkstelligen können und welche Hindernisse Sie dafür überwinden müssen.

Im zweiten Teil der Workshopserie erklären wir, wie Sie PowerShell-Code im Parser auf Plausibilität prüfen und warum auch ein Check der Skriptsignatur nicht fehlen sollte. Im dritten Teil schauen wir uns an, wie Sie fremde Skripte in einer abgeschlossenen Testumgebung unter die Lupe nehmen.

Ü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.