Editions ENI Livres | Vidéos | e-Formations
Sécuriser PowerShell
Introduction
Les trois chapitres précédents ont présenté de nombreuses manières d’utiliser PowerShell pour s’introduire dans un système d’information, de la reconnaissance avec le scan réseau à l’exfiltration des données de la base de comptes Active Directory, en passant par les élévations de privilèges. Nous y avons même développé un petit ransomware, qui a permis d’introduire les principales notions de base de la cryptographie moderne.
Le constat à la sortie de cette première moitié de l’ouvrage peut paraître inquiétant. En résumé, un attaquant avec un simple accès à une console PowerShell dans un système d’information, avec une configuration standard à l’exclusion de la désactivation de l’antivirus, peut se promener et s’élever assez facilement jusqu’aux privilèges d’administrateur du domaine. L’antivirus apporterait certes une protection supplémentaire non négligeable, mais seulement sur une partie des menaces. L’évasion antivirale étant devenue un véritable sport olympique dans les milieux offensifs, s’appuyer sur cette seule protection est au mieux inconscient, pour ne pas dire suicidaire.
Malgré cette réalité...
Supprimer PowerShell
1. Désinstaller, désactiver ou bloquer ?
Une stratégie classique pour améliorer la protection d’un système d’information est de diminuer la surface d’attaque. Ainsi, un pare-feu n’autorisera en entrée que les ports et protocoles nécessaires par exemple. Dans cette optique, la première question que tout administrateur devrait se poser est donc la suivante : est-ce que tous mes postes informatiques ont réellement besoin d’avoir PowerShell ?
Il ne faut pas oublier que PowerShell est un framework, avec un langage de programmation accessible via un Shell en ligne de commande. C’est très éloigné des fonctions utilisées par 80 à 99 % des utilisateurs. En réalité, la majeure partie d’entre eux peuvent très bien s’en passer.
Malgré tout, PowerShell fait maintenant partie intégrante du système d’exploitation Windows, et il n’est donc pas possible de le désinstaller purement et simplement. On peut cependant se servir des stratégies de groupe Windows pour le bloquer.
2. Bloquer PowerShell par GPO
Les stratégies de groupe, ou GPO pour Group Policy en anglais, sont un mécanisme très pratique et largement utilisé au sein des infrastructures Microsoft. Ces stratégies permettent de régler finement...
Execution policy
1. Présentation
La stratégie d’exécution en français, plus souvent appelée execution policy dans la pratique, est une configuration de sûreté qui vise à contrôler l’exécution des scripts PowerShell sur un système. Cette fonctionnalité ne contrôle que l’exécution des scripts, c’est-à-dire des fichiers, mais pas des commandes en direct dans un Shell.
Il est intéressant ici de différencier la sûreté et la sécurité. Même si les deux domaines se recoupent parfois, il s’agit bien de notions distinctes.
D’un côté, la sécurité est la capacité d’un système (organisation, personnes, bâtiment, système d’information, etc.) à résister à des menaces, souvent supposées externes. En particulier, la sécurité vise à s’assurer que ces menaces ne pourront pas endommager le système et faire des actions non souhaitées. Il s’agit donc de se prémunir pour empêcher un risque de se réaliser, ou d’en minimiser les conséquences.
La sûreté, de l’autre côté, s’intéresse plutôt à la capacité du système à fonctionner malgré la réalisation d’un événement redouté. Il s’agit donc des précautions prises en prévision de la réalisation d’un risque pour s’assurer que le système continuera de fonctionner de manière nominale malgré le problème. Elle traite par exemple de la résilience d’un système face à des erreurs humaines.
Malgré beaucoup de confusion sur cette fonction, l’aide de PowerShell (ci-dessous) est très claire sur le sujet. L’execution policy n’est pas une fonction de sécurité et il est plutôt facile de la contourner, comme le montrera la suite.
get-help about_Execution_Policies "PowerShell’s execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts […]
The execution policy isn’t a security system that restricts user actions […]...
Code signing
1. Présentation
La signature de code est une technique qui consiste à utiliser la cryptographie asymétrique pour permettre de détecter des modifications dans celui-ci, et vérifier les informations de la personne émettrice du code. C’est une manière de s’appuyer sur les infrastructures de gestion de clés déjà évoquées au chapitre Les attaquants et PowerShell, pour apporter de la confiance dans le programme à exécuter. Cela revient également à transférer cette confiance à la robustesse des PKI (Public Key Infrastructure) qui émettent les bi-clés et certificats qui signeront les programmes.
Le mécanisme de signature numérique peut être schématisé comme ci-dessous. Il s’appuie sur les concepts présentés au chapitre Les attaquants et PowerShell pour le chiffrement asymétrique. En revanche en signature l’usage des clés est inversé : on "chiffre" avec sa clé privée pour permettre à tout le monde de déchiffrer le message avec la clé publique associée (c’est-à-dire vérifier que l’émetteur détient bien la clé privée).
Même si elle est plus traditionnellement utilisée avec les programmes compilés, la signature de code existe également pour les scripts PowerShell, bien que le mécanisme de contrôle s’appuie sur la fameuse execution policy… Son utilité reste limitée dans une optique de sécurité, mais cela reste une bonne habitude. De plus, on retrouve ce mécanisme de manière beaucoup plus utile sur la majorité des exécutables compilés. Enfin, la plupart des antivirus modernes contrôlent désormais que ce qui est exécuté sur un système est bien signé avant d’en autoriser le lancement.
La capture d’écran ci-dessous vous montre en exemple les informations de signature du binaire de Visual Studio Code.
Toutes ces raisons poussent à ce qu’on s’intéresse à la signature de code, ce qui offre en plus l’occasion de mettre en place une micro-PKI d’entreprise et de se former à la gestion...
AMSI
1. Présentation
AMSI (Antimalware Scan Interface) est une plateforme d’échange qui permet à des applications de communiquer avec un antivirus compatible sur la machine. Elle permet aux applications de dialoguer directement avec l’antivirus, et en conséquence permet aux antivirus de mieux contrôler ce qui se passe sur la machine.
Contrairement à l’execution policy, AMSI a été conçu comme un mécanisme de sécurité. Introduit à partir de Windows 10 (2015), AMSI est principalement utilisé sous forme d’API (Access Programming interface) par les développeurs d’applications pour dialoguer avec l’antivirus du poste ; mais également par les éditeurs d’antivirus pour supporter au mieux les fonctionnalités offertes par ce mécanisme.
Pour revenir à PowerShell, la difficulté à sécuriser un Shell est qu’un utilisateur peut saisir à peu près ce qu’il veut comme commande. Il est donc impossible d’utiliser un modèle de signature sur fichier statique classique. L’analyse comportementale (par exemple repérer que le script télécharge du code, puis l’exécute avant de tenter d’élever ses privilèges) est également difficile au vu des durées des sessions de scripting et de la complexité possible des saisies. AMSI essaye de répondre à ces problématiques. Il permet à une application (PowerShell ou un autre programme) de soumettre un contenu (fichier, texte, bloc mémoire, URL, IP, etc.) à l’antivirus au travers d’une API. Le schéma suivant illustre son implémentation dans le système d’exploitation Windows.
Certaines applications natives sur Windows intègrent AMSI dans leur fonctionnement :
-
L’UAC (User Account Control), qui gère les élévations de privilèges des programmes.
-
Windows Script Host (wscript.exe et cscript.exe), qui est l’interpréteur VBScript, qu’on peut considérer comme l’ancêtre de PowerShell… même si on trouve encore de nombreux scripts .vbs dans les parcs informatiques actuels.
-
jScript et JavaScript, présents sur les moteurs Microsoft (Edge...
Conclusion
Dans ce chapitre, nous avons pu voir quelques mécanismes de protection existants et natifs avec PowerShell. Il faut garder à l’esprit que si le blocage pur et simple de PowerShell n’est pas une solution utilisable partout, cela reste une option viable pour certains périmètres d’un parc informatique (par exemple des périmètres très exposés ou très sensibles).
L’execution policy vue ensuite n’est pas un mécanisme de sécurité à proprement parler. Elle reste cependant intéressante à mettre en œuvre pour améliorer la conformité du parc, limiter les erreurs d’administration et gêner les attaquants en les forçant à contourner ce mécanisme supplémentaire. L’execution policy a aussi permis d’aborder le sujet de la signature numérique des scripts PowerShell, plus particulièrement sous le prisme de la gestion des certificats en entreprise avec les PKI. Ce sujet est souvent mal compris et parfois implémenté approximativement en entreprise. Il nous semblait donc intéressant de le dédramatiser ici.
La dernière partie du chapitre portait sur l’Antimalware Scan Interface de Windows qui protège PowerShell. Celle-ci, malgré quelques limitations et une adhésion partielle des antivirus du marché...
