Freigeben über

Funktionsweise von App-Steuerelementen mit PowerShell

  • Artikel

In diesem Artikel wird erläutert, wie App Control for Business PowerShell und die von ihr auferlegten Einschränkungen sichert. Das sichere Verhalten von PowerShell variiert je nach der verwendeten Version von Windows und PowerShell.

So erkennt PowerShell eine Systemsperrungsrichtlinie

PowerShell erkennt sowohl AppLocker als auch App Control for Business systemweite Richtlinien. AppLocker ist veraltet. App Control ist das bevorzugte Anwendungssteuerungssystem für Windows.

Erzwingungserkennung für Legacy-App-Steuerungsrichtlinien

PowerShell verwendet die ältere App-Steuerelement-API WldpGetLockdownPolicy , um zwei Dinge zu ermitteln:

  • Systemweite Richtlinienerzwingung: None, Audit, Enforce
  • Einzelne Dateirichtlinie: None, (Audit durch Richtlinie zugelassen), Enforce (nicht durch Richtlinie zugelassen)

Alle Versionen von PowerShell (v5.1 – v7.x) unterstützen diese App-Steuerelementrichtlinienerkennung.

Neueste Erzwingungserkennung der App-Steuerungsrichtlinie

App Control hat neue APIs in neueren Versionen von Windows eingeführt. Ab Version 7.3 verwendet PowerShell die neue WldpCanExecuteFile-API, um zu entscheiden, wie eine Datei behandelt werden soll. Windows PowerShell 5.1 unterstützt diese neue API nicht. Die neue API hat Vorrang vor der Vorversion der API für einzelne Dateien. PowerShell verwendet jedoch weiterhin die Vorversion der API, um die systemweite Richtlinienkonfiguration abzurufen. Wenn die neue API nicht verfügbar ist, greift PowerShell auf das alte API-Verhalten zurück.

Die neue API enthält die folgenden Informationen für jede Datei:

  • WLDP_CAN_EXECUTE_ALLOWED
  • WLDP_CAN_EXECUTE_BLOCKED
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX

PowerShell-Verhalten unter Sperrmodusrichtlinie

PowerShell kann sowohl im interaktiven als auch im nicht interaktiven Modus ausgeführt werden.

  • Im interaktiven Modus ist PowerShell eine Befehlszeilenanwendung, die Befehlszeileneingaben durch den Benutzer als Befehle oder Skripts ausführt. Die Ergebnisse werden wieder dem Benutzer angezeigt.
  • Im nicht interaktiven Modus lädt PowerShell Module und führt Skriptdateien ohne Benutzereingabe aus. Ergebnisdatenströme werden entweder ignoriert oder an eine Datei umgeleitet.

Interaktiver Modus, der unter Richtlinienerzwingung ausgeführt wird

PowerShell führt Befehle im ConstrainedLanguage-Modus aus. Dieser Modus verhindert, dass interaktive Benutzer bestimmte Befehle ausführen oder beliebigen Code ausführen. Weitere Informationen zu den Einschränkungen in diesem Modus finden Sie in den PowerShell-Einschränkungen im Abschnitt Sperrmodusrichtlinie in diesem Artikel.

Nicht interaktiver Modus, der unter Richtlinienerzwingung ausgeführt wird

Wenn PowerShell ein Skript ausführt oder ein Modul lädt, wird die App-Steuerelement-API verwendet, um die Richtlinienerzwingung für die Datei abzurufen.

PowerShell Version 7.3 oder höher verwendet die WldpCanExecuteFile-API, falls verfügbar. Diese API gibt eines der folgenden Ergebnisse zurück:

  • WLDP_CAN_EXECUTE_ALLOWED: Die Datei wird von der Richtlinie genehmigt und wird im FullLanguage-Modus mit einigen Einschränkungen verwendet.
  • WLDP_CAN_EXECUTE_BLOCKED: Die Datei wird von der Richtlinie nicht genehmigt. PowerShell löst einen Fehler aus, wenn die Datei ausgeführt oder geladen wird.
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX: Die Datei wird von der Richtlinie nicht genehmigt, kann aber weiterhin im ConstrainedLanguage-Modus ausgeführt oder geladen werden.

