Partager via

Fonctionnement du contrôle d’application avec PowerShell

  • Article

Cet article explique comment App Control for Business sécurise PowerShell et les restrictions qu’il impose. Le comportement sécurisé de PowerShell varie en fonction de la version de Windows et de PowerShell que vous utilisez.

Comment PowerShell détecte une stratégie de verrouillage du système

PowerShell détecte les stratégies à l’échelle du système AppLocker et App Control for Business . AppLocker est déconseillé. Le contrôle d’application est le système de contrôle d’application préféré pour Windows.

Détection de la stratégie de contrôle d’application héritée

PowerShell utilise l’API App Control WldpGetLockdownPolicy héritée pour découvrir deux éléments :

  • Application d'une stratégie à l'échelle du système : None, Audit, Enforce
  • Politique en matière de fichiers individuels : None, Audit (autorisé par la stratégie), Enforce (non autorisé par la stratégie)

Toutes les versions de PowerShell (v5.1 - v7.x) prennent en charge cette détection de stratégie App Control.

Détection de la mise en œuvre de la stratégie App Control la plus récente

App Control a introduit de nouvelles API dans les versions récentes de Windows. À partir de la version 7.3, PowerShell utilise la nouvelle API WldpCanExecuteFile pour décider de la manière dont un fichier doit être traité. Windows PowerShell 5.1 ne prend pas en charge cette nouvelle API. La nouvelle API a la priorité sur l'ancienne API pour les fichiers individuels. Cependant, PowerShell continue d'utiliser l'ancienne API pour obtenir la configuration de la stratégie à l'échelle du système. Si la nouvelle API n'est pas disponible, PowerShell revient au comportement de l'ancienne API.

La nouvelle API fournit les informations suivantes pour chaque fichier :

  • WLDP_CAN_EXECUTE_ALLOWED
  • WLDP_CAN_EXECUTE_BLOCKED
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX

Comportement de PowerShell dans le cadre d'une stratégie de verrouillage

PowerShell peut fonctionner en mode interactif et non interactif.

  • En mode interactif, PowerShell est une application de ligne de commande qui prend en compte les entrées de ligne de commande des utilisateurs sous forme de commandes ou de scripts à exécuter. Les résultats sont affichés à l'utilisateur.
  • En mode non interactif, PowerShell charge les modules et exécute les fichiers de script sans intervention de l'utilisateur. Les flux de données de résultat sont soit ignorés, soit redirigés vers un fichier.

Mode interactif fonctionnant dans le cadre de l'application de la stratégie

PowerShell exécute les commandes en mode ConstrainedLanguage. Ce mode empêche les utilisateurs interactifs d'exécuter certaines commandes ou du code arbitraire. Pour plus d'informations sur les restrictions dans ce mode, voir la section de cet article consacrée aux restrictions PowerShell dans le cadre de la stratégie de verrouillage.

Mode non interactif fonctionnant dans le cadre de l'application d'une stratégie

Lorsque PowerShell exécute un script ou charge un module, il utilise l’API App Control pour obtenir l’application de la stratégie pour le fichier.

PowerShell version 7.3 ou supérieure utilise l'API WldpCanExecuteFile si elle est disponible. Cette API renvoie l'un des résultats suivants :

  • WLDP_CAN_EXECUTE_ALLOWED : Le fichier est approuvé par la stratégie et est utilisé en mode FullLanguage avec quelques restrictions.
  • WLDP_CAN_EXECUTE_BLOCKED : Le dossier n'est pas approuvé par la stratégie. PowerShell génère une erreur lorsque le fichier est exécuté ou chargé.
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX : Le fichier n'est pas approuvé par la stratégie mais il peut toujours être exécuté ou chargé en mode ConstrainedLanguage.

Dans Windows PowerShell 5.1 ou si l'API WldpCanExecuteFile n'est pas disponible, le comportement de PowerShell par fichier est le suivant :

  • None : Le fichier est exécuté en mode FullLanguage chargé avec quelques restrictions.
  • Audit : Le fichier est exécuté ou chargé en mode FullLanguage sans restriction. Dans PowerShell 7.4 ou supérieur, la stratégie enregistre les informations de restriction dans les journaux d'événements Windows.
  • Enforce : Le fichier est exécuté ou chargé en mode ConstrainedLanguage.

Restrictions PowerShell dans le cadre de la stratégie de verrouillage

