Avec le correctif du 10 mai 2022, Microsoft tente de combler une faille de sécurité dans le Active Directory dans laquelle l'inscription basée sur un certificat (généralement connue sous le nom de PKINIT ou encore de Connexion par carte à puce).
La mise à jour modifie à la fois le comportement Autorité de certification que le comportement d'Active Directory lors du traitement des inscriptions basées sur des certificats.
Arrière-plan
L'ensemble du fonctionnement de l'attaque peut être détaillé auprès du découvreur de la faille de sécurité peut être consulté.
L'ouverture de session basée sur un certificat n'est pas seulement utilisée pour la "connexion par carte à puce" bien connue, mais aussi pour le mappage du certificat client Active Directory du Service d'information Internet (IIS).
Les comptes d'utilisateurs ne sont pas les seuls à pouvoir se connecter au domaine avec un certificat. Cela est également possible pour les comptes d'ordinateurs.
Pour les comptes d'utilisateurs, le userPrincipalName du compte Active Directory correspondant est inscrit dans le certificat émis et est à nouveau lié à l'objet correspondant par Active Directory lors de la connexion.
Pour les comptes d'ordinateur, le fonctionnement est en principe le même, mais ici, le dNSHostName est inscrit dans le certificat et évalué par Active Directory lors de la connexion.
Voir aussi l'article "Sur l'option "Build this from Active Directory information" pour les modèles de certificats„ .
L'attaque repose sur le fait que le propriétaire d'un objet informatique (celui qui a admis la machine dans le domaine - chaque utilisateur a ce droit par défaut) peut définir de manière autonome l'attribut dNSHostName à une valeur quelconque. Les collisions avec d'autres objets (c'est-à-dire si la même valeur est déjà définie sur un autre objet informatique) ne sont pas détectées avec dNSHostName.
Entsprechend ist es möglich, Zertifikate für Identitäten anderer Computer, auch Domänencontroller, zu beantragen, mit denen dann eine Identifikation unter der Identität des gefälschten Computerobjektes möglich ist, was wiederum das Auslesen aller Anmeldedaten der Domäne zur Folge haben kann.
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.
La mise à jour
Les changements sont détaillés dans l'article de la base de connaissances Microsoft KB5014754 décrites.
Nouvelle extension de certificat
La mise à jour introduit une nouvelle extension de certificat appelée szOID_NTDS_CA_SECURITY_EXT avec l'identificateur d'objet (OID) 1.3.6.1.4.1.311.25.2.
Les autorités de certification d'entreprise (CA) commenceront à ajouter une nouvelle extension non critique avec un identifiant d'objet (OID) (1.3.6.1.4.1.311.25.2) par défaut dans tous les certificats émis contre des modèles en ligne après que vous aurez installé la mise à jour Windows du 10 mai 2022.
KB5014754-Changements d'authentification basés sur les certificats sur les contrôleurs de domaine Windows (Microsoft Corporation)
Tous les certificats émis par des modèles de certificats "en ligne", c'est-à-dire ceux dont la part d'identité dans le certificat est formée par l'Active Directory, contiennent cette extension de certificat dès l'installation de la mise à jour sur l'autorité de certification.
L'extension du certificat comprend le objectSid ("Security Identifier") Attribut Active Directory du compte associé. L'enregistrement de l'attribut de certificat est déterminé par l'attribut de certificat par défaut de Windows. Module de politique qui a été mis à jour en conséquence.
Le patch a donc permis d'installer une nouvelle version du module Windows Default Policy afin de refléter les modifications correspondantes lors de l'émission des certificats.
Voir le numéro de version avant le patch...
... et après l'installation du patch.
Modifications apportées à Active Directory
Au lieu de s'attaquer au problème de base (les propriétaires de comptes d'ordinateurs peuvent modifier eux-mêmes leur attribut dNSHostName et aucune contrainte d'uniqueness n'est définie sur celui-ci), Microsoft estime désormais que l'attribut dNSHostName ne doit plus être considéré comme une connexion "forte" au compte Active Directory correspondant.
Soit le lien entre le compte Active Directory et le certificat doit maintenant être établi manuellement via le altSecurityIdentities Un certificat doit présenter la nouvelle extension de certificat avec l'identifiant de sécurité correspondant du compte.
En conséquence, lors du traitement des inscriptions basées sur un certificat selon l'"ancien" schéma, de nouveaux messages d'avertissement (Événement avec ID 39 de la source Microsoft-Windows-Kerberos-Key-Distribution-Center) sont consignées.
The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.
Il est possible, via la clé de registre "StrongCertificateBindingEnforcement" (type DWORD), d'utiliser le nouveau mode de traitement, dans lequel une liaison "forte" (selon Microsoft) est établie.
La clé se trouve à l'endroit suivant :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
La clé peut prendre les valeurs suivantes :
| Valeur | Description |
|---|---|
| 0 | Les inscriptions avec des certificats sans attribut SID seront pas protocolées et autorisées. |
| 1 | Les connexions avec des certificats sans attribut SID sont consignées et autorisées. (paramètre par défaut) |
| 2 | Les connexions avec des certificats sans attribut SID sont consignées et pas admis. |
Si l'on modifie la valeur à "2", les connexions correspondantes sont refusées et consignées en conséquence sur le contrôleur de domaine.
Microsoft prévoit de lancer le "nouveau" mécanisme exactement un an après la sortie de la mise à jour, c'est-à-dire le 19 mai 2023 forcer durement le passage. La logique correspondante est déjà incluse dans le patch. Les clés de registre mentionnées dans l'article ne seront plus utilisables à partir de ce moment-là.
Mise à jour : Microsoft a mis en place le forçage sur le 14 novembre 2023 reporté.
Nouvelle mise à jour : Apparemment, il y a des problèmes plus graves, si bien que Microsoft a de nouveau reporté le forçage, cette fois au 11 février 2025. La phrase secondaire "...ou plus tard" est également passionnante.
Si aucun mapping explicite de certificat à compte n'est souhaité, c'est-à-dire si la nouvelle extension de certificat doit être utilisée, tous les certificats doivent être réémis avant la date limite.
Le nom commun ne suffit apparemment plus non plus...
En outre, Microsoft mentionne dans une phrase secondaire que, depuis le correctif, il est également requis dès maintenant, remplir les attributs de certificat correspondants userPrincipalName ou dNSName avec les valeurs du compte Active Directory correspondantl'utilisation exclusive du commonName ne suffit donc plus.
Cette modification concerne Serveur de politiques de réseau (NPS) ou les serveurs web qui traitent une connexion avec des certificats. La bibliothèque sous-jacente a été configurée avec une nouvelle valeur par défaut grâce au correctif.
Celle-ci se trouve dans la valeur "CertificateMappingMethods" sous la clé de registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
Cette valeur peut être configurée comme suit :
| Bit | Réglage | Méthode | Évaluation de la force |
|---|---|---|---|
| 1 | 0x0001 | Subject/Issuer certificat mapping | faible |
| 2 | 0x0002 | Mappage du certificat d'émetteur | faible |
| 3 | 0x0004 | Cartographie des certificats UPN | faible |
| 4 | 0x0008 | S4U2Self mapping des certificats | fort |
| 5 | 0x0010 | S4U2Self explicit certificate mapping | fort |
L'ancienne valeur par défaut de 0x1F (0001 1111) activait toutes les méthodes mentionnées. La nouvelle valeur par défaut 0x18 (0001 1000) n'active plus que les deux méthodes "fortes".
Il y a eu de la confusion ici, puisque certains blogueurs écriventL'administrateur du certificat a déclaré que l'attribut userPrincpialName devait absolument être rempli et activé en conséquence dans le modèle de certificat. Cela a incité certains administrateurs à l'activer également pour les certificats d'ordinateur, ce qui n'est évidemment pas nécessaire. Ce qui compte, c'est ce qui doit être identifié par le certificat. Pour les certificats d'ordinateur, il doit y avoir un Subject Alternative Name du type "dNSName", pour les certificats d'utilisateur du type "userPrincipalName".
Gérer la nouvelle situation
Les modèles de certificats hors ligne semblent avoir été oubliés
J'ai profité de ce changement pour PSCertificateEnrollment Module PowerShell d'étendre l'extension du certificat de sorte que la nouvelle extension puisse être inscrite dans une demande de certificat "hors ligne.
Import-Module PSCertificateEnrollment New-CertificateRequest -Subject "CN=test" -Sid "lol"
Il s'avère que pour les modèles de certificats hors ligne (c'est-à-dire ceux pour lesquels le demandeur peut déterminer lui-même le contenu de l'identité du certificat), le module Windows Default Policy transmet l'extension du certificat avec n'importe quel contenu au certificat délivré.
Si un attaquant parvient maintenant à obtenir l'accès à un tel modèle de certificat, le lien prétendument "fort" avec un objet Active Directory n'a plus lieu d'être (à condition de miser sur la nouvelle extension de certificat plutôt que sur un mappage explicite pour l'authentification).
En outre, je suis d'avis que l'utilisation d'une extension de certificat propriétaire peut même être dangereuse dans ce cas, car ce type d'identité ne serait pas reconnu comme identité par les solutions courantes et ne serait pas enregistré dans une base de données (si elle existe).
Le site Module de politique de TameMyCerts est désormais en mesure de reconnaître et de refuser la nouvelle extension de certificat dans les demandes de certificat "hors ligne". De même, il est possible d'utiliser la nouvelle extension de certificat dans Certificats pour les exigences de certificat "hors ligne" à saisirLes utilisateurs de téléphones portables doivent être en mesure d'identifier et d'identifier les appareils mobiles, par exemple s'ils ont été fournis par un système de gestion des appareils mobiles (MDM) comme Intune, Workspace ONE ou MobileIron.
Il est également surprenant que le contrôle de l'utilisation de cette extension de certificat pour les demandes de certificats hors ligne ne soit pas possible via l'interface prévue à cet effet. EnableEnrolleeRequestExtensionList Malheureusement, il n'est pas possible d'utiliser la clé de registre, car elle est apparemment codée en dur dans le module Policy et n'apparaît donc pas dans la liste (tout en étant active).
Problèmes d'application du correctif lors de la connexion au serveur de politiques réseau (NPS) ou aux services d'information Internet (IIS).
Assez rapidement après l'installation du correctif, il est apparu que les entreprises qui utilisaient le Network Policy Service (NPS) pour permettre des scénarios d'accès à distance (RAS) ou de contrôle d'accès réseau (NAC), tels que les connexions au réseau câblé ou sans fil avec des certificats, devaient faire face à une panne de ces services précisément.
Le problème se présente de manière comparable sur les serveurs web IIS qui traitent les connexions avec des certificats clients.
Microsoft n'a manifestement pas tenu compte du fait que les inscriptions les plus diverses dans Active Directory se basent sur la même procédure, y compris le NPS. Et le "nouveau" mode d'exploitation y a apparemment déjà été imposé. Aussi le patch ajouté le 19 mai 2022 pour le patch ne résout apparemment pas le problème. Ce n'est que sur la mise à jour hors bande du 27.05.2022 résout le problème apparemment.
Au 05 août 2022, je peux confirmer qu'un contrôleur de domaine avec le niveau de patch de juillet 2022 (StrongCertificateBindingEnforcement configuré avec la valeur 1 ou non défini) et le rôle de serveur de stratégie réseau installé se comporte exactement comme documenté, c'est-à-dire qu'il accepte les connexions RADIUS et les autorise même si l'extension de certificat SID n'est pas présente dans le certificat. L'événement avec ID 39 est consigné comme avertissement.
Actuellement, il n'y a ici que le Solution de contournementLa solution consiste à patcher d'abord l'autorité de certification, puis à réémettre tous les certificats (avec la nouvelle extension de certificat) et enfin à patcher les contrôleurs de domaine - ce qui ne sera pas pratique dans la pratique, car le renouvellement d'un certificat peut prendre plusieurs mois.Il faudra attendre la fin de l'année pour qu'elle soit généralisée.
La désinstallation du patch ne peut pas non plus être la solution, car elle laisse l'utilisateur sans protection contre plusieurs failles de sécurité (même si l'autorité américaine CISA a entre-temps mis en garde contre l'installation des patchs).
Il semblerait que le correctif ne fonctionne pas non plus avec les contrôleurs de domaine prêts à l'emploi (RODC).
Qu'en est-il des scénarios hors ligne voulus ?
En outre, je me demande comment Microsoft envisage de traiter les scénarios qui utilisent volontairement des modèles de certificats hors ligne. Prenons l'exemple d'un système de gestion des appareils mobiles (MDM) (p. ex. le propre Intune/MEM de Microsoft ou VMware AirWatch), tels que les smartphones. Ceux-ci peuvent tout à fait posséder des certificats qui sont utilisés pour une connexion via RAS ou NAC (en général, ces certificats sont émis pour l'identité de l'utilisateur qui utilise l'appareil).
Si le serveur de politique réseau (NPS) est maintenant utilisé dans le backend de l'entreprise, je me demande (si le problème NPS devait être résolu entre-temps par un patch) ce qui pourrait bien se passer à la date du forçage si Microsoft activait comme prévu le forçage de la nouvelle extension de certificat (la "bombe à retardement" est en effet déjà incluse), et ce sans possibilité de désactivation.
Network Policy Server denied access to a user. [...] Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Tous les fabricants de MDM auront-ils fait en sorte, d'ici cette date, que leurs produits demandent la nouvelle extension de certificat et que leurs clients aient renouvelé tous leurs certificats d'ici là ?
Entre-temps, cette hypothèse est partagée par le gouvernement américain, entre autres, sans qu'il y ait de solution :
Note importante : Microsoft prévoit de supprimer le 'mode compatibilité' et de passer tous les périphériques Windows Server en mode 'application complète' en mai 2023. Ce changement cassera l'authentification si les agences n'ont pas créé un mappage fort ou ajouté des SID aux certificats. La CISA et le groupe de travail inter-agences sont en discussion active avec Microsoft pour trouver une meilleure voie à suivre. A l'heure actuelle, la CISA ne recommande pas aux agences de migrer vers une cartographie forte.
GUIDE SUR L'APPLICATION DE LA MISE À JOUR DE JUIN DU MARDI DES PATCHS MICROSOFT POUR CVE-2022-26925 (Agence pour la sécurité de la cybersécurité et des infrastructures)
Ironiquement, Microsoft lui-même écrit ce qui suit à ce sujet :
Les environnements qui ont des déploiements CA non-Microsoft ne seront pas protégés par la nouvelle extension SID après l'installation de la mise à jour Windows du 10 mai 2022. Les clients concernés doivent travailler avec les fournisseurs de CA correspondants pour résoudre ce problème ou envisager d'utiliser d'autres mappages de certificats forts décrits ci-dessus.
En d'autres termes, Microsoft propose que d'autres fabricants d'autorités de certification intègrent cette extension de certificat dans leurs produits sans avoir fourni de solution complète dans leur propre produit.
On peut tout à fait parler ici d'une bombe à retardement.
J'ai commencé à travailler avec Module TameMyCerts Policy pour l'autorité de certification Microsoft a entre-temps créé une solution possible pour ce scénario. Avec le module TameMyCerts Policy, il est possible de relier l'identité demandée par le Mobile Device Management System dans la demande de certificat au compte Active Directory correspondant et d'inscrire son SID dans une demande de certificat correspondante dans le certificat délivré. N'hésitez pas à me contacter si vous souhaitez utiliser ce module et si vous avez besoin d'aide pour le configurer.
Possibilités alternatives pour un lien "fort
Microsoft indique que - dans la mesure où l'on ne peut ou ne veut pas émettre de certificats avec la nouvelle extension de certificat - il est également possible de créer manuellement une liaison "forte" à un certificat via le altSecurityIdentities Attribut pour les objets Active Directory mettre en place peut.
Cette étape doit toutefois être effectuée manuellement ou à l'aide d'un script. Microsoft ne propose pas de solution d'automatisation utilisable. On ne sait pas non plus comment cette liste peut être gérée durablement.
Désactiver l'extension
La désactivation de la nouvelle extension de certificat peut être utile si la connexion basée sur un certificat n'est de toute façon pas prévue dans l'environnement.
Veuillez ne procéder à cette modification qu'avec bon sens et uniquement si vous avez une bonne raison de le faire. La modification est marquée comme "non critique" et ne devrait donc pas avoir de conséquences négatives, par exemple en ce qui concerne la compatibilité des applications.
Au niveau de chaque modèle de certificat, l'extension peut être désactivée à l'aide de la commande suivante :
certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000
Le drapeau s'appelle CT_FLAG_NO_SECURITY_EXTENSION, mais il n'est actuellement pas encore résolu par le système d'exploitation.
Ajout d'un nouvel indicateur d'attribut d'inscription CT_FLAG_NO_SECURITY_EXTENSION à la table d'attributs de l'indicateur d'inscription msPKI, qui, lorsqu'il est appliqué, ordonne à l'AC de ne pas inclure l'extension de sécurité szOID_NTDS_CA_SECURITY_EXT (OID:1.3.6.1.4.1.311.25.2), comme spécifié dans [MS-WCCE] sections 2.2.2.7.7.4 et 3.2.2.6.2.1.4.5.9, dans le certificat délivré. Une note de comportement est ajoutée pour indiquer que cet indicateur d'inscription est pris en charge par les systèmes d'exploitation spécifiés dans [MSFT-CVE-2022-26931], chacune installée avec son article KB correspondant à télécharger.
Les protocoles Windows : Ce qui est nouveau et ce qui a changé (Microsoft Corporation)
Au niveau de l'autorité de certification, l'extension peut également être désactivée. Ainsi, l'autorité de certification configurée en conséquence n'inscrit l'extension dans aucun des certificats publiés. La commande suivante permet d'effectuer ce réglage :
certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2
Ce réglage n'est pas recommandé et est désormais connu sous le nom de ESC16 traitées comme des configurations erronées ayant une incidence sur la sécurité.
Conclusion/évaluation
Le patch semble très précipité :
- Le problème réel, à savoir qu'un compte de compteurs peut définir certains de ses propres attributs comme bon lui semble, n'est apparemment pas adressé.
- La nouvelle extension de certificat n'est pas vérifiée pour les modèles de certificats "hors ligne", il ne peut donc pas vraiment être question d'un lien "fort" avec l'objet Active Directoy. Elle est codée en dur dans le module de politique par défaut de Windows et n'apparaît pas dans les clés de registre prévues à cet effet dans le module de politique pour les demandes de certificats hors ligne, c'est-à-dire que l'on est ici incohérent avec son propre design et que l'on intègre apparemment même un nouveau bug par ce biais. Mais cela correspond effectivement au niveau de maintenance, que le produit peut encore attendre de Microsoft à l'heure actuelleà savoir juste le strict nécessaire à mettre en œuvre avec le moins d'efforts possible.
- Avec l'introduction de la mise à jour, Microsoft a créé une chaîne apparemment sans fin de nouveaux problèmes (y a-t-il éventuellement un problème de contrôle de la qualité) ?
- Apparemment, Microsoft a également oublié qu'il existe un monde dans la PKI en dehors de l'Active Directory, mais n'a pas veillé à ce que tous les certificats concernés puissent disposer de la nouvelle extension de certificat avant la date limite.
En outre, des questions essentielles n'ont toujours pas été abordées. Par exemple Les utilisations de clés étendues des contrôleurs de domaine ne sont toujours pas vérifiées dans le paramètre par défaut.
Je continue donc de recommander (si elle n'est de toute façon pas utilisée) Inscription par carte à puce et les cas similaires, et de supprimer toutes les autorités de certification (où cela est possible sans risque). NTAuthCertificates qui ne doivent pas émettre de certificats pour les mécanismes de connexion correspondants. A mon avis, le Network Policy Service ne devrait plus être utilisé, car il crée, en raison de sa dépendance à l'Active Directory, les problèmes de sécurité les plus divers et, comme on le voit maintenant, également des problèmes de disponibilité.
D'une manière générale, il est très difficile d'introduire un changement d'une telle ampleur sans pouvoir en évaluer les conséquences ou sans au moins se concerter au préalable avec les principaux partenaires. Une période de préparation aussi courte (pour les cycles de vie PKI) d'à peine un an peut déjà être qualifiée de négligence.
Liens complémentaires :
- Les contrôleurs de domaine ne vérifient pas l'utilisation étendue de la clé lors de la connexion par carte à puce.
- De zéro à Enterprise Administrator grâce au service d'enregistrement des périphériques réseau (NDES) - et ce qui peut être fait à ce sujet
- Modifier l'objet NTAuthCertificates dans Active Directory
- Modèles de certificats de contrôleur de domaine et inscription par carte à puce
- L'extension de certificat "S/MIME Capabilities
- L'extension de certificat "Application Policies
- Planification de la validité des certificats et de la période de renouvellement des certificats d'entité finaux avec auto-enrollment
Sources externes
- KB5014754-Changements d'authentification basés sur les certificats sur les contrôleurs de domaine Windows (Microsoft Corporation)
- Les protocoles Windows : Ce qui est nouveau et ce qui a changé (Microsoft Corporation)
- May 2022 - Vous pouvez voir des échecs d'authentification sur le serveur ou le client pour les services (Microsoft Corporation)
- Windows Kerberos Élévation de la vulnérabilité des privilèges (CVE 2022 26931) (Microsoft Corporation)
- HowTo : Mapper un utilisateur à un certificat via toutes les méthodes disponibles dans l'attribut altSecurityIdentities (Microsoft Corporation)
- GUIDE SUR L'APPLICATION DE LA MISE À JOUR DE JUIN DU MARDI DES PATCHS MICROSOFT POUR CVE-2022-26925 (Agence pour la sécurité de la cybersécurité et des infrastructures)
- Certifried : Active Directory Domain Privilege Escalation (CVE-2022-26923) (Oliver Lyak)
- May 19, 2022-KB5015013 (OS Build 20348.709) Hors bande (Microsoft Corporation)
- Le CISA avertit de ne pas installer les mises à jour de May Windows sur les contrôleurs de domaine (Bleepingcomputer)
- NPS a cessé de fonctionner après les mises à jour de mai 2022 (discussion sur Microsoft TechNet)
- AD Authentication Issues 2022-05 May Patches / Mapping Certificates to AD Objects (Robin Beismann)
- Forte application de la cartographie des certificats Février 2025 (Richard Hicks)
Français 
Deutsch 
English
Les commentaires sont fermés.