Dela via

Så här fungerar App Control med PowerShell

  • Artikel

Den här artikeln beskriver hur App Control för företag skyddar PowerShell och de begränsningar som det medför. Det säkra beteendet för PowerShell varierar beroende på vilken version av Windows och PowerShell du använder.

Så identifierar PowerShell en princip för systemlåsning

PowerShell identifierar både AppLocker och App Control for Business system wide polices. AppLocker är inaktuellt. Appkontroll är det föredragna programkontrollsystemet för Windows.

Identifiering av tvingande principer för äldre appkontroll

PowerShell använder det äldre Api:et för appkontroll WldpGetLockdownPolicy för att identifiera två saker:

  • Systemomfattande principframtvingande: None, Audit, Enforce
  • Enskild filprincip: None, Audit (tillåts av princip) Enforce (tillåts inte av principen)

Alla versioner av PowerShell (v5.1 – v7.x) stöder den här appkontrollprincipidentifieringen.

Senaste tvingande identifiering av appkontrollprincip

App Control introducerade nya API:er i de senaste versionerna av Windows. Från och med version 7.3 använder PowerShell det nya WldpCanExecuteFile API:et för att bestämma hur en fil ska hanteras. Windows PowerShell 5.1 stöder inte det här nya API:et. Det nya API:et har företräde framför det äldre API:et för enskilda filer. PowerShell fortsätter dock att använda det äldre API:et för att hämta systemomfattande principkonfiguration. Om det nya API:et inte är tillgängligt återgår PowerShell till det gamla API-beteendet.

Det nya API:et innehåller följande information för varje fil:

  • WLDP_CAN_EXECUTE_ALLOWED
  • WLDP_CAN_EXECUTE_BLOCKED
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX

PowerShell-beteende under låsningsprincip

PowerShell kan köras i både interaktiva och icke-interaktiva lägen.

  • I interaktivt läge är PowerShell ett kommandoradsprogram som tar användarnas kommandoradsindata som kommandon eller skript att köra. Resultaten visas tillbaka till användaren.
  • I icke-interaktivt läge läser PowerShell in moduler och kör skriptfiler utan användarindata. Resultatdataströmmar ignoreras eller omdirigeras till en fil.

Interaktivt läge som körs under principframtvingande

PowerShell kör kommandon i ConstrainedLanguage läge. Det här läget hindrar interaktiva användare från att köra vissa kommandon eller köra godtycklig kod. Mer information om begränsningarna i det här läget finns i avsnittet PowerShell-begränsningar under låsningsprincip i den här artikeln.

Icke-interaktivt läge som körs under principframtvingande

När PowerShell kör ett skript eller läser in en modul använder den App Control-API:et för att hämta principtillämpningen för filen.

PowerShell version 7.3 eller senare använder API:et om det WldpCanExecuteFile är tillgängligt. Det här API:et returnerar något av följande resultat:

  • WLDP_CAN_EXECUTE_ALLOWED: Filen är godkänd av en princip och används i FullLanguage läge med några begränsningar.
  • WLDP_CAN_EXECUTE_BLOCKED: Filen är inte godkänd av principen. PowerShell genererar ett fel när filen körs eller läses in.
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX: Filen är inte godkänd av principen, men den kan fortfarande köras eller läsas in i ConstrainedLanguage läge.

I Windows PowerShell 5.1 eller om WldpCanExecuteFile API:et inte är tillgängligt är PowerShells beteende per fil:

  • None: Filen körs i FullLanguage läget med några begränsningar.
  • Audit: Filen körs eller läses in i FullLanguage läge utan begränsningar. I PowerShell 7.4 eller senare loggar principen begränsningsinformation till Windows-händelseloggarna.
  • Enforce: Filen körs eller läses in i ConstrainedLanguage läge.

PowerShell-begränsningar under låsningsprincip

