Résumé
Il existe une faille de sécurité dans certains circuits microprogrammés du module de plateforme sécurisée (TPM). Cette vulnérabilité affaiblit la puissance des clés.
Pour en savoir plus sur cette vulnérabilité, consultez la page ADV170012.
Informations supplémentaires
Vue d’ensemble
Les sections suivantes vous permettent d’identifier, d’atténuer et de corriger les certificats et les demandes émis par les services de certificats Active Directory (AD CS) concernés par la vulnérabilité décrite dans l’Avis de sécurité Microsoft ADV170012.
La procédure d’atténuation vise à identifier les certificats émis concernés par la vulnérabilité, ainsi qu’à les révoquer.
Les certificats x.509 émis au sein de votre entreprise reposent-ils sur un modèle qui spécifie un fournisseur KSP TPM ?
Si votre entreprise utilise un fournisseur KSP TPM, il est probable que les scénarios d’utilisation de ces certificats sont exposés à la vulnérabilité décrite dans l’Avis de sécurité.
Atténuation
-
En attendant la publication d’une mise à jour appropriée du microprogramme pour votre appareil, mettez à jour les modèles de certificat définis pour utiliser un fournisseur KSP TPM afin qu’ils utilisent un fournisseur KSP logiciel. Cela empêche la création ultérieure de certificats utilisant un fournisseur KSP TPM et qui sont dès lors vulnérables. Pour plus d’informations, reportez-vous à la section Mise à jour du microprogramme plus loin dans cet article.
-
Pour les certificats ou demandes déjà créés, procédez comme suit :
-
Utilisez le script joint pour obtenir la liste de tous les certificats émis pouvant être vulnérables.
-
Révoquez ces certificats en transmettant la liste de numéros de série obtenue à l’étape précédente.
-
Appliquez l’inscription des nouveaux certificats en fonction de la configuration de modèle qui spécifie à présent un fournisseur KSP logiciel.
-
Réexécutez dès que possible tous les scénarios à l’aide des nouveaux certificats.
-
-
Utilisez le script joint pour obtenir la liste de tous les certificats demandés pouvant être vulnérables.
-
Rejetez toutes ces demandes de certificat.
-
-
Utilisez le script joint pour obtenir la liste de tous les certificats expirés. Assurez-vous qu’il ne s’agit pas de certificats chiffrés encore utilisés pour déchiffrer des données. Les certificats expirés sont-ils chiffrés ?
-
Le cas échéant, assurez-vous que les données sont déchiffrées puis chiffrées à l’aide d’une nouvelle clé reposant sur un certificat créé par un fournisseur KSP logiciel.
-
Dans le cas contraire, vous pouvez ignorer les certificats en toute sécurité.
-
-
Assurez-vous qu’il existe un processus empêchant l’annulation accidentelle de la révocation des certificats révoqués par l’administrateur.
-
S’assurer que les nouveaux certificats KDC respectent les pratiques recommandées actuelles
Risque : De nombreux autres serveurs peuvent respecter les critères de vérification des contrôleurs de domaine et de l’authentification du contrôleur de domaine. Cette situation peut introduire des vecteurs d’attaque KDC non autorisés bien connus.
Correction
Des certificats ayant l’utilisation améliorée de la clé KDC, conformément à la partie 3.2.4 de la norme [RFC 4556], doivent être émis pour tous les contrôleurs de domaine. Pour AD CS, utilisez le modèle d’authentification Kerberos et configurez-le pour remplacer les autres certificats KDC émis.
Pour plus d’informations, l’annexe C de la norme [RFC 4556] explique l’historique des différents modèles de certificat KDC dans Windows.
Lorsque tous les contrôleurs de domaine ont des certificats KDC conformes à la norme RFC, Windows peut se protéger en activant la validation KDC stricte dans Kerberos sous Windows.
Remarque Par défaut, les nouvelles fonctionnalités liées aux clés publiques Kerberos sont obligatoires.
S’assurer que les certificats révoqués échouent au scénario respectif
AD CS est utilisé dans le cadre de différents scénarios dans une organisation. Il peut être utilisé pour le Wi-Fi, le réseau privé virtuel (VPN), KDC, System Center Configuration Manager, etc.
Identifiez tous les scénarios dans votre organisation. Assurez-vous que ces scénarios échouent s’ils possèdent les certificats révoqués ou veillez à remplacer tous les certificats révoqués par des certificats logiciels et à ce que les scénarios réussissent.
Si vous utilisez le protocole OCSP ou des listes de révocation de certificats, ces éléments sont mis à jour à leur expiration. Toutefois, vous devez généralement mettre à jour les listes de révocation de certificats mises en cache sur tous les ordinateurs. Si votre protocole OCSP repose sur des listes de révocation de certificats, assurez-vous qu’il obtient immédiatement les dernières listes.
Pour vérifier que les caches sont supprimés, exécutez les commandes suivantes sur tous les ordinateurs concernés :
certutil -urlcache * delete
certutil –setreg chain\ChainCacheResyncFiletime @now
Mise à jour du microprogramme
Installez la mise à jour publiée par le fabricant OEM pour corriger la vulnérabilité dans le module TPM. Après la mise à jour du système, vous pouvez mettre à jour les modèles de certificat afin qu’ils utilisent un fournisseur KSP TPM.
