Tim Beasley Consultant senior en gestion des incidents

Dans cette série d'articles, nous avons examiné comment les droits d'accès accordés à des groupes tels que « Backup Operators » et « Account Operators » peuvent être exploités. Dans cet article, nous allons voir comment la relation de confiance influe sur les risques liés aux groupes Active Directory.

Opérateurs cryptographiques font partie de ces groupes que la plupart des défenseurs ignorent complètement ou classent mentalement dans la catégorie « probablement sans importance ». C'est une grave erreur.

À première vue, les opérateurs cryptographiques n'ont rien d'effrayant. Microsoft les décrit simplement ainsi : les membres sont autorisés à effectuer des opérations cryptographiques.

  • Il s'agit d'un groupe local intégré au conteneur « Builtin ».
  • Elle ne comporte aucun membre par défaut.
  • Aucun droit d'utilisateur n'y est attribué par défaut dès son installation.

C'est justement à cause de cette description banale qu'on passe à côté.

Le problème n'est pas que le groupe « Cryptographic Operators » ressemble au groupe « Domain Admins ». Ce n'est pas le cas. Le problème, c'est qu'il se trouve dangereusement proche des systèmes qui définissent la confiance.

Et sous Windows, la confiance est primordiale.


Qu'est-ce que le groupe « Opérateurs cryptographiques » ?

Microsoft a introduit le groupe intégré « Cryptographic Operators » afin de représenter le rôle de « Crypto Officer » et de contrôler certaines tâches de configuration cryptographique dans les environnements Windows utilisant l'API de cryptographie : Next Generation (CNG). Dans les scénarios liés aux Critères communs ou à la norme FIPS, les membres du groupe « Cryptographic Operators » peuvent configurer des paramètres cryptographiques auxquels les utilisateurs ordinaires n'ont pas accès, notamment certains paramètres cryptographiques IPsec spécifiques.

Cela a son importance, car le modèle de fournisseurs qui sous-tend la cryptographie de Windows n’est pas qu’une simple question théorique. Les fournisseurs cryptographiques de Microsoft mettent en œuvre des algorithmes, génèrent des clés, assurent leur stockage et authentifient les utilisateurs ; or, tant les services de certificats Active Directory (AD CS) que l’enregistrement des certificats s’appuient sur CryptoAPI et CNG.

En d’autres termes, il ne s’agit pas « simplement d’un énième groupe intégré un peu bizarre ».

Il est associé aux mécanismes qui permettent de déterminer comment les clés sont générées, où elles sont stockées et comment fonctionnent les processus d'authentification, de signature et de chiffrement.

Et si cette faille est exploitée, vous risquez de voir le jeu se terminer.


Pourquoi ce groupe AD devient dangereux plus vite qu'on ne le pense

Beaucoup de gens, lorsqu'ils entendent parler d'« opérations cryptographiques », pensent qu'il s'agit d'une tâche en arrière-plan, bien délimitée et inoffensive.

Ce n'est pas le bon modèle mental.

Si votre environnement utilise AD CS, des cartes à puce, IPsec, des modules de sécurité matériels ou des fournisseurs de stockage de clés logicielles et matérielles, vous évoluez déjà dans un contexte où la configuration cryptographique est directement liée aux décisions en matière d'identité, d'authentification et de confiance.

Semperis considère déjà les « Cryptographic Operators » comme un groupe de niveau 0 bien connu, présent dans plusieurs environnements clients réels, et non comme une curiosité obsolète sans grande importance.

Cela devrait faire comprendre une chose importante aux défenseurs : même si la description par défaut semble inoffensive, son rayon d'action ne l'est pas.


Des inquiétudes légitimes concernant la défense après ce compromis

Le danger lié aux opérateurs cryptographiques est davantage lié au contexte que celui lié, par exemple, aux opérateurs de sauvegarde.

Les opérateurs de sauvegarde le crient haut et fort.
Les opérateurs cryptographiques le murmurent .

C'est encore pire.


1. Altération de la politique relative aux cryptomonnaies dans les environnements où celles-ci sont effectivement utilisées

La documentation et les recommandations historiques de Microsoft associent ce groupe à la configuration CNG et aux paramètres cryptographiques IPsec en mode « Common Criteria », notamment la possibilité de définir ou de modifier certains paramètres cryptographiques du mode principal que les utilisateurs standard ne peuvent pas modifier.

Si un attaquant parvient à prendre le contrôle d'une identité dotée de ce type de responsabilité dans un environnement sécurisé, vous devez partir du principe qu'il opère désormais au niveau de la politique de confiance (ou « niveau 0 »), et non plus uniquement au niveau d'un terminal.

C'est là que les changements subtils deviennent des changements stratégiques.


2. Proximité avec l'infrastructure PKI et les processus de gestion des clés

Les fournisseurs de stockage de clés (KSP) sont chargés du stockage et de la récupération des clés cryptographiques. Lors de l’installation d’AD CS, les administrateurs choisissent explicitement un fournisseur pour gérer la clé privée de l’autorité de certification. (…ou bien ils se contentent de cliquer sur « Suivant » tout au long de l’installation…)

Par ailleurs, le modèle de fournisseur de services de cryptographie de Microsoft sert de base à l'enregistrement des certificats et, plus largement, aux opérations AD CS.

Ainsi, même si l'appartenance au groupe « Cryptographic Operators » ne garantit pas automatiquement un accès immédiat à toutes les clés privées, elle implique clairement que vous devez examiner de près tout environnement dans lequel ce groupe est présent, car ce rôle est étroitement lié aux systèmes qui gèrent les ancres de confiance et les clés de signature.

Ce n'est pas un domaine où se contenter d'un « ça ira sûrement » constitue une décision acceptable en matière de sécurité.


3. Persistance cachée et faible visibilité

Microsoft précise que le groupe « Cryptographic Operators » ne comporte aucun membre par défaut et n'est pas protégé par AdminSDHolder, tout en indiquant que la gestion de ce groupe ne doit pas être déléguée à des administrateurs n'appartenant pas au service.

Cette combinaison devrait vous mettre mal à l'aise.

Cela signifie qu’il ne s’agit pas d’un des groupes protégés évidents sur lesquels les défenseurs se focalisent, mais qu’il est tout de même considéré comme suffisamment sensible pour que Microsoft précise explicitement : « Ne confiez pas sa gestion à des administrateurs de faible niveau de confiance. »

C'est donc un angle mort idéal.


4. Les surfaces opérationnelles liées aux clés privées sont rarement inspectées de manière approfondie par les responsables de la sécurité

Pour les fournisseurs utilisant des solutions logicielles, Windows stocke généralement les clés privées au niveau de la machine sous des chemins d'accès tels que C:\ProgramData\Microsoft\Crypto\Keys pour les KSP au GNC et C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys pour les CSP CryptoAPI.

Je ne dis pas que le simple fait d'être membre de « Cryptographic Operators » donne automatiquement accès à tous ces fichiers.

Ce que je veux dire , c'est que si vous gérez des comptes chargés de gérer la configuration des cryptos, les fournisseurs, les services de certificats et les flux de travail liés aux clés, ce sont précisément ces points que les responsables de la sécurité doivent examiner pour détecter les erreurs dans les listes de contrôle d'accès (ACL), l'utilisation abusive des fournisseurs et les dérives opérationnelles.


Ce que les défenseurs doivent surveiller

Commençons par une question toute simple : pourquoi certains font-ils partie de ce groupe ?

Selon Microsoft, l'interface « Cryptographic Operators » ne comporte aucun élément par défaut. Par conséquent, si elle contient des éléments, cela devrait donner lieu à un examen immédiat.

À partir de là, soyez attentifs aux éléments suivants :

  • Ajouts et suppressions de membres. Le groupe « Cryptographic Operators » doit en principe rester vide ; toute modification a donc une incidence opérationnelle.
  • Modifications apportées à IPsec ou à la politique de cryptographie dans des environnements utilisant des contrôles liés aux Critères communs ou à la norme FIPS, en particulier lorsque ces modifications sont effectuées par des entités qui ne font pas partie d'un processus de gestion de la cryptographie strictement contrôlé.
  • L'activité sur les serveurs CA, les serveurs d'inscription, l'infrastructure de cartes à puce et les systèmes utilisant des modules HSM ou des intégrations logicielles KSP/CSP ; ces flux de travail s'appuient sur la même pile de fournisseurs que celle que ce groupe a été créé pour aider à gérer.
  • Vérification des ACL et des droits d'accès aux emplacements de clés gérés par logiciel, tels que MachineKeys et Crypto\Keys, car les responsables de la sécurité surveillent souvent la délivrance des certificats mais négligent la couche sous-jacente de stockage des clés.

Comment gérer les risques liés aux opérateurs cryptographiques ?

Les recommandations que je privilégie sont les mêmes que celles que j'ai formulées pour d'autres groupes AD :

Veillez à ce que le groupe reste vide. Et surveillez toute modification concernant les membres du groupe.

Si Microsoft indique que ce groupe ne comporte aucun membre par défaut et que votre propre logique de niveau 0 le classe déjà comme sensible, il faudrait que les critères soient extrêmement stricts avant que quiconque n'y soit affecté.

Si vous pensez en avoir besoin, prouvez-le.
Plus précisément :

  • Décrivez précisément le processus qui nécessite l'adhésion.
  • Identifiez précisément les serveurs, les fournisseurs, les intégrations HSM, les services de cartes à puce ou les politiques IPsec concernés.
  • Considérez ce compte comme un compte de niveau 0 ou proche du niveau 0.
  • Limiter les endroits où il peut se connecter.
  • Vérifiez la configuration de l'autorité de certification (CA) et celle des prestataires associés.
  • Surveillez ce groupe comme vous le feriez pour toute autre interface d'administration déterminante pour la confiance.

Si ce compte est habilité à gérer les systèmes qui définissent la confiance cryptographique, cela signifie, par définition, qu’il opère dans une partie de l’environnement où une seule erreur peut devenir un problème pour tout le monde.


Mettez en avant vos identités « trust-plane »

Les opérateurs cryptographiques sont dangereux précisément parce qu’ils n’en ont pas l’air .

  • Sa description par défaut est brève.
  • Sa liste de membres est souvent vide.
  • Son nom ne suscite pas la même méfiance que les groupes « Admins » ou « Opérateurs », qui disposent de droits plus étendus.

Mais Microsoft l'associe à l'autorité de configuration cryptographique, au modèle de fournisseur Windows qui sous-tend les clés et les certificats, ainsi qu'à des scénarios spécifiques IPsec et CNG à haut niveau de confiance.

Et les résultats des analyses de Semperis le considèrent déjà comme un groupe de niveau 0 connu dans des environnements réels.

Cela signifie que les défenseurs chevronnés devraient cesser de considérer les opérateurs cryptographiques comme un simple bruit de fond inoffensif.

Si une identité peut influencer le plan de confiance cryptographique, il ne s'agit pas d'une identité à privilèges limités. Il s'agit d'une identité du plan de confiance.

Et les identités du « trust-plane » méritent une réflexion de niveau 0.

À la prochaine…Suivez la discussion sur les opérateurs cryptographiques sur LinkedIn.

Et pour bénéficier de l'aide d'experts afin d'identifier et de combler les lacunes de vos groupes de sécurité AD, n'hésitez pas à demander une évaluation de la sécurité Active Directory. Nous sommes là pour vous aider.


Ressources connexes