När PowerShell identifierar att systemet är under en appkontrollslåsningsprincip tillämpas begränsningar även om skriptet är betrott och körs i FullLanguage läge. Dessa begränsningar förhindrar kända beteenden i PowerShell som kan leda till godtycklig kodkörning i ett låst system. Låsningsprincipen tillämpar följande begränsningar:

  • Modul dot-sourcing med begränsning av jokerteckenfunktionsexport

    Alla moduler som använder funktioner för dot-sourcing och export av skript med jokertecken resulterar i ett fel. Blockering av jokerteckenexport förhindrar skriptinmatning från en obehörig användare som kan plantera ett obetrott skript som får punktkälla till en betrodd modul. Det skadliga skriptet kan sedan få åtkomst till den betrodda modulens privata funktioner.

    Säkerhetsrekommendations: Använd aldrig skript dot-sourcing i en modul och exportera alltid modulfunktioner med explicita namn (inga jokertecken).

  • Kapslad modul med exportbegränsning för jokertecken

    Om en överordnad modul exporterar funktioner med jokertecken för funktionsnamn tar PowerShell bort alla funktionsnamn i en kapslad modul från funktionsexportlistan. Om du blockerar jokerteckenexporter från kapslade moduler förhindras oavsiktlig export av farliga kapslade funktioner via matchning av jokerteckennamn.

    Säkerhetsrekommendations: Exportera alltid modulfunktioner med explicita namn (inga jokertecken).

  • Konvertering av parametertyp för interaktivt gränssnitt

    När systemet är låst körs interaktiva PowerShell-sessioner i ConstrainedLanguage läge för att förhindra godtycklig kodkörning. Betrodda moduler som läses in i sessionen körs i FullLanguage läge. Om en cmdlet för betrodd modul använder komplexa typer för sina parametrar kan typkonverteringen under parameterbindningen misslyckas om konverteringen inte tillåts över förtroendegränser. Felet uppstår när PowerShell försöker konvertera ett värde genom att köra en typkonstruktor. Typkonstruktorer får inte köras i ConstrainedLanguage läge.

    I det här exemplet tillåts konvertering av parameterbindningstyp normalt, men misslyckas när den körs i ConstrainedLanguage läge. Typkonstruktorn ConnectionPort tillåts inte:

    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 tillåts inte

    Cmdleten Enter-PSHostProcess är inaktiverad och genererar ett fel om den används. Det här kommandot används för anslutnings- och felsökningssessioner. Det gör att du kan ansluta till andra PowerShell-sessioner på den lokala datorn. Cmdleten är inaktiverad för att förhindra avslöjande av information och godtycklig kodkörning.

PowerShell-begränsningar under begränsat språkläge

