Mise en danger de la structure globale d'Active Directory par le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2

En réseau circulent malheureusement beaucoup sur beaucoup de Instructions (même les grands acteurs n'en sont pas excluspas même Microsoft lui-même ou le Grand Maître Komar), qui recommandent fatalement que le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 soit activé sur l'autorité de certification - soi-disant pour être en mesure d'émettre des certificats avec l'extension Subject Alternative Name (SAN) pour les demandes de certificats faites manuellement.

Malheureusement, cette procédure n'est pas seulement inutile, elle a aussi quelques effets secondaires désagréables qui peuvent, dans le pire des cas, aider un attaquant à prendre le contrôle de toute la structure globale d'Active Directory.

Voir aussi l'article "Modifications apportées à l'émission de certificats et à l'ouverture de session basée sur des certificats dans Active Directory par le correctif pour Windows Server du 10 mai 2022 (KB5014754)„ .

Contexte

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Le réglage est-il nécessaire pour émettre des certificats avec une extension SAN ?

Un non clair !

Si la demande de certificat contient déjà une extension SAN, celle-ci peut être délivrée par l'autorité de certification même si la demande est faite manuellement. Pour ce faire, l'identificateur d'objet pour l'extension de certificat SAN est déjà configuré par défaut dans le module Policy de l'autorité de certification sous "EnableEnrolleeRequestExtensionList" inscrite.

La raison pour laquelle la plupart des cas décrits sur Internet et dans la littérature spécialisée conseillent d'activer le drapeau est que la demande de certificat (en anglais Certificate Signing Request, CSR) envoyée à l'autorité de certification ne dispose pas d'une extension SAN, mais que celle-ci est souhaitée.

Le véritable problème que les auteurs tentent de résoudre est donc d'ajouter ultérieurement l'extension SAN à la demande de certificat. Ils ne peuvent toutefois pas modifier directement la demande de certificat sans rendre sa signature inutilisable.

En effet, en activant ce drapeau, il est possible, lors de la soumission de la demande de certificat n'importe quel d'attributs, dont l'extension SAN, mais cela a un effet négatif sur la qualité de l'information. prix très élevé.

Quel est l'effet du drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 ?

Si le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 est activé, un demandeur peut transmettre des attributs supplémentaires à l'autorité de certification via une combinaison nom/valeur pendant qu'il envoie la demande de certificat à l'autorité de certification.

Habituellement, l'autorité de certification décide du contenu du certificat délivré sur la base des paramètres définis dans le modèle de certificat. Cette décision est prise par le Module de politique de l'organisme de certification.

Si l'indicateur EDITF_ATTRIBUTESUBJECTALTNAME2 est activé, les paramètres correspondants du modèle de certificat sont cependant ignoresi des informations différentes arrivent avec la demande de certificat.

En clair, cela signifie que toute personne ayant le droit de demander des certificats à l'autorité de certification (autorisation "Enroll"), peut indiquer n'importe quel Subject Alternative NamesLe certificat est ensuite inscrit sans vérification par l'autorité de certification dans le certificat délivré.

Étant donné que de nombreuses applications et protocoles (notamment HTTPS, voir RFC 2818) forment leur identité de préférence par le biais du Subject Alternative Name, cette circonstance permet à un pirate de les utiliser, d'usurper l'identité de n'importe quel autre utilisateur, y compris celle d'un administrateur.

Selon les types de certificats proposés par l'autorité de certification, un attaquant peut s'en servir pour effectuer diverses activités non autorisées, par exemple

  • Falsification de l'identité d'un serveur web (type SAN "nom DNS")
  • Envoi d'e-mails signés au nom d'un autre utilisateur (SAN "Type RFC 822 Name")
  • Reprendre l'ensemble de la structure globale d'Active Directory (type SAN "User Principal Name")

C'est ce dernier cas qui sera décrit plus en détail dans cet article.

L'attaque

Identifier les modèles de certificats intéressants

Pour reprendre la structure globale d'Active Directory, il faut un modèle de certificat qui permette de se connecter via une carte à puce.

Pour cela, les conditions suivantes doivent être remplies :

  • L'environnement doit permettre les inscriptions par carte à puce, ce qui devrait être possible dans la plupart des cas.
  • L'utilisateur doit pouvoir demander un certificat à partir du modèle (avoir l'autorisation Enroll).
  • Le certificat délivré doit contenir soit l'Extended Key Usage pour Smart Card Logon, soit (avec une petite astuce) pour Client Authentication.
  • L'utilisateur doit disposer d'une carte à puce et d'un lecteur de carte à puce. Le middleware de la carte à puce doit être installé sur un ordinateur de domaine. Il est également possible d'utiliser les informations d'identification Kerberos être généré même sans carte à puce.

