Funktionsweise von App-Steuerelementen mit PowerShell

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. Microsoft investiert nicht mehr in AppLocker. AppLocker erhält nur Sicherheitsupdates. App Control ist das bevorzugte Anwendungssteuerungssystem für Windows.

Erkennung der Erzwingung von Legacy-App-Control-Richtlinien

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 Erkennung der App Control-Richtliniendurchsetzung

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 unter Richtliniendurchsetzung

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, verwendet PowerShell die App Control-API, um die Durchsetzung der Richtlinie 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 Richtlinie ermöglicht die Verwendung der Datei im FullLanguage Modus mit einigen Einschränkungen.
  • WLDP_CAN_EXECUTE_BLOCKED: Die Richtlinie verbietet die Datei. PowerShell löst einen Fehler aus, wenn die Datei ausgeführt oder geladen wird.
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX: Die Richtlinie genehmigt die Datei nicht, kann aber 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 App-Kontroll-Sperrrichtlinie befindet, gelten Einschränkungen, selbst wenn das Skript vertrauenswürdig ist 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. Die Sperrmodus-Richtlinie erzwingt die folgenden Einschränkungen:

  • 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 Wildcard-Exporten verhindert eine Skriptinjektion durch einen böswilligen Benutzer, der ein nicht vertrauenswürdiges Skript platzieren kann, das per Dot-Sourcing in ein vertrauenswürdiges Modul eingebunden wird. 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 Einschränkung beim Export von Funktionen per Wildcard

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

  • Parametertypkonvertierung der interaktiven Shell

    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 Typkonvertierung bei der Parameterbindung normalerweise zulässig, schlägt jedoch bei der Ausführung im ConstrainedLanguage-Modus fehl. 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 erlaubt

    Das Enter-PSHostProcess-Cmdlet ist deaktiviert und löst bei Verwendung einen Fehler aus. Dieser Befehl wird für Sitzungen zum Anfügen und Debuggen 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

Ein Von der App-Steuerelementrichtlinie nicht genehmigtes Skript oder eine Funktion ist 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 erlaubt

    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-Beschrä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-ModuleMemberCmdlet-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 Geltungsbereichs der Skriptblockverarbeitung

    Untergeordnete Skriptblöcke dürfen nicht in den Gültigkeitsbereichen übergeordneter Skriptblöcke ausgeführt werden, wenn die Skriptblöcke unterschiedliche Vertrauensstufen aufweisen. Sie stellen z. B. eine untergeordnete Beziehung her, wenn Sie ein Skript per Dot-Sourcing in ein anderes Skript einbinden. 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 Verhindern der Erkennung nicht vertrauenswürdiger Befehle verhindert Codeinjektion durch das Platzieren von Befehlen.

  • Konvertierung von Hashtable in Objekt 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.

  • Einschränkung beim Festlegen von Variablen AllScope

    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.

  • Setter für Typeigenschaften 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

  • Last updated on