Lorsque PowerShell détecte que le système est sous une stratégie de verrouillage App Control, il applique des restrictions même si le script est approuvé et en mode en FullLanguage cours d’exécution. Ces restrictions empêchent les comportements connus de PowerShell qui pourraient entraîner l'exécution de code arbitraire sur un système verrouillé. La stratégie de verrouillage applique les restrictions suivantes :

  • Module dot-sourcing avec restriction d'exportation de la fonction caractère générique

    Tout module qui utilise le point-sourcing de script et exporte des fonctions utilisant des noms de caractères génériques entraîne une erreur. Le blocage des exportations de caractères génériques empêche l'injection de scripts par un utilisateur malveillant qui peut introduire un script non fiable dans un module fiable par le biais d'une source de points. Le script malveillant peut alors accéder aux fonctions privées du module de confiance.

    Recommandation de sécurité : Ne jamais utiliser de script dot-sourcing dans un module et toujours exporter les fonctions du module avec des noms explicites (pas de caractères génériques).

  • Module imbriqué avec restriction d'exportation de fonctions caractères génériques

    Si un module parent exporte des fonctions à l'aide de caractères génériques, PowerShell supprime tout nom de fonction dans un module imbriqué de la liste d'exportation des fonctions. Le blocage des exportations de caractères génériques à partir de modules imbriqués permet d'éviter l'exportation accidentelle de fonctions imbriquées dangereuses par le biais de la correspondance des noms de caractères génériques.

    Recommandation de sécurité : Toujours exporter les fonctions des modules avec des noms explicites (pas de caractères génériques).

  • Conversion interactive des types de paramètres de l'interpréteur de commandes

    Lorsque le système est verrouillé, les sessions PowerShell interactives s'exécutent en mode ConstrainedLanguage pour empêcher l'exécution de code arbitraire. Les modules de confiance chargés dans la session s'exécutent en mode FullLanguage. Si une cmdlet de module de confiance utilise des types complexes pour ses paramètres, la conversion de type lors de la liaison des paramètres peut échouer si la conversion n'est pas autorisée à travers les frontières de confiance. L'échec survient lorsque PowerShell tente de convertir une valeur en exécutant un constructeur de type. Les constructeurs de types ne sont pas autorisés à fonctionner en mode ConstrainedLanguage.

    Dans cet exemple, la conversion du type de liaison des paramètres est normalement autorisée, mais elle échoue lorsqu'elle est exécutée en mode ConstrainedLanguage. Le constructeur de type ConnectionPort n'est pas autorisé :

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

  • cmdlet Enter-PSHostProcess non autorisée

    La cmdlet Enter-PSHostProcess est désactivée et génère une erreur si elle est utilisée. Cette commande est utilisée pour les sessions d'attachement et de débogage. Il vous permet de vous connecter à n'importe quelle autre session PowerShell sur la machine locale. La cmdlet est désactivée pour éviter la divulgation d'informations et l'exécution de code arbitraire.

Restrictions de PowerShell en mode linguistique contraint

Script ou fonction qui n’est pas approuvé par la stratégie App Control n’est pas approuvé. Lorsque vous exécutez une commande non approuvée, PowerShell bloque l'exécution de la commande (nouveau comportement) ou l'exécute en mode ConstrainedLanguage. Les restrictions suivantes s'appliquent au mode ConstrainedLanguage :

  • cmdlet Add-Type non autorisée

    Le blocage de Add-Type empêche l'exécution de code .NET arbitraire.

  • cmdlet Import-LocalizedData restreinte

    Le blocage du paramètre SupportedCommand de Import-LocalizedData empêche l'exécution de code arbitraire.

  • cmdlet Invoke-Expression restreinte

    Tous les blocs de script transmis à la cmdlet Invoke-Expression sont exécutés en mode ConstrainedLanguage afin d'empêcher l'exécution de code arbitraire.

  • cmdlet New-Object restreinte

    La cmdlet New-Object ne peut utiliser que les types .NET et COM autorisés, afin d'empêcher l'accès à des types non fiables.

  • Restriction de la cmdlet ForEach-Object

    L'invocation de méthodes de type pour les variables transmises au ForeEach-Object est interdite pour tout type .NET ne figurant pas dans la liste approuvée. Généralement, le mode ConstrainedLanguage interdit toute invocation de méthode d'objet, sauf pour les types .NET approuvés, afin d'empêcher l'accès à des types .NET non fiables.

  • Restriction de la cmdlet Export-ModuleMember

    L'utilisation de la cmdlet Export-ModuleMember pour exporter des fonctions dans un fichier de script de module imbriqué où le module enfant n'est pas de confiance et le module parent est de confiance, entraîne une erreur. Le blocage de ce scénario empêche un module malveillant non fiable d'exporter des fonctions dangereuses à partir d'un module fiable.

  • Restriction de la cmdlet New-Module

    Lorsque vous exécutez New-Module dans un script de confiance, tout bloc de script fourni par le paramètre ScriptBlock est marqué pour s'exécuter en mode ConstrainedLanguage afin d'empêcher l'injection de code arbitraire dans un contexte d'exécution de confiance.

  • Le mot clé Configuration n'est pas autorisé

    Le mot-clé du langage Configuration n'est pas autorisé en mode ConstrainedLanguage afin de prévenir les attaques par injection de code.

  • Le mot clé class n'est pas autorisé

    Le mot-clé du langage class n'est pas autorisé en mode ConstrainedLanguage afin d'éviter l'injection de code arbitraire.

  • Restrictions relatives au champ d'application du traitement des blocs de texte

    Les blocs de scripts enfants ne sont pas autorisés à s'exécuter dans les champs d'application des blocs de scripts parents si les blocs de scripts ont des niveaux de confiance différents. Par exemple, vous créez une relation enfant lorsque vous insérez un script dans un autre. Le blocage de ce scénario empêche un script non fiable d'accéder à des fonctions dangereuses dans le champ d'application du script fiable.

  • Empêcher la découverte par les commandes de fonctions de script non approuvées

    La découverte de commandes PowerShell ne renvoie pas les fonctions d'une source non approuvée, telle qu'un script ou un module non approuvé, vers une fonction approuvée. Le blocage de la découverte de commandes non fiables empêche l'injection de code par l'implantation de commandes.

  • La conversion de table de hachage en objet n'est pas autorisée

    Le mode ConstrainedLanguage bloque les conversions de tables de hachage en objets dans les sections Data des fichiers de données PowerShell (.psd1) afin de prévenir les attaques potentielles par injection de code.

  • Restriction de la conversion automatique des types

    Le mode ConstrainedLanguage bloque la conversion automatique des types, à l'exception d'un petit ensemble de types sûrs approuvés, afin de prévenir d'éventuelles attaques par injection de code.

  • Restriction implicite à l'exportation de fonctions de modules

    Si un module n'exporte pas explicitement de fonctions, PowerShell exporte implicitement toutes les fonctions définies du module, par commodité. En mode ConstrainedLanguage, les exportations implicites ne se produisent plus lorsqu'un module est chargé au-delà des limites de confiance. Le blocage des exportations implicites permet d'éviter l'exposition involontaire de fonctions de modules dangereuses qui ne sont pas destinées à un usage public.

  • Les fichiers de script ne peuvent pas être importés en tant que modules

    PowerShell vous permet d'importer des fichiers de script (.ps1) en tant que module. Toutes les fonctions définies deviennent accessibles au public. Le mode ConstrainedLanguage bloque l'importation de fichiers de script afin d'éviter l'exposition involontaire à des fonctions de script dangereuses.

  • Variables de réglage AllScope restriction

    Le mode ConstrainedLanguage désactive la possibilité de définir AllScope sur les variables. La limitation de la portée des variables empêche celles-ci d'interférer avec l'état de la session des commandes de confiance.

  • L'invocation d'une méthode de type n'est pas autorisée

    Le mode ConstrainedLanguage n'autorise pas l'invocation de méthodes sur des types non approuvés. Le blocage des méthodes sur les types non approuvés empêche l'invocation de méthodes de type .NET qui pourraient être dangereuses ou permettre l'injection de code.

  • Les fixateurs de propriétés de type ne sont pas autorisés

    Le mode ConstrainedLanguage restreint l'invocation des fixateurs de propriété sur les types non approuvés. Le blocage des fixateurs de propriété sur les types non approuvés permet d'éviter les attaques par injection de code.

  • La création de type n'est pas autorisée

    Le mode ConstrainedLanguage bloque la création de types non approuvés afin de bloquer les constructeurs non fiables qui pourraient permettre l'injection de code.

  • L'opérateur de champ d'application du module n'est pas autorisé

    Le mode ConstrainedLanguage ne permet pas l'utilisation de l'opérateur de portée du module. Par exemple : & (Get-Module MyModule) MyFunction. Le blocage de l'opérateur de portée du module empêche l'accès aux fonctions et variables privées du module.

Pour aller plus loin