In Windows PowerShell 5.1 oder wenn die WldpCanExecuteFile-API nicht verfügbar ist, definiert sich das Verhalten pro Datei von PowerShell wie folgt:

  • None: Die Datei wird im FullLanguage-Modus mit einigen Einschränkungen geladen.
  • Audit: Die Datei wird im FullLanguage-Modus ohne Einschränkungen geladen. In PowerShell 7.4 oder höher protokolliert die Richtlinie Einschränkungsinformationen in den Windows-Ereignisprotokollen.
  • Enforce: Die Datei wird im ConstrainedLanguage-Modus ausgeführt oder geladen.

PowerShell-Einschränkungen unter Sperrmodusrichtlinie

Wenn PowerShell erkennt, dass sich das System unter einer Sperrmodusrichtlinie für App-Steuerelement befindet, gelten Einschränkungen, auch wenn das Skript vertrauenswürdig und im FullLanguage Modus ausgeführt wird. Diese Einschränkungen verhindern bekanntes Verhalten von PowerShell, die zu einer beliebigen Codeausführung in einem gesperrten System führen könnten. Mit der Sperrrmodusichtlinie werden die folgenden Einschränkungen angewendet:

  • Modul dot-sourcing mit Exporteinschränkung der Platzhalterfunktion

    Jedes Modul, das Skript-Dot-Sourcing verwendet und Funktionen mithilfe von Platzhalternamen exportiert, führt zu einem Fehler. Das Blockieren von Platzhalterexporten verhindert die Einschleusung von Skripten durch einen böswilligen Benutzer, der ein nicht vertrauenswürdiges Skript in ein vertrauenswürdiges dot-sourced Modul einschleusen kann. Das bösartige Skript könnte dann Zugriff auf die privaten Funktionen des vertrauenswürdigen Moduls erhalten.

    Sicherheitsempfehlung: Verwenden Sie kein Skript-Dot-sourcing in einem Modul, und exportieren Sie Modulfunktionen immer mit expliziten Namen (keine Platzhalterzeichen).

  • Geschachteltes Modul mit Exporteinschränkung für Platzhalterfunktionen

    Wenn ein übergeordnetes Modul Funktionen mithilfe von Platzhalterzeichen mit Funktionsnamen exportiert, entfernt PowerShell jeden Funktionsnamen in einem geschachtelten Modul aus der Funktionsexportliste. Das Blockieren von Platzhalterexporten aus geschachtelten Modulen verhindert den versehentlichen Export gefährlicher geschachtelter Funktionen durch den Übereinstimmen von Platzhalternamen.

    Sicherheitsempfehlung: Exportieren Sie Modulfunktionen immer mit expliziten Namen (keine Platzhalterzeichen).

  • Konvertierung des interaktiven Shellparametertyps

    Wenn das System gesperrt ist, werden interaktive PowerShell-Sitzungen im ConstrainedLanguage-Modus ausgeführt, um die beliebige Codeausführung zu verhindern. Vertrauenswürdige Module, die in die Sitzung geladen werden, werden im FullLanguage-Modus ausgeführt. Wenn ein Cmdlet für vertrauenswürdige Module komplexe Typen für seine Parameter verwendet, kann die Typkonvertierung während der Parameterbindung fehlschlagen, wenn die Konvertierung nicht über vertrauenswürdige Grenzen hinweg zulässig ist. Der Fehler tritt auf, wenn PowerShell versucht, einen Wert durch Ausführen eines Typkonstruktors zu konvertieren. Typkonstruktoren dürfen nicht im ConstrainedLanguage-Modus ausgeführt werden.

    In diesem Beispiel ist die Konvertierung des Parameterbindungstyps normalerweise zulässig, schlägt jedoch fehl, wenn er im ConstrainedLanguage-Modus ausgeführt wird. Der ConnectionPort-Typkonstruktor ist nicht zulässig:

    PS> Create-ConnectionOnPort -Connection 22
