Récapitulatif
Les mises à jour Windows du 13 juillet 2021 et ultérieures ajoutent des protections pour la vulnérabilité CVE-2021-33757.
Après l’installation des mises à jour Windows du 13 juillet 2021 ou ultérieures, le chiffrement AES (Advanced Encryption Standard) sera la méthode préférée sur les clients Windows lors de l’utilisation du protocole MS-SAMR hérité pour les opérations de mot de passe si le chiffrement AES est pris en charge par le serveur SAM. Si le chiffrement AES n’est pas pris en charge par le serveur SAM, le rétablissement du chiffrement RC4 hérité est autorisé.
Les modifications dans CVE-20201-33757 sont spécifiques au protocole MS-SAMR et sont indépendantes des autres protocoles d’authentification. MS-SAMR utilise SMB sur RPC et des canaux nommés. Bien que SMB prenne également en charge le chiffrement, il n’est pas activé par défaut. Par défaut, les modifications dans CVE-20201-33757 sont activées et offrent une sécurité supplémentaire au niveau de la couche SAM. Aucune modification de configuration supplémentaire n’est requise en plus des protections pour CVE-20201-33757 incluses dans les mises à jour Windows du 13 juillet 2021 ou ultérieures sur toutes les versions prises en charge de Windows. Les versions non prises en charge de Windows ne doivent plus être utilisées ou doivent être mises à niveau vers une version prise en charge.
Remarque :CVE-2021-33757 ne modifie la façon dont les mots de passe sont chiffrés en transit que lors de l’utilisation d’API spécifiques du protocole MS-SAMR , et ne modifie PAS spécifiquement la façon dont les mots de passe sont stockés au repos. Pour plus d’informations sur la façon dont les mots de passe sont chiffrés au repos dans Active Directory et localement dans la base de données SAM (Registre), consultez la rubrique Vue d’ensemble des mots de passe.
Plus d’informations
Modifications apportées par les mises à jour du 13 juillet 2021
Modèle de changement de mot de passe
Les mises à jour modifient le modèle de changement de mot de passe du protocole en ajoutant une nouvelle méthode de changement de mot de passe qui utilise AES.Ancienne méthode avec RC4 Nouvelle méthode avec AES SamrUnicodeChangePasswordUser2 (OpNum 55) SamrUnicodeChangePasswordUser4 (OpNum 73) Pour obtenir la liste complète des numéros OpNum MS-SAMR, consultez la section Événements de traitement des messages et règles de séquencement.
Modèle de définition de mot de passe
Les mises à jour modifient le modèle de définition de mot de passe du protocole en ajoutant deux nouvelles classes d’informations utilisateur à la méthode SamrSetInformationUser2 (Opnum 58). Vous pouvez définir les informations de mot de passe comme suit.Ancienne méthode avec RC4 Nouvelle méthode avec AES SamrSetInformationUser2 (Opnum 58) avec UserInternal4InformationNew qui contient un mot de passe utilisateur chiffré avec RC4. SamrSetInformationUser2 (Opnum 58) avec UserInternal8Information qui contient un mot de passe utilisateur chiffré avec AES. SamrSetInformationUser2 (Opnum 58) avec UserInternal5InformationNew qui contient un mot de passe d’utilisateur chiffré avec RC4 et tous les autres attributs utilisateur. SamrSetInformationUser2 (Opnum 58) avec UserInternal7Information qui contient un mot de passe chiffré avec AES et tous les autres attributs utilisateur.
Comment fonctionne le nouveau comportement ?
La méthode SamrConnect5 existante est généralement utilisée pour établir une connexion entre le client et le serveur SAM.
Un serveur mis à jour retourne maintenant un nouveau bit dans la réponse SamrConnect5() telle que définie dans SAMPR_REVISION_INFO_V1.
| Valeur | Signification |
|---|---|
| 0x00000010 | Dès qu’elle est reçue par le client, cette valeur, si elle est définie, indique que le client doit utiliser le chiffrement AES avec la structure SAMPR_ENCRYPTED_PASSWORD_AES pour chiffrer les tampons de mot de passe en cas d’envoi par réseau. Voir AES Cipher Usage (section 3.2.2.4) et SAMPR_ENCRYPTED_PASSWORD_AES (section 2.2.6.32). |
Si le serveur mis à jour prend en charge AES, le client utilise les nouvelles méthodes et les nouvelles classes d’informations pour les opérations de mot de passe. Si le serveur ne retourne pas cet indicateur ou si le client n’est pas mis à jour, le client rétablit l’utilisation des méthodes précédentes avec le chiffrement RC4.
Impact sur le contrôleur de domaine en lecture seule
Les opérations de définition de mot de passe nécessitent un contrôleur de domaine accessible en écriture (RWDC). Les changements de mot de passe sont transmis par le contrôleur de domaine en lecture seule (RODC) vers un contrôleur RWDC. Tous les appareils doivent être mis à jour pour qu’AES puisse être utilisé. Par exemple :
- Si le client, le RODC ou le RWDC n’est pas mis à jour, le chiffrement RC4 est utilisé.
- Si le client, le RODC et le RWDC sont mis à jour, le chiffrement AES est utilisé.
Journalisation des événements
Les mises à jour du 13 juillet 2021 ajoutent quatre nouveaux événements au journal système afin d’identifier les appareils qui ne sont pas à jour et d’améliorer la sécurité.
L’ID d’événement d’état de configuration 16982 ou 16983 est journalisé au démarrage ou lors de la modification de la configuration du Registre.
ID d’événement 16982
Journal des événements Système Source de l’événement Directory-Services-SAM ID d’événement 16982 Level (Niveau) Informations Texte du message d’événement Le Gestionnaire de comptes de sécurité journalise désormais les événements détaillés pour les clients distants qui appellent des méthodes RPC héritées de changement ou de définition de mot de passe. Ce paramètre peut entraîner un grand nombre de messages et ne doit être utilisé que pendant une courte période pour diagnostiquer des problèmes. ID d’événement 16983
Journal des événements Système Source de l’événement Directory-Services-SAM ID d’événement 16983 Level (Niveau) Informations Texte du message d’événement Le Gestionnaire de comptes de sécurité journalise désormais les événements de synthèse périodiques pour les clients distants qui appellent des méthodes RPC héritées de changement ou de définition de mot de passe. Après l’application de la mise à jour du 13 juillet 2021, un événement de synthèse 16984 est consigné dans le journal des événements système toutes les 60 minutes.
ID d’événement 16984
Journal des événements Système Source de l’événement Directory-Services-SAM ID d’événement 16984 Level (Niveau) Informations Texte du message d’événement Le Gestionnaire de comptes de sécurité a détecté %x appels de méthode RPC héritée de changement ou de définition de mot de passe au cours des 60 dernières minutes. Après la configuration de la journalisation des événements détaillés, l’ID d’événement 16985 est consigné dans le journal des événements système chaque fois qu’une méthode RPC héritée est utilisée pour modifier ou définir un mot de passe de compte.
ID d’événement 16985
Journal des événements Système Source de l’événement Directory-Services-SAM ID d’événement 16985 Level (Niveau) Informations Texte du message d’événement Le Gestionnaire de compte de sécurité a détecté l’utilisation d’une méthode RPC héritée de changement ou de définition à partir d’un client réseau. Envisagez de mettre à niveau l’application ou le système d’exploitation client afin d’utiliser la version la plus récente et la plus sécurisée de cette méthode.
Détails :
Méthode RPC : %1
Adresse réseau client : %2
SID client : %3
Nom d’utilisateur : %4Pour journaliser l’ID d’événement détaillé 16985, basculez la valeur de Registre suivante sur le serveur ou le contrôleur de domaine.
Chemin d’accès HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SAM Type REG_DWORD Nom de la valeur AuditLegacyPasswordRpcMethods Données de la valeur 1 = la journalisation détaillée est activée
0 ou valeur non présente = la journalisation détaillée est désactivée. Événements de synthèse uniquement. (valeur par défaut)
Configurer les itérations PBKDF2 pour le changement de mot de passe
Comme décrit dans SamrUnicodeChangePasswordUser4 (Opnum 73), lorsque vous utilisez la nouvelle méthode SamrUnicodeChangePasswordUser4 , le client et le serveur utiliseront l’algorithme PBKDF2 pour dériver une clé de chiffrement et de déchiffrement à partir de l’ancien mot de passe en texte brut. En effet, l’ancien mot de passe est le seul secret courant connu par le serveur et le client.
Pour plus d’informations sur PBKDF2, consultez la fonction BCryptDeriveKeyPBKDF2 (bcrypt.h).
Si vous devez apporter une modification pour des raisons de performances et de sécurité, vous pouvez ajuster le nombre d’itérations PBKDF2 utilisées par le client pour le changement de mot de passe en définissant la valeur de Registre suivante sur le client.
Remarque
Si vous diminuez le nombre d’itérations PBKDF2, vous abaissez le niveau de sécurité. Nous vous déconseillons de diminuer le nombre par rapport à celui par défaut. Il est toutefois recommandé d’utiliser le plus grand nombre possible d’itérations PBKDF2.
| Chemin d’accès | HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SAM |
|---|---|
| Type | REG_DWORD |
| Nom de la valeur | PBKDF2Iterations |
| Données de la valeur | Minimum de 5 000 et maximum de 1 000 000 |
| Valeur par défaut | 10 000 |
Remarque
PBKDF2 n’est pas utilisé pour les opérations de définition de mot de passe. Pour les opérations de définition de mot de passe, la clé de session SMB est le secret partagé entre le client et le serveur, et est utilisée comme base pour dériver les clés de chiffrement.
Pour plus d’informations, consultez Acquisition d’une clé de session SMB.
Forum aux questions (FAQ)
Quels scénarios déclenchent la rétrogradation d’AES à RC4 ?
La rétrogradation se produit quand le serveur ou le client ne prend pas en charge AES.
Comment savoir si le chiffrement RC4 ou AES a été négocié ?
Les serveurs mis à jour journalisent les événements quand des méthodes héritées avec RC4 sont utilisées.
Puis-je exiger le chiffrement AES sur le serveur, et des mises à jour Windows ultérieures appliqueront-elles par programme l’utilisation d’AES ?
Aucun mode de mise en conformité n’est disponible pour le moment, mais il est possible qu’il le soit ultérieurement. Aucune date n’est définie.
Les clients tiers prennent-ils en charge les protections pour CVE-2021-33757 afin de négocier AES lors d’une prise en charge par le serveur ? Dois-je contacter le service de Support Microsoft ou l’équipe de support tierce pour obtenir une réponse à cette question ?
Si un appareil tiers n’utilise pas le protocole SAMR, cette prise en charge n’est pas importante. Les fournisseurs tiers qui mettent en œuvre le protocole MS-SAMR peuvent choisir de le faire. Contactez le fournisseur tiers si vous avez des questions.
Des modifications de configuration supplémentaires doivent-elles être apportées ?
Aucune modification supplémentaire n’est requise.
Qu’est-ce qui ce protocole ?
Ce protocole est hérité et son utilisation devrait être très faible. Les applications héritées peuvent utiliser ces API. Par ailleurs, certains outils Active Directory tels que la console MMC Utilisateurs et ordinateurs AD utilisent SAMR.
Les changements de mot de passe qui utilisent le protocole Kerberos ou d’autres protocoles sont-ils impactés ?
Non. Seuls les changements de mot de passe qui utilisent ces API SAMR spécifiques sont concernés.
Les performances du contrôleur de domaine peuvent-elles être impactées ?
Oui. PBKDF2 est plus onéreux que RC4. Si de nombreux changements de mot de passe se produisent en même temps sur le contrôleur de domaine appelant l’API SamrUnicodeChangePasswordUser4 , la charge processeur de LSASS peut être affectée. Vous pouvez ajuster les itérations PBKDF2 sur les clients si nécessaire. Il n’est toutefois pas recommandé de définir une valeur inférieure à celle par défaut, car cela abaisse le niveau de sécurité.
Références
Authenticated Encryption with AES-CBC and HMAC-SHA
Utilisation du chiffrement AES
Exclusion de responsabilité de tiers
Microsoft fournit des informations de contact de sociétés tierces afin de vous aider à obtenir un support technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés tierces.