# Vulnérabilité de sécurité Certifried Certifried est une vulnérabilité de sécurité divulguée en mai 2022 sous [CVE-2022-26921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26921) et [CVE-2022-26923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26923). [Oliver Lyak a décrit une vulnérabilité d’élévation de privilèges](https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4) qu’il avait découverte en utilisant l’authentification par certificat. Il décrit qu’un attaquant pourrait inscrire un certificat lui permettant de s’authentifier en tant que compte d’ordinateur Domain Controller et ainsi prendre le contrôle d’un domaine AD (et d’un tenant AAD, s’il est connecté). Microsoft a traité les vulnérabilités avec [un correctif dans KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap). Cet article décrit l’impact sur les organisations exécutant SCEPman, et comment SCEPman peut aider à atténuer le problème de sécurité. ## Résumé exécutif * Les certificats SCEPman ne peuvent pas être utilisés pour des attaques Certifried dans la plupart des cas * L’utilisation de SCEPman aide à atténuer les attaques Certifried, car contrairement aux certificats Microsoft CA, les certificats SCEPman CA ne doivent généralement pas se trouver dans le magasin NTAuth * Le correctif de Microsoft n’affectera pas les installations SCEPman dans la plupart des cas. Dans ces cas, activer le mode Full Enforcement est une bonne idée. ## Conséquences du correctif de Microsoft Le correctif dans [KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap) ajoute simplement quelques événements d’audit supplémentaires par défaut. Le mode Full Enforcement commence le 11 février 2025 — ou plus tôt s’il est activé manuellement. Avec le mode Full Enforcement, les certificats peuvent être utilisés pour l’authentification des utilisateurs et des appareils uniquement s’ils contiennent soit le SID d’un compte, soit, dans le cas des certificats utilisateur, si l’objet AD de l’utilisateur contient une référence au certificat spécifique. Le premier nécessite une nouvelle extension X.509 propriétaire, le second s’appelle Certificate Mapping et utilise l’attribut altSecurityIdentities. De manière générale, cela n’a d’effet que sur les authentifications AD. Cela nécessite d’ajouter le certificat CA au magasin NTAuth de la forêt. Par défaut, SCEPman n’est pas ajouté au magasin NTAuth si vous ne le faites pas explicitement et manuellement. Si vous ne l’avez pas encore fait et ne prévoyez pas de le faire, le correctif n’a aucun effet sur votre instance SCEPman. Il existe un cas d’utilisation pour lequel la documentation SCEPman recommande d’ajouter le certificat CA SCEPman au magasin NTAuth : lorsque vous souhaitez [permettre à SCEPman de délivrer des certificats Domain Controller pour l’authentification Kerberos](https://docs.scepman.com/fr/gestion-des-certificats/domain-controller-certificates#trust-the-ca-certificate-in-the-domain-for-kerberos-authentication). ### Certificats d’appareil Intune Les certificats d’appareil peuvent être utilisables pour [la confiance par certificat Windows Hello for Business](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust). Si vous avez ajouté le nom DNS AD aux certificats d’appareil pour les utiliser avec la confiance par certificat, vous pourriez être concerné. Cela nécessite un objet d’appareil à la fois dans AAD et AD. Pour ce cas d’utilisation rare, nous recommandons de passer à [WHfB Cloud Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust). ### Certificats utilisateur Intune Les certificats utilisateur peuvent être utilisés pour la confiance par certificat Windows Hello for Business. Ils pourraient aussi être utilisés pour d’autres méthodes d’authentification AD basée sur les certificats, comme des sessions RDP vers des machines jointes au domaine ou l’authentification Wi-Fi basée sur NPS. Si vous souhaitez faire cela, vous pouvez utiliser le paramètre [AppConfig:AddSidExtension](https://docs.scepman.com/fr/configuration-scepman/application-settings/certificates#appconfig-addsidextension) pour permettre à SCEPman de créer des certificats de mappage de certificat fort. Les certificats utilisateur pour les utilisateurs synchronisés entre AD et Entra ID reçoivent automatiquement l’extension avec l’OID 1.3.6.1.4.1.311.25.2 pour les mapper fortement aux utilisateurs AD.\ L’équipe Intune prévoit en outre [d’ajouter une valeur SAN](https://docs.scepman.com/fr/configuration-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates) pour implémenter le mappage de certificat fort. Vous pouvez également utiliser cette méthode comme alternative à l’extension SID. ### Certificats DC Les certificats Domain Controller ne sont pas affectés par la vulnérabilité et ne sont donc généralement pas non plus affectés par le correctif. Il peut arriver que des certificats DC soient utilisés pour l’authentification client, ce qui était autorisé auparavant. Cela ne fonctionnera plus une fois le mode Full Enforcement activé. Recherchez [les événements d’audit](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_auditevents) après l’application du correctif pour déterminer si cela pourrait vous affecter. Dans la plupart des cas, cela ne devrait pas poser de problème. ## Attaques utilisant des certificats SCEPman L’attaque Certifried ne peut être utilisée qu’avec des certificats CA présents dans le magasin NTAuth. Par défaut, ce n’est pas le cas pour le certificat CA SCEPman. Ainsi, si vous utilisez SCEPman pour inscrire des certificats via Intune au lieu de Microsoft Active Directory Certificate Services, il y a de fortes chances que votre environnement soit immunisé contre l’attaque. Toutefois, si votre SCEPman délivre des certificats Domain Controller, votre certificat CA SCEPman se trouve dans le magasin NTAuth et vous devriez continuer à lire. Un attaquant a besoin d’un certificat avec soit un UPN falsifié dans l’extension Subject Alternative Name (SAN) et l’Extended Key Usage (EKU) Smart Card Logon, soit un nom DNS falsifié dans le SAN et l’EKU Client Authentication. ### Certificats utilisateur Intune Supposons qu’un attaquant prenne le contrôle d’un compte utilisateur AAD pour permettre à SCEPman d’inscrire un certificat utilisateur. Comment l’attaquant pourrait-il faire en sorte que SCEPman délivre un certificat utilisable pour l’attaque ? Les certificats utilisateur contiennent généralement l’EKU Client Authentication. Mais si vous suivez les recommandations, ils ne contiennent pas de nom DNS dans le SAN. Par conséquent, ces certificats ne peuvent pas être utilisés. Si vous avez configuré l’EKU Smart Card Logon, le certificat peut être utilisé pour l’authentification, mais uniquement pour le compte correspondant au UPN. Le UPN provient d’AAD et est vérifié, donc l’attaquant ne peut pas faire figurer dans le certificat un UPN d’un compte sur lequel il n’a pas déjà la main. Si vous utilisez également [mappage fort du certificat](https://docs.scepman.com/fr/configuration-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates), vous pouvez vous assurer que les certificats ne fonctionnent pas pour un autre compte si le UPN change. ### Certificats d’appareil Intune En suivant nos recommandations de base, les certificats d’appareil ont l’EKU Client Authentication. Leur SAN contient une entrée URI dans le SAN, qui ne peut pas être utilisée pour l’exploitation. Cependant, vous pouvez également ajouter un nom DNS au SAN, par exemple DeviceName.contoso.com. Si vous avez aussi importé le certificat CA SCEPman dans le magasin NTAuth, ces certificats peuvent être utilisés pour s’authentifier sur site en tant qu’appareil portant le même nom DNS. Comme les utilisateurs peuvent définir le nom de leur appareil comme ils le souhaitent, ils pourraient nommer leur appareil « PrimaryDomainController » et s’authentifier sur site en tant que PrimaryDomainController.contoso.com, même si un tel ordinateur existe déjà dans l’AD. Ce n’est d’ailleurs pas spécifique à SCEPman et cela affecterait également d’autres implémentations SCEP comme NDES. Par conséquent, vous ne devriez pas ajouter d’entrées de nom DNS basées sur des données contrôlées par l’utilisateur, comme le nom de l’appareil, avec des noms de domaine qui sont également utilisés pour les domaines sur site si vous utilisez la même instance SCEPman aussi pour des certificats DC ! Si vous en avez encore besoin, vous devez activer le mode Full Enforcement pour empêcher l’attaque d’élévation de privilèges. Vous pouvez aussi exécuter deux instances SCEPman séparées, l’une pour les certificats DC et l’autre pour l’inscription Intune. ### Certificats utilisateur et appareil Jamf Pro Les certificats délivrés via Jamf Pro auront l’EKU Client Authentication. Si vous suivez notre documentation, aucun type de certificat n’aura de nom DNS dans le SAN. Par conséquent, ces certificats sont inutilisables pour une attaque Certifried. Si le certificat CA SCEPman se trouve dans le NTAuthStore de votre AD, par exemple parce que vous délivrez des certificats DC, vous ne devriez pas ajouter de noms DNS au SAN ou vous assurer d’activer le mode Full Enforcement dans votre domaine AD. ### Certificats Certificate Master Il existe trois façons d’émettre des certificats via le composant Certificate Master à partir de la version 2.1 de SCEPman. [**Certificats de serveur TLS**](https://docs.scepman.com/fr/gestion-des-certificats/certificate-master/tls-server-certificate-pkcs-12) ne sont pas affectés, car ils ne contiennent ni Smart Card Logon ni Client Authentication comme EKU. [**Certificats client manuels**](https://docs.scepman.com/fr/gestion-des-certificats/certificate-master/client-certificate-pkcs-12) ne sont pas non plus affectés. Ils contiennent l’EKU Client Authentication, mais aucune entrée DNS SAN. [**Demandes CSR personnalisées**](https://docs.scepman.com/fr/gestion-des-certificats/certificate-master/certificate-signing-request-csr) sont librement configurables et incluent des certificats d’authentification. Comme toute personne ayant accès à l’application Certificate Master peut émettre un tel certificat, vous devriez prendre au moins une des précautions suivantes : * Assurez-vous que seuls les comptes privilégiés peuvent accéder à Certificate Master. Vous pourriez, par exemple, [accorder l’accès au composant Certificate Master](https://docs.scepman.com/fr/deploiement-scepman/permissions/post-installation-config#granting-the-rights-to-request-certificates-via-the-certificate-master-website) uniquement à un seul groupe AAD que vous définissez comme [groupe d’accès privilégié](https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-features). * Utiliser des instances SCEPman et des certificats CA séparés pour les certificats DC (dont le certificat CA se trouve dans le magasin NTAuth) et Certificate Master. * Activer le mode Full Enforcement dans votre domaine AD. ### les certificats Domain Controller Si un attaquant dispose des droits d’accès nécessaires pour émettre des certificats Domain Controller, cet attaquant a probablement déjà le contrôle d’un Domain Controller et possède déjà le domaine. L’attaquant n’a pas besoin de l’attaque Certifried.