Create-ConnectionOnPort: Cannot bind parameter 'Connection'. Cannot convert the "22"
value of type "System.Int32" to type "ConnectionPort".

  • Enter-PSHostProcess cmdlet nicht zulässig

    Das Enter-PSHostProcess-Cmdlet ist deaktiviert und löst bei Verwendung einen Fehler aus. Dieser Befehl wird für Anlagen- und Debugsitzungen verwendet. Sie können damit eine Verbindung mit jeder anderen PowerShell-Sitzung auf dem lokalen Computer herstellen. Das Cmdlet ist deaktiviert, um die Veröffentlichung von Informationen und die beliebige Codeausführung zu verhindern.

PowerShell-Einschränkungen im eingeschränkten Sprachmodus

Skripts oder Funktionen, die von der App-Steuerelementrichtlinie nicht genehmigt werden, sind nicht vertrauenswürdig. Wenn Sie einen nicht vertrauenswürdigen Befehl ausführen, blockiert PowerShell entweder die Ausführung des Befehls (neues Verhalten) oder führt den Befehl im ConstrainedLanguage-Modus aus. Es gelten folgende Einschränkungen für den ConstrainedLanguage-Modus:

  • Add-Type cmdlet nicht zulässig

    Das Blockieren von Add-Type verhindert die Ausführung von beliebigem .NET-Code.

  • Import-LocalizedData-cmdlet eingeschränkt

    Das Blockieren des SupportedCommand-Parameters von Import-LocalizedData verhindert die beliebige Codeausführung.

  • Invoke-Expression-cmdlet eingeschränkt

    Alle an das Invoke-Expression-cmdlet übergebenen Skriptblöcke werden im ConstrainedLanguage-Modus ausgeführt, um die beliebige Codeausführung zu verhindern.

  • New-Object-cmdlet eingeschränkt

    Das New-Object-cmdlet ist auf die Verwendung zulässiger .NET- und COM-Typen beschränkt, um den Zugriff auf nicht vertrauenswürdige Typen zu verhindern.

  • ForEach-Object-cmdlet-Einschränkung

    Der Aufruf der Typmethode für Variablen, die an ForeEach-Object übergeben werden, ist für jeden .NET-Typ unzulässig, der nicht in der genehmigten Liste enthalten ist. Im Allgemeinen verbietet der ConstrainedLanguage-Modus jegliche Objektmethodenaufrufe mit Ausnahme genehmigter .NET-Typen, um den Zugriff auf nicht vertrauenswürdige .NET-Typen zu verhindern.

  • Export-ModuleMember-cmdlet-Einschränkung

    Das Verwenden des Export-ModuleMember-cmdlets zum Exportieren von Funktionen in einer geschachtelten Modulskriptdatei, in der das untergeordnete Modul nicht vertrauenswürdig ist und das übergeordnete Modul vertrauenswürdig ist, führt zu einem Fehler. Das Blockieren dieses Szenarios verhindert, dass ein schädliches nicht vertrauenswürdiges Modul gefährliche Funktionen aus einem vertrauenswürdigen Modul exportiert.

  • New-Module-cmdlet-Einschränkung

    Wenn Sie New-Module in einem vertrauenswürdigen Skript ausführen, wird jeder vom ScriptBlock-Parameter bereitgestellte Skriptblock so markiert, dass er im ConstrainedLanguage-Modus ausgeführt wird, um zu verhindern, dass beliebiger Code in einen vertrauenswürdigen Ausführungskontext eingefügt wird.

  • Configuration-Schlüsselwort nicht zulässig

    Das Configuration-Schlüsselwort für die Sprache ist im ConstrainedLanguage-Modus nicht zulässig, um Angriffe mit Codeeinfügung zu verhindern.

  • class-Schlüsselwort nicht zulässig

    Das class-Schlüsselwort für die Sprache ist im ConstrainedLanguage-Modus nicht zulässig, um die Einfügung von beliebigem Code zu verhindern.

  • Einschränkungen des Skriptblockverarbeitungsbereichs

    Untergeordnete Skriptblöcke dürfen nicht in übergeordneten Skript-Blockbereichen ausgeführt werden, wenn die Skriptblöcke unterschiedliche Vertrauensebenen aufweisen. Sie erstellen z. B. eine untergeordnete Beziehung, wenn Sie ein Skript als Punktquelle in ein anderes Skript einfügen. Das Blockieren dieses Szenarios verhindert, dass ein nicht vertrauenswürdiges Skript zugriff auf gefährliche Funktionen im Bereich vertrauenswürdiger Skripts erhält.

  • Verhindern der Befehlsermittlung von nicht vertrauenswürdigen Skriptfunktionen

    Die PowerShell-Befehlsermittlung gibt keine Funktionen aus einer nicht vertrauenswürdigen Quelle zurück, z. B. einem nicht vertrauenswürdigen Skript oder Modul, an eine vertrauenswürdige Funktion. Das Blockieren der Erkennung von nicht vertrauenswürdigen Befehlen verhindert die Codeeinfügung über die Befehlsanlage.

  • Hashtable zu Objektkonvertierung nicht zulässig

    ConstrainedLanguage-Modus blockiert die Konvertierung von Hash-Tabellen in Objekte in den Data-Abschnitten der PowerShell-Daten (.psd1)-Dateien, um mögliche Angriffe mit Codeeinfügung zu verhindern.

  • Automatische Typkonvertierung eingeschränkt

    ConstrainedLanguage-Modus blockiert die automatische Typkonvertierung mit Ausnahme einer kleinen Gruppe genehmigter sicherer Typen, um potenzielle Angriffe mit Codeeinfügung zu verhindern.

  • Exporteinschränkung für implizite Modulfunktionen

    Wenn ein Modul Funktionen nicht explizit exportiert, exportiert PowerShell implizit alle definierten Modulfunktionen automatisch als praktisches Feature. Im ConstrainedLanguage-Modus treten implizite Exporte nicht mehr auf, wenn ein Modul über vertrauenswürdige Grenzen geladen wird. Das Blockieren impliziter Exporte verhindert unbeabsichtigte Exposition von gefährlichen Modulfunktionen, die nicht für die öffentliche Verwendung vorgesehen sind.

  • Skriptdateien können nicht als Module importiert werden

    PowerShell ermöglicht Ihnen das Importieren von Skriptdateien (.ps1) als Modul. Alle definierten Funktionen werden öffentlich zugänglich. Im ConstrainedLanguage-Modus wird die Importierung der Skriptdatei blockiert, um unbeabsichtigte Gefährdung gefährlicher Skriptfunktionen zu verhindern.

  • Festlegen der Variablen AllScope Einschränkung

    Im ConstrainedLanguage-Modus wird die Möglichkeit zum Festlegen von AllScope auf Variablen deaktiviert. Durch das Einschränken des Variablenumfangs wird verhindert, dass die Variablen den Sitzungszustand vertrauenswürdiger Befehle beeinträchtigen.

  • Typmethodenaufruf nicht zulässig

    Der ConstrainedLanguage-Modus lässt den Methodenaufruf für nicht genehmigte Typen nicht zu. Das Blockieren von Methoden für nicht genehmigte Typen verhindert den Aufruf von .NET-Typmethoden, die gefährlich sein können oder die Einfügung von Code zulassen.

  • Typeneigenschaftssetter sind nicht zulässig

    Der ConstrainedLanguage-Modus schränkt den Aufruf von Eigenschaftensettern für nicht genehmigte Typen ein. Das Blockieren von Eigenschaftensettern für nicht genehmigte Typen verhindert Angriffe mit Codeeinfügung.

  • Typerstellung nicht zulässig

    Im ConstrainedLanguage-Modus wird die Typerstellung für nicht genehmigte Typen blockiert, um nicht vertrauenswürdige Konstruktoren zu blockieren, die die Codeeinfügung zulassen können.

  • Modulbereichsoperator nicht zulässig

    Der ConstrainedLanguage-Modus lässt die Verwendung des Modulbereichsoperators nicht zu. Beispiel: & (Get-Module MyModule) MyFunction Das Blockieren des Modulbereichsoperators verhindert den Zugriff auf private Modulfunktionen und -variablen.

Weitere Informationen