Les contrôleurs de domaine ne vérifient pas l'utilisation étendue de la clé lors de la connexion par carte à puce.

Auteur Uwe GradeneggerPublié le Catégories Active Directory, Test d'intrusion, Sécurité, Carte à puce, Utilisation du certificatÉtiquettes , , ,

Quiconque souhaite utiliser la fonction Smartcard Logon dans l'entreprise a tout intérêt à veiller à ce que la sécurité de son autorité de certification soit aussi renforcée que possible. Cela implique quelques mesures essentielles :

  • Suppression de tous les certificats d'autorité de certification inutiles de l'objet NTAuthCertificates dans Active DirectoryChaque autorité de certification qui se trouve dans ce magasin est autorisée à émettre des certificats de connexion de carte à puce dans l'Active Directory pour l'ensemble de la structure.
  • Utiliser la subordination qualifiéeLimiter les certificats d'autorité de certification afin de ne leur faire confiance que pour les extended key usages effectivement délivrés. En cas de compromission de l'autorité de certification, le dommage est alors limité à ces Extended Key Usages. Le "Smart Card Logon" Extended Key Usage ne serait alors présent que dans le certificat d'autorité de certification de l'autorité de certification qui délivre effectivement de tels certificats.

Ce qui est intéressant dans ces réflexions, c'est que les contrôleurs de domaine ne vérifient pas du tout les Extended Key Usages lors de la connexion via carte à puce.

Microsoft utilise le terme "Enhanced Key Usage" (utilisation améliorée des clés), mais la désignation correcte selon le RFC 5280 est "Extended Key Usage"..

Vérifier le comportement

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.

On peut vérifier ce comportement via l'observateur d'événements sur le contrôleur de domaine qui traite l'inscription. On peut suivre les opérations qui ont lieu contre les certificats dans le journal de la CryptoAPI (CAPI). Ce protocole est désactivé dans la configuration standard en raison de la grande quantité de données qu'il génère. Il se trouve sous Applications and Services Logs - Microsoft - Windows - CAPI2 - Operational. Un clic droit permet de l'activer avec la commande "Enable Log".

Si l'on effectue une connexion par carte à puce, différents événements concernant le certificat de la carte à puce sont consignés. L'événement qui nous intéresse est celui qui porte le numéro 11.

Dans l'onglet "Détails", on voit que les CertGetCertificateChain est appelée par le processus Local Security Authority Subsystem (lsass). Lors de l'appel, il y a un attribut "ExtendedKeyUsage" qui est vide. Cela signifie que n'importe quel Extended Key Usage est autorisé lors de la vérification du certificat.

Il ne s'agit en aucun cas d'un bug : ce comportement a été intégré à Windows Server 2008 à l'époque de Windows Vista et existe encore aujourd'hui dans toutes les versions de Windows Server. L'objectif était alors de permettre l'ouverture de session avec des cartes d'identité numériques et des documents d'identité comparables. Dans ce cas, il n'était pas possible de s'assurer que les certificats qui s'y trouvaient présentaient les Extended Key Usages corrects, ni même qu'ils disposaient d'une telle extension. Le contrôle a donc été complètement désactivé.

Activation de la vérification des Extended Key Usages

Si l'on souhaite réactiver la vérification des utilisations de clés étendues, il existe une clé de registre à cet effet, qui est définie pour le processus Kerberos Key Distribution Center (KDC) sur chaque contrôleur de domaine doit être activé. Il se trouve sous la clé suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Si l'on crée une valeur DWORD (32 bits) nommée SCLogonEKUnotrequired avec la valeur 0, la vérification des Extended Key Usages est à nouveau active.

Le service KDC doit être redémarré pour appliquer la modification.

Contrôle des résultats

Si l'on procède maintenant à une nouvelle connexion par carte à puce et que l'on intercepte le journal CAPI, on constate que CertGetCertificateChain attend maintenant l'une des trois Extended Key Usages suivantes :

  • id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4)
  • Authentification client TLS/SSL (1.3.6.1.5.5.7.3.2)
  • Connexion par carte à puce (1.3.6.1.4.1.311.20.2.2)

Mais même dans cette constellation, il reste quelques lacunes : ainsi, le Client Authentication Extended Key Usage est très répandu et est par exemple souvent utilisé en relation avec le Microsoft Network Policy Service (NPS), qui exige que le certificat d'autorité de certification se trouve dans le NTAuthCertificates dans l'Active Directory.

Puis-je donc effectuer une inscription par carte à puce avec n'importe quelle utilisation de clé étendue ?

Non, ce n'est pas possible. Le processus du KDC semble à nouveau vérifier si le certificat présenté présente l'une des extended key uages pertinentes (c'est en tout cas ce que suggèrent les tests effectués sur le TGT forging avec kekeo : le KDC va vérifier le certificat en question. Événement n° 21 avec le message d'erreur "The certificate is not valid for the requested usage". ). Toutefois, à ce stade, le KDC n'effectue pas de nouveau contrôle de validité pour le certificat.

Il est donc possible d'exploiter cette faille comme indiqué pour contourner les restrictions éventuelles des Extended Key Usages pour les certificats d'autorité de certification.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais