© best_vector/Shutterstock.com
Windows Developer
Sicherheit der PowerShell im Überblick

PowerShell sicher einsetzen

Die PowerShell ist, wie der Name schon nahelegt, ein sehr mächtiges Werkzeug. So etwas reizt natürlich auch die Cyberkriminellen, denn was Entwickler und Benutzer im positiven Sinne nutzen, lässt sich natürlich genauso gut auch für bösartige Zwecke missbrauchen. Besonders die Möglichkeit, die Shell über Skripte zu steuern, lockt Angreifer an.

Carsten Eilers


Viele von Ihnen kennen sicher noch die Batch-File-Viren, die früher unter MS-DOS und den ersten Windows-Versionen ihr Unwesen trieben. Damit sich diese Angriffe nicht mit der PowerShell wiederholen, wurde von Anfang an auf ihre Sicherheit geachtet [1].

Am sichersten wäre es natürlich gewesen, einfach auf die Skriptfähigkeit zu verzichten, denn was nicht da ist, kann auch nicht von Angreifern missbraucht werden. Aber was soll man mit einer Shell, wenn man sie nicht über Skripte steuern kann? Also mussten die Power­Shell-Entwickler Wege suchen, um Angriffe über PowerShell-Skripte zu erschweren. Ganz verhindern kann man einen Missbrauch zwar nicht, es gibt aber kaum Angriffe auf/über die PowerShell. Eine schnelle Recherche hat nur einen tatsächlichen Schädling zum Vorschein gebracht: Eine russische Ransomware nutzt die PowerShell zum Verschlüsseln bestimmter Dateien [2]. Und das auch dann, wenn die PowerShell auf dem angegriffenen Rechner gar nicht vorhanden ist, denn dann wird sie vom Schädling selbst installiert. Aber anstelle der PowerShell hätten die Cyberkriminellen auch jede beliebige andere Software missbrauchen oder eigenen Code verwenden können. Insofern ist dieser Angriff also nicht der PowerShell anzulasten.

Sicher verknüpft: „.ps1“ gehört zum Editor und nicht zur PowerShell

Aber kommen wir zu den Schutzmaßnahmen [1], [3], [4]. Los geht es mit der Verknüpfung der Dateiendung .ps1 für PowerShell-Skripte: Per Default ist diese Endung nicht mit der PowerShell selbst, sondern dem Editor (im Allgemeinen mit dem Notepad) verknüpft. Bei einem Doppelklick auf ein PowerShell-Skript wird dieses also nicht gestartet, sondern im Editor geöffnet. Um das Skript auszuführen, muss die PowerShell geöffnet und das Skript darin gestartet werden.

Skriptaufruf nur mit Pfad und Namen

Um zu verhindern, dass ein Angreifer einem Benutzer ein PowerShell-Skript mit dem gleichen Namen wie einem integrierten PowerShell-Befehl unterschiebt, das dann beim Aufruf des Befehls anstelle des eigentlichen Befehls ausgeführt wird („Befehlsaneignung“), müssen PowerShell-Skripte im Allgemeinen mit ihrem Pfad aufgerufen werden. Das Skript test.ps1 im aktuellen Verzeichnis kann also nicht über test aufgerufen werden, sondern nur über .\test, oder über seinen vollständigen Pfad, z. B. c:\scripts\test.ps1. Der Aufruf als test.ps1 ist nur möglich, wenn sich das Skript in einem Verzeichnis befindet, das in der PATH-Environment-Variable von Windows enthalten ist.

Aber auch wenn Sie das Skript mit ...

Windows Developer
Sicherheit der PowerShell im Überblick

PowerShell sicher einsetzen

Die PowerShell ist, wie der Name schon nahelegt, ein sehr mächtiges Werkzeug. So etwas reizt natürlich auch die Cyberkriminellen, denn was Entwickler und Benutzer im positiven Sinne nutzen, lässt sich natürlich genauso gut auch für bösartige Zwecke missbrauchen. Besonders die Möglichkeit, die Shell über Skripte zu steuern, lockt Angreifer an.

Carsten Eilers


Viele von Ihnen kennen sicher noch die Batch-File-Viren, die früher unter MS-DOS und den ersten Windows-Versionen ihr Unwesen trieben. Damit sich diese Angriffe nicht mit der PowerShell wiederholen, wurde von Anfang an auf ihre Sicherheit geachtet [1].

Am sichersten wäre es natürlich gewesen, einfach auf die Skriptfähigkeit zu verzichten, denn was nicht da ist, kann auch nicht von Angreifern missbraucht werden. Aber was soll man mit einer Shell, wenn man sie nicht über Skripte steuern kann? Also mussten die Power­Shell-Entwickler Wege suchen, um Angriffe über PowerShell-Skripte zu erschweren. Ganz verhindern kann man einen Missbrauch zwar nicht, es gibt aber kaum Angriffe auf/über die PowerShell. Eine schnelle Recherche hat nur einen tatsächlichen Schädling zum Vorschein gebracht: Eine russische Ransomware nutzt die PowerShell zum Verschlüsseln bestimmter Dateien [2]. Und das auch dann, wenn die PowerShell auf dem angegriffenen Rechner gar nicht vorhanden ist, denn dann wird sie vom Schädling selbst installiert. Aber anstelle der PowerShell hätten die Cyberkriminellen auch jede beliebige andere Software missbrauchen oder eigenen Code verwenden können. Insofern ist dieser Angriff also nicht der PowerShell anzulasten.

Sicher verknüpft: „.ps1“ gehört zum Editor und nicht zur PowerShell

Aber kommen wir zu den Schutzmaßnahmen [1], [3], [4]. Los geht es mit der Verknüpfung der Dateiendung .ps1 für PowerShell-Skripte: Per Default ist diese Endung nicht mit der PowerShell selbst, sondern dem Editor (im Allgemeinen mit dem Notepad) verknüpft. Bei einem Doppelklick auf ein PowerShell-Skript wird dieses also nicht gestartet, sondern im Editor geöffnet. Um das Skript auszuführen, muss die PowerShell geöffnet und das Skript darin gestartet werden.

Skriptaufruf nur mit Pfad und Namen

Um zu verhindern, dass ein Angreifer einem Benutzer ein PowerShell-Skript mit dem gleichen Namen wie einem integrierten PowerShell-Befehl unterschiebt, das dann beim Aufruf des Befehls anstelle des eigentlichen Befehls ausgeführt wird („Befehlsaneignung“), müssen PowerShell-Skripte im Allgemeinen mit ihrem Pfad aufgerufen werden. Das Skript test.ps1 im aktuellen Verzeichnis kann also nicht über test aufgerufen werden, sondern nur über .\test, oder über seinen vollständigen Pfad, z. B. c:\scripts\test.ps1. Der Aufruf als test.ps1 ist nur möglich, wenn sich das Skript in einem Verzeichnis befindet, das in der PATH-Environment-Variable von Windows enthalten ist.

Aber auch wenn Sie das Skript mit ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang