Pourquoi et comment Windows et PowerShell empêchent-ils l'exécution de scripts?
PowerShell est en réalité le shell de commande et le langage de script destinés à remplacer les scripts CMD et batch sur les systèmes Windows. En tant que tel, un script PowerShell peut être configuré pour faire tout ce que vous pouvez faire manuellement à partir de la ligne de commande. Cela équivaut à effectuer pratiquement tous les changements possibles sur votre système, dans la limite des restrictions en vigueur sur votre compte utilisateur. Ainsi, si vous pouviez simplement cliquer deux fois sur un script PowerShell et l'exécuter avec les privilèges d'administrateur complets, une simple couche unique comme celle-ci pourrait vraiment gâcher votre journée:
Get-ChildItem '$env:SystemDrive' -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
NE PAS exécuter la commande ci-dessus!
Cela passe simplement par le système de fichiers et supprime tout ce qu'il peut. Fait intéressant, cela peut ne pas rendre le système inutilisable aussi rapidement que vous pourriez le penser, même lorsqu'il est exécuté à partir d'une session avec privilèges élevés. Mais si quelqu'un vous appelle après avoir exécuté ce script, parce que soudainement, ils ne peuvent pas trouver leurs fichiers ni exécuter certains programmes, «l'éteindre et l'activer à nouveau» les mènera probablement dans Windows Startup Repair où ils seront avertis. rien qui puisse être fait pour résoudre le problème. Ce qui pourrait être pire, c’est qu'au lieu d’obtenir un script qui bloque leur système de fichiers, votre ami pourrait être amené à en exécuter un qui télécharge et installe un enregistreur de frappe ou un service d’accès à distance. Ensuite, au lieu de vous poser des questions sur Startup Repair, ils risquent de poser des questions à la police sur la fraude bancaire!
Il devrait maintenant être évident de comprendre pourquoi certaines choses sont nécessaires pour protéger les utilisateurs finaux contre eux-mêmes, pour ainsi dire. Mais les utilisateurs chevronnés, les administrateurs système et les autres geeks sont généralement (à quelques exceptions près) un peu plus méfiants vis-à-vis de ces menaces, sachant les repérer et les éviter facilement, et souhaitant simplement poursuivre leur travail. Pour ce faire, ils devront soit désactiver, soit contourner quelques obstacles:
- PowerShell n'autorise pas l'exécution de script externe par défaut. Le paramètre ExecutionPolicy de PowerShell empêche l’exécution de scripts externes par défaut dans toutes les versions de Windows. Dans certaines versions de Windows, la valeur par défaut n’autorise pas l’exécution de script. Nous vous avons montré comment modifier ce paramètre dans Comment autoriser l'exécution de scripts PowerShell sous Windows 7, mais nous allons en parler ici à plusieurs niveaux.
- PowerShell n'est pas associé à l'extension de fichier.PS1 par défaut. Nous en avons parlé initialement dans notre série PowerShell Geek School. Windows définit l'action par défaut pour que les fichiers.PS1 les ouvrent dans le Bloc-notes au lieu de les envoyer à l'interpréteur de commandes PowerShell. Ceci permet d'éviter directement l'exécution accidentelle de scripts malveillants lorsqu'ils sont simplement double-cliqués.
- Certains scripts PowerShell ne fonctionneront pas sans autorisations d'administrateur. Même si vous utilisez un compte de niveau administrateur, vous devez toujours utiliser le contrôle de compte d'utilisateur pour effectuer certaines actions. Pour les outils de ligne de commande, cela peut être un peu lourd pour le moins. Nous ne souhaitons pas désactiver le contrôle de compte d'utilisateur, mais cela reste agréable quand nous pouvons le rendre un peu plus facile à gérer.
Ces mêmes problèmes sont abordés dans Comment utiliser un fichier de traitement des commandes pour faciliter l’exécution des scripts PowerShell, dans lequel nous vous expliquons comment écrire un fichier de traitement par lots pour les contourner temporairement. Nous allons maintenant vous montrer comment configurer votre système avec une solution à plus long terme. N'oubliez pas qu'en règle générale, vous ne devez pas effectuer ces modifications sur des systèmes que vous n'utilisez pas exclusivement. Dans le cas contraire, vous exposez les autres utilisateurs au risque de rencontrer les mêmes problèmes que ces fonctionnalités sont destinées à éviter.
Changer l’association de fichier.PS1.
L'association par défaut des fichiers.PS1 est le premier et peut-être le principal ennui à contourner. L'association de ces fichiers à autre chose que PowerShell.exe est utile pour empêcher l'exécution accidentelle de scripts indésirables. Toutefois, étant donné que PowerShell est livré avec un environnement ISE (Integrated Scripting Environment) spécialement conçu pour l'édition de scripts PowerShell, pourquoi voudrions-nous ouvrir les fichiers.PS1 dans le Bloc-notes par défaut? Même si vous n'êtes pas prêt à activer complètement la fonctionnalité de double-clic pour exécuter, vous voudrez probablement modifier ces paramètres.
Vous pouvez modifier l'association de fichier.PS1 en choisissant le programme de votre choix à l'aide du panneau de configuration par défaut, mais le fait de creuser directement dans le registre vous donnera un peu plus de contrôle sur le mode d'ouverture des fichiers. Cela vous permet également de définir ou de modifier des options supplémentaires disponibles dans le menu contextuel pour les fichiers.PS1. N’oubliez pas de faire une sauvegarde du registre avant de le faire!
Les paramètres de registre contrôlant le mode d'ouverture des scripts PowerShell sont stockés à l'emplacement suivant:
HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell
Pour explorer ces paramètres avant de les modifier, jetez un œil à cette clé et à ses sous-clés avec Regedit. La clé Shell ne doit avoir qu'une valeur, "(Par défaut)", qui est définie sur "Ouvrir". Ceci est un pointeur sur l'action par défaut pour double-cliquer sur le fichier, ce que nous verrons dans les sous-clés.
Développez la clé Shell et vous verrez trois sous-clés. Chacun de ceux-ci représente une action que vous pouvez effectuer et qui est spécifique aux scripts PowerShell.
- 0 - Exécuter avec PowerShell. “Run with PowerShell” est en fait le nom d'une option déjà présente dans le menu contextuel des scripts PowerShell. Le texte est simplement extrait d'un autre emplacement au lieu d'utiliser le nom de la clé comme les autres. Et ce n’est toujours pas l’action de double-clic par défaut.
- Modifier - Ouvrir dans PowerShell ISE. Cela est beaucoup plus logique que le Bloc-notes, mais vous devez toujours cliquer avec le bouton droit sur le fichier.PS1 pour le faire par défaut.
- Ouvrir - Ouvrir dans le Bloc-notes. Notez que ce nom de clé est également la chaîne stockée dans la valeur «(Par défaut)» de la clé Shell. Cela signifie qu'un double-clic sur le fichier le «ouvrira» et cette action est normalement configurée pour utiliser le Bloc-notes.
Si vous souhaitez vous en tenir aux chaînes de commande prédéfinies déjà disponibles, il vous suffit de modifier la valeur «(par défaut)» dans la clé Shell pour qu'elle corresponde au nom de la clé qui correspond à ce que vous souhaitez faire un double-clic. Cela peut facilement être fait à partir de Regedit, ou vous pouvez utiliser les leçons de notre tutoriel sur l'exploration du registre avec PowerShell (plus un petit tweak PSDrive) pour commencer à créer un script réutilisable capable de configurer vos systèmes. Les commandes ci-dessous doivent être exécutées à partir d'une session PowerShell élevée, similaire à l'exécution de CMD en tant qu'administrateur.
Tout d’abord, vous souhaiterez configurer un lecteur PSDrive pour HKEY_CLASSES_ROOT, car celui-ci n’est pas configuré par défaut. La commande pour cela est:
New-PSDrive HKCR Registry HKEY_CLASSES_ROOT
Maintenant, vous pouvez naviguer et éditer les clés et les valeurs de registre dans HKEY_CLASSES_ROOT, comme vous le feriez avec les lecteurs classiques HKCU et HKLM.
Pour configurer un double-clic afin de lancer les scripts PowerShell directement:
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 0
Pour configurer un double-clic afin d'ouvrir des scripts PowerShell dans PowerShell ISE:
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Edit'
Pour restaurer la valeur par défaut (double-cliquez pour ouvrir les scripts PowerShell dans le bloc-notes):
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Open'
C’est la base de la modification de l’action par défaut du double-clic. Nous verrons plus en détail comment personnaliser le traitement des scripts PowerShell lors de leur ouverture dans PowerShell depuis Explorer dans la section suivante. Gardez à l'esprit que la portée empêche les lecteurs PSDrive de persister d'une session à l'autre. Par conséquent, vous souhaiterez probablement inclure la ligne New-PSDrive au début de tout script de configuration que vous construisez à cet effet ou l'ajouter à votre profil PowerShell. Sinon, vous devrez exécuter ce bit manuellement avant d'essayer d'apporter des modifications de cette façon.
Modification du paramètre PowerShell ExecutionPolicy.
ExecutionPolicy de PowerShell constitue une autre couche de protection contre l’exécution de scripts malveillants. Il existe plusieurs options pour cela, et deux manières différentes de le configurer. Du plus sécurisé au moins sécurisé, les options disponibles sont les suivantes:
- Restreint - Aucun script n'est autorisé à s'exécuter. (Paramètre par défaut pour la plupart des systèmes.) Cela empêchera même l’exécution de votre script de profil.
- AllSigned - Tous les scripts doivent être signés numériquement par un éditeur approuvé pour s'exécuter sans que l'utilisateur ne soit invité à le faire. Les scripts signés par les éditeurs définis explicitement comme non approuvés, ou les scripts non signés numériquement, ne seront pas exécutés. PowerShell demandera à l'utilisateur de confirmer si un script est signé par un éditeur non défini comme sécurisé ou non approuvé. Si vous n’avez pas signé numériquement votre script de profil et établi la confiance en cette signature, il ne pourra pas être exécuté. Faites attention aux éditeurs en qui vous avez confiance, car vous pouvez toujours exécuter des scripts malveillants si vous faites confiance au mauvais.
- RemoteSigned - Pour les scripts téléchargés depuis Internet, il s'agit en réalité de la même chose que «AllSigned». Toutefois, les scripts créés localement ou importés de sources autres qu'Internet sont autorisés à s'exécuter sans invite de confirmation. Ici, vous devrez également faire attention aux signatures numériques en lesquelles vous avez confiance, mais encore plus aux scripts non signés que vous choisissez d’exécuter. Il s'agit du niveau de sécurité le plus élevé sous lequel vous pouvez avoir un script de profil de travail sans avoir à le signer numériquement.
- Sans restriction - Tous les scripts sont autorisés à s'exécuter, mais une invite de confirmation sera requise pour les scripts provenant d'Internet. À partir de ce moment, c’est à vous d’éviter d’exécuter des scripts non fiables.
- Bypass - Tout fonctionne sans avertissement. Soyez prudent avec celui-ci.
- Non défini - Aucune stratégie n'est définie dans la portée actuelle. Ceci est utilisé pour permettre le retour aux stratégies définies dans les portées inférieures (plus de détails ci-dessous) ou aux valeurs par défaut du système d'exploitation.
Comme suggéré par la description de Undefined, les stratégies ci-dessus peuvent être définies dans un ou plusieurs domaines. Vous pouvez utiliser Get-ExecutionPolicy, avec le paramètre -List, pour afficher toutes les étendues et leur configuration actuelle.
- MachinePolicy représente une stratégie de groupe en vigueur au niveau de l'ordinateur. Ceci est généralement appliqué uniquement dans un domaine, mais peut également être effectué localement.
- UserPolicy représente une stratégie de groupe en vigueur pour l'utilisateur. Ceci est également généralement utilisé uniquement dans les environnements d'entreprise.
- Le processus est une étendue spécifique à cette instance de PowerShell. Les modifications apportées à la stratégie dans cette étendue n’affecteront pas les autres processus PowerShell en cours d’exécution et seront inefficaces une fois la session terminée. Cela peut être configuré par le paramètre -ExecutionPolicy lors du lancement de PowerShell ou par la syntaxe Set-ExecutionPolicy appropriée dans la session.
- CurrentUser est une étendue configurée dans le registre local et s'applique au compte d'utilisateur utilisé pour lancer PowerShell. Cette étendue peut être modifiée avec Set-ExecutionPolicy.
- LocalMachine est une étendue configurée dans le registre local et s'appliquant à tous les utilisateurs du système. Il s'agit de l'étendue par défaut modifiée si Set-ExecutionPolicy est exécuté sans le paramètre -Scope. S'appliquant à tous les utilisateurs du système, il ne peut être modifié qu'à partir d'une session avec privilèges élevés.
Dans la mesure où cet article traite principalement de la sécurité pour faciliter l’utilisation, nous nous intéressons uniquement aux trois portées les plus basses. Les paramètres MachinePolicy et UserPolicy ne sont vraiment utiles que si vous souhaitez appliquer une stratégie restrictive qui n’est pas simplement contournée. En conservant nos modifications au niveau Process ou inférieur, nous pouvons facilement utiliser le paramètre de stratégie que nous jugeons approprié pour une situation donnée à tout moment.
Pour conserver un certain équilibre entre sécurité et convivialité, la stratégie présentée dans la capture d'écran est probablement la meilleure. La définition de la stratégie LocalMachine sur Restricted empêche généralement l'exécution de scripts par une personne autre que vous. Bien sûr, cela peut être évité par les utilisateurs qui savent ce qu’ils font sans trop d’efforts. Mais cela devrait empêcher les utilisateurs non avertis en technologies de déclencher accidentellement quelque chose de catastrophique dans PowerShell. Le fait que CurrentUser (c'est-à-dire) soit défini sur Non restreint vous permet d'exécuter manuellement les scripts à partir de la ligne de commande comme bon vous semble, mais conserve un rappel de prudence pour les scripts téléchargés depuis Internet. Le paramètre RemoteSigned au niveau Processus doit être défini dans un raccourci vers PowerShell.exe ou (comme nous le ferons ci-dessous) dans les valeurs de registre qui contrôlent le comportement des scripts PowerShell. Cela facilitera la fonctionnalité de double-clic pour exécuter tous les scripts que vous écrivez, tout en mettant en place une barrière plus forte contre l'exécution non intentionnelle de scripts (potentiellement malveillants) à partir de sources externes. Nous souhaitons le faire ici car il est beaucoup plus facile de double-cliquer accidentellement sur un script que de l'appeler manuellement à partir d'une session interactive.
Pour définir les stratégies CurrentUser et LocalMachine comme dans la capture d'écran ci-dessus, exécutez les commandes suivantes à partir d'une session PowerShell avec privilèges élevés:
Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser
Pour appliquer la stratégie RemoteSigned sur les scripts exécutés à partir de l'Explorateur, nous devons modifier une valeur dans l'une des clés de registre que nous avons examinées précédemment. Cela est particulièrement important car, selon votre version de PowerShell ou de Windows, la configuration par défaut peut être de contourner tous les paramètres ExecutionPolicy sauf AllSigned. Pour voir quelle est la configuration actuelle de votre ordinateur, vous pouvez exécuter cette commande (en vous assurant que le HKCR PSDrive est mappé en premier):
Get-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand | Select-Object '(Default)'
Votre configuration par défaut sera probablement l'une des deux chaînes suivantes, ou quelque chose d'assez similaire:
(Vu sur Windows 7 SP1 x64, avec PowerShell 2.0)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-file' '%1'
(Vu sous Windows 8.1 x64, avec PowerShell 4.0)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' 'if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1''
Le premier n’est pas mauvais, car il ne fait qu’exécuter le script dans les paramètres ExecutionPolicy existants. Cela pourrait être amélioré en appliquant des restrictions plus strictes pour une action plus sujette aux accidents, mais cela n’a pas été initialement prévu pour être déclenché par un double-clic de toute façon, et la stratégie par défaut est généralement restreinte après tout. La deuxième option, toutefois, consiste à ignorer complètement la politique d’exécution que vous êtes susceptible d’avoir en place, même restreinte. Dans la mesure où le contournement sera appliqué dans la portée du processus, il ne concerne que les sessions lancées lorsque les scripts sont exécutés à partir de l'explorateur. Toutefois, cela signifie que vous pourriez éventuellement lancer des scripts auxquels vous pourriez vous attendre (et que vous souhaitez) que votre stratégie interdise.
Pour définir ExecutionPolicy au niveau processus pour les scripts lancés à partir d’Explorateur, conformément à la capture d’écran ci-dessus, vous devez modifier la même valeur de registre que celle que nous venons de demander. Vous pouvez le faire manuellement dans Regedit, en le changeant comme suit:
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''
Exécutez les scripts PowerShell en tant qu'administrateur.
Tout comme c’est une mauvaise idée de désactiver entièrement le contrôle de compte utilisateur, il est également déconseillé d’exécuter des scripts ou des programmes avec des privilèges élevés, sauf si vous en avez réellement besoin pour effectuer des opérations nécessitant un accès Administrateur. Il est donc déconseillé de créer une invite UAC dans l'action par défaut des scripts PowerShell. Cependant, nous pouvons ajouter une nouvelle option de menu contextuel pour nous permettre d’exécuter facilement des scripts dans des sessions élevées lorsque cela est nécessaire. Cette méthode est similaire à la méthode utilisée pour ajouter «Ouvrir avec le Bloc-notes» au menu contextuel de tous les fichiers - mais dans ce cas, nous allons uniquement cibler les scripts PowerShell. Nous allons également reprendre certaines techniques utilisées dans l’article précédent, dans lesquelles nous utilisions un fichier de commandes au lieu de piratages de registre pour lancer notre script PowerShell.
Pour faire cela dans Regedit, retournez dans la clé Shell à:
HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell
Là, créez une nouvelle sous-clé. Appelez-le “Exécuter avec PowerShell (Admin)”. En dessous de cela, créez une autre sous-clé appelée «Command».Définissez ensuite la valeur «(Par défaut)» sous Commande à ceci:
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'
New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)' New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''
Portez également une attention particulière aux différences entre la chaîne insérée dans PowerShell et la valeur réelle enregistrée dans le registre. En particulier, nous devons envelopper le tout entre guillemets simples et doubler les guillemets internes internes, afin d’éviter les erreurs d’analyse des commandes.
Vous devez maintenant avoir une nouvelle entrée de menu contextuel pour les scripts PowerShell, intitulée «Exécuter avec PowerShell (Admin)».
La touche finale.
Quelques ajustements supplémentaires à cela peuvent encore rendre la vie un peu plus facile. D'une part, pourquoi ne pas se débarrasser complètement de la fonction Notepad? Copiez simplement la valeur «(par défaut)» à partir de la touche Commande sous Éditer (ci-dessous), au même emplacement sous Ouvrir.
'C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1'
Ou, vous pouvez utiliser ce morceau de PowerShell (avec Admin & HKCR bien sûr):
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellOpenCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1''
Une autre gêne mineure est l’habitude de la console de disparaître une fois le script terminé. Lorsque cela se produit, nous n’avons aucune chance de vérifier le résultat du script à la recherche d’erreurs ou d’autres informations utiles. Ceci peut être résolu en mettant une pause à la fin de chacun de vos scripts, bien sûr. Alternativement, nous pouvons modifier les valeurs «(par défaut)» pour nos touches de commande afin d'inclure le paramètre «-NoExit». Vous trouverez ci-dessous les valeurs modifiées.
(Sans accès administrateur)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'
(Avec accès administrateur)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'
Et bien sûr, nous vous donnerons également les commandes PowerShell. Dernier rappel: Elevation & HKCR!
(Non administrateur)
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''
(Admin)
Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-NoExit -ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''
Prendre pour un tour.
Pour tester cela, nous allons utiliser un script qui peut nous montrer les paramètres ExecutionPolicy en place et indiquer si le script a été lancé avec des autorisations d’administrateur. Le script s'appellera «MyScript.ps1» et sera stocké dans «D: Script Lab» sur notre système exemple. Le code est ci-dessous, pour référence.
if(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {Write-Output 'Running as Administrator!'} else {Write-Output 'Running Limited!'} Get-ExecutionPolicy -List
Utilisation de l'action "Exécuter avec PowerShell":
Add-Content -Path 'D:Script LabMyScript.ps1' -Value '[ZoneTransfer]`nZoneId=3' -Stream 'Zone.Identifier'
Le Zone.Identifier peut être supprimé avec ceci:
Clear-Content -Path 'D:Script LabMyScript.ps1' -Stream 'Zone.Identifier'
Références utiles:
- Exécution de scripts PowerShell à partir d’un fichier de commandes - Blog de programmation de Daniel Schroeder
- Vérification des autorisations d'administrateur dans PowerShell - Salut, scripteur! Blog