Skript eller funktioner som inte har godkänts av appkontrollprincipen är inte betrodda. När du kör ett ej betrott kommando blockerar PowerShell antingen kommandot från att köras (nytt beteende) eller kör kommandot i ConstrainedLanguage läge. Följande begränsningar gäller för ConstrainedLanguage läge:

  • Add-Type cmdlet tillåts inte

    Blockering Add-Type förhindrar körning av godtycklig .NET-kod.

  • Import-LocalizedData cmdlet begränsad

    Om parametern SupportedCommand blockeras Import-LocalizedData förhindras körning av godtycklig kod.

  • Invoke-Expression cmdlet begränsad

    Alla skriptblock som skickas till cmdleten Invoke-Expression körs i ConstrainedLanguage läge för att förhindra godtycklig kodkörning.

  • New-Object cmdlet begränsad

    Cmdleten New-Object är begränsad till att endast använda tillåtna .NET- och COM-typer för att förhindra åtkomst till ej betrodda typer.

  • ForEach-Object cmdlet-begränsning

    Typmetodanrop för variabler som skickas till ForeEach-Object tillåts inte för alla .NET-typer som inte finns i listan över godkända. I allmänhet ConstrainedLanguage tillåter läget inte anrop av objektmetoder förutom godkända .NET-typer för att förhindra åtkomst till ej betrodda .NET-typer.

  • Export-ModuleMember cmdlet-begränsning

    Om du använder Export-ModuleMember cmdlet för att exportera funktioner i en kapslad modulskriptfil där den underordnade modulen inte är betrodd och den överordnade modulen är betrodd resulterar det i ett fel. Om du blockerar det här scenariot förhindrar du att en opålitlig modul exporterar farliga funktioner från en betrodd modul.

  • New-Module cmdlet-begränsning

    När du kör New-Module i ett betrott skript markeras alla skriptblock som tillhandahålls av parametern ScriptBlock för att köras i ConstrainedLanguage läge för att förhindra inmatning av godtycklig kod i en betrodd körningskontext.

  • Configuration nyckelord tillåts inte

    Språknyckelordet Configuration tillåts inte i ConstrainedLanguage läge för att förhindra kodinmatningsattacker.

  • class nyckelord tillåts inte

    Språknyckelordet class tillåts inte i ConstrainedLanguage läge för att förhindra inmatning av godtycklig kod.

  • Begränsningar för omfång för skriptblockbearbetning

    Underordnade skriptblock tillåts inte köras i överordnade skriptblocksomfång om skriptblocken har olika förtroendenivåer. Du kan till exempel skapa en underordnad relation när du punktkälla ett skript till ett annat. Om du blockerar det här scenariot förhindrar du att ett skript som inte är betrott får åtkomst till farliga funktioner i det betrodda skriptomfånget.

  • Förhindra kommandoidentifiering av obetrodda skriptfunktioner

    PowerShell-kommandoidentifiering returnerar inte funktioner från en ej betrodd källa, till exempel ett skript eller en modul som inte är betrodd, till en betrodd funktion. Blockera identifiering av ej betrodda kommandon förhindrar kodinmatning via kommandoplantering.

  • Hashtable till objektkonvertering tillåts inte

    ConstrainedLanguage läge blockerar hashtable till objektkonverteringar i avsnitten Data i PowerShell-datafiler (.psd1) för att förhindra potentiella kodinmatningsattacker.

  • Automatisk typkonvertering begränsad

    ConstrainedLanguage läge blockerar automatisk typkonvertering förutom en liten uppsättning godkända säkra typer för att förhindra potentiella kodinmatningsattacker.

  • Exportbegränsning för implicit modulfunktion

    Om en modul inte uttryckligen exporterar funktioner exporterar PowerShell implicit alla definierade modulfunktioner automatiskt som en bekvämlighetsfunktion. I ConstrainedLanguage läge sker inte längre implicita exporter när en modul läses in över förtroendegränser. Blockera implicit export förhindrar oavsiktlig exponering av farliga modulfunktioner som inte är avsedda för offentligt bruk.

  • Skriptfiler kan inte importeras som moduler

    Med PowerShell kan du importera skriptfiler (.ps1) som en modul. Alla definierade funktioner blir offentligt tillgängliga. ConstrainedLanguage läge blockerar import av skriptfil för att förhindra oavsiktlig exponering av farliga skriptfunktioner.

  • Inställning av begränsning av variabler AllScope

    ConstrainedLanguage läget inaktiverar möjligheten att ange AllScope variabler. Om du begränsar variablernas omfång hindras variablerna från att störa sessionstillståndet för betrodda kommandon.

  • Typmetodanrop tillåts inte

    ConstrainedLanguage läge tillåter inte metodanrop på icke godkända typer. Blockeringsmetoder på icke godkända typer förhindrar anrop av .NET-typmetoder som kan vara farliga eller tillåta kodinmatning.

  • Typegenskapsuppsättningar tillåts inte

    ConstrainedLanguage läge begränsar anrop av egenskapsuppsättningar för icke godkända typer. Blockering av egenskapsuppsättningar på icke godkända typer förhindrar kodinmatningsattacker.

  • Det går inte att skapa typen

    ConstrainedLanguage läge blockerar skapande av typ på icke godkända typer för att blockera obetrodda konstruktorer som kan tillåta kodinmatning.

  • Modulomfångsoperatorn tillåts inte

    ConstrainedLanguage -läget tillåter inte användning av modulomfångsoperatorn. Exempel: & (Get-Module MyModule) MyFunction. Om du blockerar modulomfångsoperatorn förhindras åtkomst till privata funktioner och variabler för modulen.

Ytterligare läsning