Résumé
Les mises à jour Windows du 11 janvier 2022 et les suivantes ajoutent des protections pour CVE-2022-21913.
Après lʼinstallation des mises à jour Windows du 11 janvier 2022 ou ultérieures, AES (Advanced Encryption Standard) sera défini comme méthode de chiffrement préférée sur les clients Windows lorsque vous utilisez le protocole de lʼautorité de sécurité locale hérité (Stratégie de domaine) (MS-LSAD) pour les opérations de mot de passe dʼobjets Domaine approuvé qui sont envoyées sur un réseau. Ceci nʼest valable que si le chiffrement AES est pris en charge par le serveur. Si le chiffrement AES nʼest pas pris en charge par le serveur, le système permettra de revenir au chiffrement RC4 hérité.
Les modifications dans CVE-2022-21913 sont spécifiques au protocole MS-LSAD. Elles sont indépendantes des autres protocoles. MS-LSAD utilise le protocole SMB (Server Message Block) sur un appel de procédure distante
(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-2022-21913 sont activées et offrent une sécurité accrue au niveau de la couche LSAD. Aucune modification supplémentaire au niveau de la configuration nʼest nécessaire en dehors de lʼinstallation des protections pour CVE-2022-21913, qui sont incluses dans les mises à jour Windows du 11 janvier 2022 et 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.
RemarqueCVE-2022-21913 ne modifie que la façon dont les mots de passe dʼapprobation sont chiffrés en transit lorsque vous utilisez des API spécifiques du protocole MS-LSAD, et ne modifient pas 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 Présentation technique des mots de passe.
Informations supplémentaires
Modifications apportées par les mises à jour du 11 janvier 2022
-
Modèle dʼobjet Stratégie
Les mises à jour modifient le modèle dʼobjet Stratégie du protocole en ajoutant une nouvelle méthode de stratégie dʼouverture, qui permet au client et au serveur de partager des informations sur la prise en charge du chiffrement AES.Ancienne méthode à lʼaide du chiffrement RC4
Nouvelle méthode à lʼaide du chiffrement AES
LsarOpenPolicy2 (Opnum 44)
LsarOpenPolicy3 (Opnum 130)
Pour une liste complète des opnums du protocole MS-LSAR, consultez la page [MS-LSAD] : événements de traitement des messages et règles de séquençage.
-
Modèle dʼobjet Domaine approuvé
Les mises à jour modifient le modèle de création dʼobjet Domaine approuvé du protocole en ajoutant une nouvelle méthode pour créer une approbation à lʼaide dʼAES pour chiffrer les données dʼauthentification.
LʼAPI LsaCreateTrustedDomainEx préférera désormais la nouvelle méthode si le client et le serveur sont tous deux mis à jour, et reviendra à lʼancienne méthode dans le cas contraire.
Ancienne méthode à lʼaide du chiffrement RC4
Nouvelle méthode à lʼaide du chiffrement AES
LsarCréerTrustedDomainEx2 (Opnum 59)
LsarCreateTrustedDomainEx3 (Opnum 129)
Les mises à jour modifient le modèle dʼensemble dʼobjets Domaine approuvé du protocole en ajoutant deux nouvelles classes dʼinformations sécurisées aux méthodes LsarSetInformationTrustedDomain (Opnum 27) et LsarSetTrustedDomainInfoByName (Opnum 49). Vous pouvez définir les informations de lʼobjet Domaine approuvé comme suit.
Ancienne méthode à lʼaide du chiffrement RC4
Nouvelle méthode à lʼaide du chiffrement AES
LsarSetInformationTrustedDomain (Opnum 27) avec TrustedDomainAuthInformationInterne ou TrustedDomainFullInformationInternal (contient un mot de passe dʼapprobation chiffré à lʼaide de RC4)
LsarSetInformationTrustedDomain (Opnum 27) avec TrustedDomainAuthInformationInternalAes ou TrustedDomainFullInformationAes (contient un mot de passe dʼapprobation chiffré à lʼaide dʼAES)
LsarSetTrustedDomainInfoByName (Opnum 49) avec TrustedDomainAuthInformationInterne ou TrustedDomainFullInformationInternal (contient un mot de passe dʼapprobation chiffré à lʼaide de RC4 et tous les autres attributs)
LsarSetTrustedDomainInfoByName (Opnum 49) avec TrustedDomainAuthInformationInternalAes ou TrustedDomainFullInformationInternalAes (contient un mot de passe dʼapprobation chiffré à lʼaide dʼAES et tous les autres attributs)
Fonctionnement du nouveau comportement
La méthode LsarOpenPolicy2 existante est généralement utilisée pour ouvrir un handle de contexte sur le serveur RPC. Il sʼagit de la première fonction qui doit être appelée pour contacter la base de données du protocole distant de lʼautorité de sécurité locale (stratégie de domaine). Après lʼinstallation de ces mises à jour, la méthode LsarOpenPolicy2 est remplacée par la nouvelle méthode LsarOpenPolicy3.
Un client mis à jour appelant lʼAPI LsaOpenPolicy appellera désormais la méthode LsarOpenPolicy3 en premier. Si le serveur nʼest pas mis à jour et nʼimplémente pas la méthode LsarOpenPolicy3, le client revient à la méthode LsarOpenPolicy2 et utilise les méthodes précédentes qui ont recours au chiffrement RC4.
Un serveur mis à jour renverra un nouveau bit dans la réponse de la méthode LsarOpenPolicy3, comme défini dans LSAPR_REVISION_INFO_V1. Pour plus dʼinformations, consultez les sections « Utilisation du chiffrement AES » et « LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION_INTERNAL_AES » sur la page MS-LSAD.
Si le serveur prend en charge le chiffrement AES, le client utilisera les nouvelles méthodes et les nouvelles classes dʼinformations pour les opérations « create » et « set » ultérieures du domaine de confiance. Si le serveur ne renvoie pas cet indicateur ou si le client nʼest pas mis à jour, le client emploiera à nouveau les méthodes précédentes, qui ont recours au chiffrement RC4.
Journalisation des événements
Les mises à jour du 11 janvier 2022 ajoutent un nouvel événement au journal des événements de sécurité, permettant dʼidentifier les appareils qui ne sont pas mis à jour à des fins dʼamélioration de la sécurité.
|
Valeur |
Signification |
|---|---|
|
Source de l’événement |
Microsoft-Windows-Security |
|
ID d’événement |
6425 |
|
Niveau |
Informations |
|
Texte du message d’événement |
Un client réseau a utilisé une méthode RPC héritée pour modifier les informations d’authentification sur un objet domaine approuvé. Les informations d’authentification ont été chiffrées avec un algorithme de chiffrement hérité. 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. Domaine approuvé :
Modifié par :
Adresse réseau client : Pour plus d’informations, rendez-vous sur https://go.microsoft.com/fwlink/?linkid=2161080. |
Forum aux questions (FAQ)
Q1 : Quels scénarios déclenchent le passage d’AES à la version antérieure RC4 ?
R1 : Un passage à une version antérieure se produit si le serveur ou le client ne prend pas en charge AES.
Q2 : Comment puis-je savoir si le chiffrement RC4 ou AES a été négocié ?
R2 : Les serveurs mis à jour enregistrent l’événement 6425 lorsque des méthodes héritées qui utilisent RC4 sont utilisées.
Q3 : Puis-je exiger le chiffrement AES sur le serveur, et les futures mises à jour de Windows seront-elles mises en conformité par programme à l’aide d’AES ?
R3 : Il n’y a actuellement aucun mode de mise en conformité disponible. Cependant, bien qu’aucune modification de ce type ne soit planifiée, il pourrait y en avoir à l’avenir.
Q4 : Les clients tiers prennent-ils en charge les protections pour CVE-2022-21913 afin de négocier AES lors d’une prise en charge par le serveur ? Dois-je contacter le support Microsoft ou l’équipe de support tierce pour obtenir une réponse à cette question ?
R4 : Si un appareil tiers ou une application tierce n’utilise pas le protocole MS-LSAD, cela n’a pas d’importance. Les fournisseurs tiers qui implémentent le protocole MS-LSAD peuvent choisir d’implémenter ce protocole. Pour plus d’informations, contactez le fournisseur tiers.
Q5 : Des modifications de configuration supplémentaires doivent-elles être apportées ?
R5 : Aucune modification de configuration supplémentaire n’est nécessaire.
Q6 : Qu’est-ce qui utilise ce protocole ?
R6 : Le protocole MS-LSAD est utilisé par de nombreux composants Windows, notamment Active Directory et des outils tels que la console Domaines et approbations Active Directory. Les applications peuvent également utiliser ce protocole via les API de la bibliothèque advapi32, telles que LsaOpenPolicy ou LsaCreateTrustedDomainEx.