Les mesures de sécurité suivantes peuvent être contournées :

  • Le paramètre du modèle de certificat qui consiste à former l'identité du demandeur à partir de l'Active Directory peut être remplacé par la présence de EDITF_ATTRIBUTESUBJECTALTNAME2 par le demandeur, au moins pour la partie Subject Alternative Name.
  • Le réglage dans la Le demandeur peut annuler l'obligation de ne pas marquer la clé privée comme exportable dans le modèle de certificat.
  • Le paramétrage du modèle de certificat selon lequel une demande de certificat ne peut être vérifiée que par un gestionnaire de certificats donnera probablement quand même un résultat, car la modification n'est pas effectuée lors du Inspecter la demande de certificat mais uniquement dans la boîte de dialogue View Attributes/Extensions de la console de gestion de l'autorité de certification (certsrv.msc). Un gestionnaire de certificats non averti validera donc très probablement la demande de certificat.

Demander un certificat

L'attaquant pourrait également apporter une demande de certificat entièrement prête, et l'envoyer ensuite à l'autorité de certification uniquement avec l'identité de l'utilisateur. Pour des raisons de simplicité et de traçabilité, la voie décrite ici est celle des moyens embarqués existants.

Tout d'abord, nous avons besoin d'une demande de certificat sous forme de fichier texte. Celui-ci peut être généré via la console de gestion des certificats (certmgr.msc). Pour cela, il faut cliquer à droite sur Personnel Certificats cliqué et Toutes les tâchesOpérations avancéesCréer une demande personnalisée... sélectionnés.

On est invité à indiquer le modèle de certificat.

Dans cet exemple, le modèle de certificat est configuré pour utiliser une carte à puce, de sorte que la paire de clés est générée directement sur la carte à puce.

Si le modèle de certificat exige à la place un fournisseur de services cryptographiques (CSP) ou un fournisseur de stockage de clés (KSP) basé sur un logiciel, il est possible d'utiliser ces fournisseurs de services cryptographiques. la clé privée est définie comme exportable et le certificat qui en résulte est alors être importés sur une carte à puce.

La demande de certificat est maintenant enregistrée sous forme de fichier.

L'étape suivante consiste à envoyer la demande de certificat à l'autorité de certification, en la complétant par l'élément -attribut Un Subject Alternative Name sous la forme du User Principal Name (UPN) du compte Enterprise Administrator prédéfini est indiqué dans le 2e argument.

certreq ^
-submit ^
-config "CA03.intra.adcslabor.de\ADCS Labor Issuing CA 2" ^
-attrib "SAN:upn=Administrator@intra.adcslabor.de" ^
test.req ^
test.cer

Dans la mesure où la demande de certificat est configurée pour qu'un gestionnaire de certificats vérifie la demande, cela n'est pas visible dans la demande de certificat enregistrée, mais uniquement dans la boîte de dialogue "View Attributes/Extensions" dans la console de gestion de l'autorité de certification.

A première vue, le certificat délivré ne semble pas présenter de caractéristiques frappantes, puisque dans ce cas, le sujet du certificat est rempli, comme on peut s'y attendre, avec l'identité du demandeur.

Cependant, si l'on regarde l'extension Subject Alternative Name, on constate que l'UPN du compte Enterprise Administrator prédéfini y est inscrit.

Une fois que le certificat a été récupéré auprès de l'autorité de certification, il peut être installé à l'aide de la commande suivante.

certreq -accept test.cer

Là encore, aucune indication n'est donnée sur l'UPN divergent.

Effectuer l'inscription

L'utilisateur peut maintenant se connecter à un client avec la carte à puce. Une fois que le lecteur de carte à puce et la carte insérée ont été reconnus, une sélection correspondante devrait être disponible.

