Vulnérabilité de sécurité Certifried

Certifried est une vulnérabilité de sécurité divulguée en mai 2022 sous le nom CVE-2022-26921 et CVE-2022-26923. Oliver Lyak a décrit une vulnérabilité d'élévation de privilèges qu'il avait découverte en utilisant l'authentification par certificat. Il décrit qu'un attaquant pourrait enregistrer un certificat qui lui permettrait de s'authentifier en tant que compte d'ordinateur de contrôleur de domaine et ainsi prendre le contrôle d'un domaine AD (et d'un locataire AAD, si connecté). Microsoft a traité les vulnérabilités avec un correctif dans KB5014754. Cet article décrit comment cela affecte les organisations utilisant 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 CA Microsoft, les certificats CA SCEPman n'ont généralement pas besoin d'être dans le magasin NTAuth

• Le correctif de Microsoft n'affectera pas la plupart des installations SCEPman. Dans ces cas, activer le mode d'application complète est une bonne idée.

Conséquences du correctif de Microsoft

Le correctif dans KB5014754 ajoute simplement certains événements d'audit supplémentaires par défaut. Le mode d'application complète démarre le 11 février 2025 — ou plus tôt si activé manuellement. Avec le mode d'application complète, les certificats peuvent être utilisés pour l'authentification des utilisateurs et des appareils uniquement s'ils contiennent soit l'identifiant 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 le mappage de certificat et utilise l'attribut altSecurityIdentities.

De manière générale, cela n'affecte que 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 à moins que vous ne le fassiez 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 où la documentation SCEPman recommande d'ajouter le certificat CA SCEPman au magasin NTAuth, c'est lorsque vous souhaitez laisser SCEPman émettre des certificats de contrôleur de domaine pour l'authentification Kerberos.

Certificats d'appareil Intune

Les certificats d'appareil pourraient être utilisables pour Confiance de certificat Windows Hello for Business. Si vous avez ajouté le nom DNS AD aux certificats d'appareil pour les utiliser pour la confiance de certificat, vous pourriez être affecté. Cela nécessite un objet appareil à la fois dans AAD et AD. Pour ce cas d'utilisation rare, nous recommandons de passer à WHfB Cloud Trust.

Certificats utilisateur Intune

Les certificats utilisateur peuvent être utilisés pour la confiance de certificat Windows Hello for Business. Ils pourraient également être utilisés pour d'autres formes d'authentification AD basée sur les certificats comme les sessions RDP vers des machines jointes au domaine ou l'authentification WiFi basée sur NPS. Si vous souhaitez faire cela, vous pouvez utiliser le paramètre AppConfig:AddSidExtension pour permettre à SCEPman de créer des certificats de mappage fort de certificats. 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 pour implémenter le mappage fort de certificats. Vous pouvez également utiliser cette méthode comme alternative à l'extension SID.

Certificats DC

Les certificats de contrôleur de domaine 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, pour laquelle ils étaient auparavant autorisés. Cela ne fonctionnera plus une fois que l'application complète sera activée. Recherchez événements d'audit 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 du certificat CA SCEPman. Ainsi, si vous utilisez SCEPman pour enregistrer des certificats via Intune plutôt que Microsoft Active Directory Certificate Services, il y a de fortes chances que votre environnement soit immunisé contre l'attaque. Cependant, si votre SCEPman émet des certificats de contrôleur de domaine, votre certificat CA SCEPman est dans le magasin NTAuth et vous devriez continuer la lecture.

Un attaquant a besoin d'un certificat contenant 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 faire enregistrer par SCEPman un certificat utilisateur. Comment l'attaquant pourrait-il faire émettre par SCEPman 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 indiqué dans l'UPN. L'UPN provient d'AAD et est vérifié, donc l'attaquant ne peut pas faire inscrire dans le certificat un UPN d'un compte dont il n'a pas déjà la maîtrise. Si vous utilisez également mappage de certificat fort, vous pouvez vous assurer que les certificats ne fonctionnent pas pour un compte différent si l'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'exploit. Cependant, vous pouvez ajouter un nom DNS au SAN en plus, par exemple DeviceName.contoso.com. Si vous avez également importé le certificat CA SCEPman dans le magasin NTAuth, ces certificats peuvent être utilisés pour s'authentifier sur site en tant qu'appareil avec le même nom DNS. Parce que 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 pas spécifique à SCEPman, d'ailleurs, 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 également utilisés pour des domaines sur site si vous utilisez la même instance SCEPman également pour les certificats DC ! Si vous avez toujours besoin de cela, vous devez activer le mode d'application complète pour empêcher l'attaque d'élévation. Vous pouvez aussi exécuter deux instances SCEPman séparées, une pour les certificats DC, et une pour l'enregistrement Intune.

Certificats utilisateur et appareil Jamf Pro

Les certificats émis 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 vous avez le CA SCEPman dans le NTAuthStore de votre AD, par exemple parce que vous émettez des certificats DC, vous ne devriez pas ajouter de noms DNS au SAN ou vous assurer d'activer le mode d'application complète dans votre domaine AD.

Certificats du 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 TLS serveur sont non affectés, car ils ne contiennent ni Smart Card Logon ni Client Authentication comme EKU.

Certificats clients manuels sont également non affectés. Ils contiennent l'EKU Client Authentication, mais aucune entrée DNS dans le SAN.

Requêtes CSR personnalisées 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 des comptes privilégiés peuvent accéder à Certificate Master. Vous pourriez, par exemple, accorder l'accès au composant Certificate Master uniquement à un seul groupe AAD que vous désignez comme groupe d'accès privilégié.

• Utilisez des instances SCEPman et des certificats CA séparés pour les certificats DC (dont le certificat CA est dans le magasin NTAuth) et pour Certificate Master.

• Activez le mode d'application complète dans votre domaine AD.

certificats de contrôleur de domaine

Si un attaquant dispose des droits d'accès requis pour émettre des certificats de contrôleur de domaine, cet attaquant contrôle probablement déjà un contrôleur de domaine et possède déjà le domaine. L'attaquant n'a pas besoin de l'attaque Certifried.