Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Du 22 au 24 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Cybersécurité et PowerShell
  3. Restreindre PowerShell
Extrait - Cybersécurité et PowerShell De l'attaque à la défense du système d'information
Extraits du livre
Cybersécurité et PowerShell De l'attaque à la défense du système d'information
4 avis
Revenir à la page d'achat du livre

Restreindre PowerShell

Introduction

Le chapitre précédent s’intéressait surtout aux fonctions de blocage de PowerShell dites "binaires" (c’est-à-dire autorisé ou non). Il est tout de même possible de nuancer un peu plus la configuration du Shell, afin de permettre des personnalisations des usages propres à chaque organisation.

Pour rappel, "l’exécution de commandes à distance" est le fait de faire exécuter du code à un ordinateur différent de celui sur lequel on se trouve. C’est exactement ce que nous avons fait avec les différents Reverse Shell utilisés au chapitre Malware maison et au chapitre PowerShell Empire. PowerShell embarque au travers de WinRM et WMI cette capacité de travailler à distance. Il est possible de la configurer finement comme nous le verrons par la suite.

Le chapitre terminera avec l’application du mode de langage contraint dans le Lab pour limiter PowerShell, sans en interdire l’usage.

Remote PowerShell

PowerShell n’est pas qu’un Shell local aux machines Windows. Il intègre nativement la capacité d’interagir avec des machines distantes et de faire exécuter à peu près n’importe quelle commande.

Par contre, l’accès distant avec PowerShell s’appuie sur de nombreux protocoles de communication et frameworks présents dans les environnements de Microsoft.

Cette variété de protocoles peut rendre complexe la compréhension du remoting avec PowerShell. Les protocoles disponibles pour agir à distance sur une machine avec PowerShell sont les suivants :

  • WMI : Windows Management Instrumentation avec DCOM et RPC sous le capot. 

  • WinRM : Windows Remote Management qui s’appuie sur WSMan (Web Services-Management).

  • Sur les versions Linux (Core 7), PowerShell supporte même le SSH.

Les accès distants en PowerShell existaient dès la version 2 du langage de Microsoft. Entre 2009 et aujourd’hui, de nombreuses évolutions du langage et du Framework .NET sont passées par là et certains comportements ou fonctionnalités peuvent donc varier en fonction de la version de PowerShell. En revanche, la plupart des commandes récentes s’appuient sur le mécanisme de "sessions" qui va être présenté ci-après.

1. PSSessions, WS-Management et WinRM

a. Sessions

Les PSSessions sont le mécanisme privilégié par PowerShell pour exécuter des commandes à distance. Elles permettent de se connecter ponctuellement ou de manière persistante à un ou plusieurs ordinateurs distants pour y faire exécuter des scripts ou des sessions interactives.

La session "classique" en PowerShell, comme dans de nombreux langages interactifs, est l’environnement en mémoire dans lequel sont chargés vos variables, modules, codes. Les PSSessions de la console PowerShell sont simplement une couche d’abstractions qui permet la gestion de sessions supplémentaires dans votre session courante. Contrairement à une session classique, ces sessions supplémentaires peuvent être associées à un ordinateur distant.

Pour gérer la communication avec la machine distante, les PSSessions s’appuient sur le service...

PowerShell JEA : Just Enough Administration

1. Présentation

Concernant la connexion à distance avec PowerShell, il faut par défaut être administrateur local de la machine sur laquelle on souhaite se connecter pour avoir les permissions nécessaires. Si sur de petits environnements ce paradigme peut être suffisant, dès lors que l’on aborde de grands parcs cela se concrétise souvent par l’utilisation de comptes fortement privilégiés pour l’administration à distance.

Les leçons tirées du chapitre PowerShell Empire nous enseignent que la compromission de ce type de compte est une très mauvaise chose, ces derniers permettant au mieux à un attaquant de se déplacer latéralement, au pire de prendre le contrôle du domaine.

Comme on l’a vu dans la section précédente, l’implémentation technique de la gestion des privilèges d’accès à distance avec PowerShell est complexe, car elle repose sur de nombreux mécanismes (WSman, WinRM, PSSessions, WMI et RPC, ou encore DCOM) qui peuvent tous jouer un rôle. De plus, ces mécanismes ne permettent pas une gestion différenciée des droits de chaque utilisateur. Il ne serait pas possible de donner à Frédéric les privilèges sur l’administration du DNS du domaine, et à Arnaud ceux sur les registres des différentes machines.

Proposé depuis PowerShell 5, JEA est le mécanisme qui adresse ces problèmes. En associant des comptes virtuels temporairement privilégiés avec des droits spécifiques, les utilisateurs autorisés dans JEA peuvent réaliser les actions qui leur sont autorisées avec des comptes standard, y compris si ces actions nécessitent habituellement des privilèges d’administration. JEA fonctionne au travers d’un PowerShell en sandbox configuré en no language mode (que l’on verra à la section suivante) et s’attaque à la question de la sécurisation des actions d’administration à distance avec PowerShell.

2. Stratégie de mise en œuvre

Avant de déployer une stratégie JEA, il est impératif de réaliser une cartographie des utilisations de PowerShell pour...

Constrained Language Mode et AppLocker

1. Language Mode

Avant de parler de mode de langage contraint, il est nécessaire d’évoquer les différents modes de langage que PowerShell propose. En pratique, en fonction du mode sélectionné de certaines fonctions, cmdlet, mots-clés ou techniques seront autorisés ou non. Il existe quatre modes de langage en PowerShell :

  • FullLanguage : il s’agit du mode par défaut dans lequel aucune restriction n’est appliquée.

  • RestrictedLanguage : dans ce mode, la plupart des cmdlets sont autorisées, mais de nombreuses variables ne sont plus accessibles, les scripts blocks comme l’accès aux propriétés des objets est bloqué, et seuls trois opérateurs de comparaison sont accessibles (-eq, -gt, -lt).

  • NoLanguage : il s’agit d’un mode spécifique uniquement utilisable avec l’API de PowerShell, Dans ce mode, seules les fonctions de l’API AddCommand et AddScript sont autorisées, comme dans l’exemple ci-dessous.

$session = [powershell]::Create() 
$session.RunSpace.SessionStateProxy.LanguageMode = 'NoLanguage' 
$session.AddScript('Get-Date').Invoke()

  • ConstrainedLanguage : en mode contraint tout comme le mode restricted, toutes les cmdlets et éléments du langage sont autorisés. En revanche, les types accessibles sont limités, la conversion de type est bloquée et de nombreuses bornes sont imposées au fonctionnement de PowerShell. Seules les fonctions explicitement exportées des scripts ou modules sont accessibles. Les objets COM et les classes sont bloqués, et l’utilisation de points d’arrêt et des Jobs/ScheduledJobs est également interdite. Ce mode n’existe qu’à partir de PowerShell V3.

Le mode de langage appliqué à la session courante peut être vérifié ainsi :

> $ExecutionContext.SessionState.LanguageMode 
FullLanguage

Comme pour l’execution policy, le mode de langage peut être modifié par l’utilisateur :

> [System.Math]::Exp(2) 
7,38905609893065 
> $ExecutionContext.SessionState.LanguageMode = 
"ConstrainedLanguage" 
> [System.Math]::Exp(2) 
Impossible d'appeler la méthode. L'appel...

Conclusion

Dans ce chapitre, nous avons vu comment configurer des sessions à distance en PowerShell avec WinRM ou WMI. Nous avons ensuite vu comment les sécuriser et les restreindre grâce aux mécanismes système de WinRM et DCOM et aux règles de pare-feu associées.

Nous avons continué avec la solution intégrée JEA. Celle-ci permet d’affecter des permissions avec un niveau de granularité au paramètre près pour chaque cmdlet. JEA requiert néanmoins un travail préparatoire assez conséquent avant sa mise en œuvre.

Enfin, le mode de langage contraint a permis d’illustrer qu’il est possible de restreindre efficacement et par défaut l’accès à PowerShell pour les utilisateurs du SI. Sans être invulnérable, le mode de langage contraint est une barrière très pénible à contourner pour un attaquant. Cette barrière devrait être mise en œuvre par défaut pour tous les utilisateurs du SI qui n’ont pas besoin de PowerShell (il est par contre nécessaire de laisser un accès normal à la console PowerShell à vos administrateurs informatiques).

Au fil des ans, PowerShell s’est étoffé de nombreuses fonctions. Les deux derniers chapitres ont abordé les fonctions suivantes :

  • Le blocage pur et simple...