Dans ce dialogue, on voit les identités divergentes - en haut le Subject, en bas le Subject Alternative Name.

Comme on peut le voir, une connexion devrait maintenant avoir lieu avec le compte Enterprise Administrator prédéfini.

Une vérification montre que nous avons maintenant des droits d'"administrateur d'entreprise".

Quelle est l'astuce pour pouvoir utiliser des certificats avec Client Authentication Extended Key Usage ?

Pour autant que l'utilisateur dispose de droits administratifs sur l'ordinateur auquel il se connecte, il peut appliquer une stratégie de groupe locale qui désactive la restriction au Smart Card Logon EKU pour la boîte de dialogue de connexion Windows.

Le réglage se trouve sous Configuration de l'ordinateurOutils d'administrationComposants WindowsCarte à puce et porte le nom "Allow Certificates with still extended key usage certificate attribute".

Ensuite, les certificats qui ne contiennent pas de Smart Card Logon Extended Key Usage peuvent également être utilisés. De tels modèles de certificats sont nettement plus fréquents, et souvent sans exigence de carte à puce.

Pourquoi les contrôleurs de domaine acceptent-ils les certificats qui ne contiennent pas de Smart Card Logon Extended Key Usage ?

La stratégie de groupe décrite précédemment a pour seul effet de proposer des certificats qui ne contiennent pas de Smart Card Logon Extended Key Usage sur le client sur lequel la connexion par carte à puce est effectuée, afin qu'il puisse les sélectionner pour la connexion.

Inversement, cela signifie que les contrôleurs de domaine ne vérifient pas l'utilisation de la clé étendue du certificat d'inscription. C'est effectivement le cas dans la configuration par défaut, voir à ce sujet l'article "Les contrôleurs de domaine ne vérifient pas l'utilisation étendue de la clé lors de la connexion par carte à puce.„ .

La solution

Le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 doit être activé sur chaque autorité de certification en ligne. ne jamais activert, respectivement être désactivé d'urgence. Dans la mesure du possible, les demandes de certificat devraient toujours être formulées de manière à inclure l'extension SAN. Certes, il n'est parfois pas possible de générer directement une telle demande de certificat, mais il existe également une alternative plus sûre pour de tels cas.

Comment puis-je vérifier si le drapeau est activé ?

La commande de ligne de commande suivante permet d'obtenir une liste de tous les drapeaux de l'autorité de certification. Si EDITF_ATTRIBUTESUBJECTALTNAME2 n'est pas entre parenthèses et n'est pas indenté, le drapeau est actif.

certutil -v -getreg Policy\Editflags

Comment désactiver le drapeau ?

Le drapeau peut être supprimé à l'aide de la commande de ligne de commande suivante :

certutil -v -setreg Policy\Editflags -EDITF_ATTRIBUTESUBJECTALTNAME2

Le service d'autorité de certification doit ensuite être redémarré pour que les modifications prennent effet.

Comment puis-je ajouter l'extension SAN à une demande de certificat ultérieurement, de manière sécurisée ?

L'idéal serait bien sûr que le Demande de certificat soit directement mis en place, y compris un Subject Alternative Name correctement rempli. Cela n'est cependant pas toujours possible.

J'ai expliqué les possibilités d'ajouter un Subject Alternative Name à une demande de certificat existante dans l'article "Modifier le Subject Alternative Name (SAN) d'un certificat avant son émission - mais en toute sécurité !" décrit.

Le site Module de politique de TameMyCerts pour Microsoft Active Directory Certificate Services prend en charge le transfert automatique de tout nom DNS ou adresse IP trouvé dans le commonName d'une demande de certificat vers le Subject Alternative Name des certificats émis, s'il en manque. Le fonctionnement de cette fonction est décrit dans l'article "Ajouter automatiquement des noms DNS dans le Subject Alternate Name (SAN) des certificats émis - avec le module TameMyCerts Policy pour Microsoft Active Directory Certificate Services (ADCS)" décrit.

TameMyCerts est un Module de politiquepour sécuriser l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend les fonctions de l'autorité de certification et permet de l'application élargie de la réglementationIl permet d'automatiser en toute sécurité l'émission de certificats. TameMyCerts est unique dans l'écosystème Microsoft et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais