Objet: Classe de vulnérabilités en environnement Active Directory

Résumé

Le protocole d’authentification NTLM souffre de faiblesses permettant, sous conditions, à un attaquant de relayer une authentification qu’il reçoit d’une victime vers un serveur cible. Ceci peut potentiellement permettre à cet attaquant d’élever ses privilèges ou d’envoyer des commandes à exécuter à la cible sans connaître les secrets d’authentification ainsi détournés, mais en bénéficiant des droits d’accès de la victime.

Idéalement, dans un environnement Active Directory, il faudrait désactiver globalement l’utilisation de l’authentification NTLM au profit d’une utilisation exclusive de Kerberos. Cependant, l’authentification NTLM reste souvent nécessaire au bon fonctionnement de certaines applications non migrées vers Kerberos, il n’est donc pas souvent possible d’interdire NTLM globalement.

Cependant, les authentifications des services de l’Active Directory entre systèmes Windows supportent nativement Kerberos et l’authentification NTLM peut être désactivée pour ces systèmes. Or ce sont les hauts niveaux de privilèges de ces connexions qui sont activement exploités.

Afin de limiter certaines attaques sur NTLM, il est fortement recommandé de bloquer les authentifications NTLM sortantes des systèmes les plus privilégiés d’un environnement Active Directory. Ceci aura pour effet d’empêcher de manière générique l’exploitation de la classe de vulnérabilités connue sous le nom de « relai NTLM » vis-à-vis de ces systèmes critiques pour éviter que leurs authentifications soient détournées.

Cette mesure de blocage doit être appliquée sur tous les systèmes Windows les plus critiques, en particulier les contrôleurs de domaine. En effet, détourner l’authentification des contrôleurs de domaine permet d’élever ses privilèges au niveau domaine, puis forêt.

Comme toute recommandation, cette mesure de blocage doit faire l’objet d’une qualification attentive pour prévenir tout dysfonctionnement.

Description

Le 23 juillet 2021, Microsoft publiait un avis de sécurité [1,2] concernant un défaut de configuration répandu permettant d'élever ses privilèges dans des environnements Active Directory (AD) utilisant un serveur Active Directory Certificate Services (ADCS). Cette vulnérabilité consiste à provoquer l'authentification NTLM d'un contrôleur de domaine vers une machine contrôlée par un attaquant (par exemple, au moyen de l'outil "Petit Potam" [3]) et à relayer les messages d'authentification de ce contrôleur vers l'interface Web d'un serveur ADCS. L'attaquant est alors authentifié avec le compte du contrôleur de domaine et peut demander l'émission d'un certificat X.509 permettant l'authentification sur d'autres contrôleurs de domaine en tant que l'un d'entre eux. Un contrôleur de domaine étant un des objets les plus privilégiés dans l'annuaire AD, ceci permet la compromission de toute la forêt au moyen d'outils publics.

Le cœur de la vulnérabilité est le fait que le serveur Web de destination mis en œuvre par ADCS accepte le protocole d'authentification à distance NTLM dans une configuration qui n'impose pas la signature des messages transmis, permettant leur altération et leur relai par un attaquant.

Pour les serveurs ADCS, Microsoft recommande de corriger la vulnérabilité en imposant dans leur configuration la signature des requêtes HTTP à destination du serveur Web, ou, idéalement en interdisant toute authentification NTLM entrante sur ces serveurs.

Cependant, le problème initial subsiste : les contrôleurs de domaine pourraient à l’avenir être la cible d’une attaque par relai NTLM exploitant une autre vulnérabilité déclenchant cette authentification de leur part.

Pour pallier les défauts de configuration d'autres services ou serveurs (RPC, Web et autres applicatifs confondus), et dans une démarche de défense en profondeur, l'ANSSI recommande de désactiver l'authentification NTLM sortante sur les systèmes les plus privilégiés, en particulier les contrôleurs de domaine. Ainsi, la classe de vulnérabilité de relai d'authentification de ces systèmes (au moyen de PetitPotam ou d'un autre outil) vers n'importe quel service (ADCS ou autre) est bloquée à sa source.

Pour réaliser ce changement de configuration, il est conseillé de procéder en deux phases :

1. Qualification au moyen d'un réglage de journalisation

Activer la journalisation des authentifications NTLM sortantes sur tous les contrôleurs de domaine, au moyen de la politique de groupe (GPO) ci-dessous. Cette étape n'altère pas le fonctionnement du contrôleur de domaine, et ne bloque aucune fonctionnalité ni tentative d'exploitation. Ou, sur un contrôleur installé en anglais : Une fois ce réglage déployé, toute authentification NTLM sortante d'un contrôleur de domaine génère un évènement Microsoft-Windows-NTLM/8001 de niveau Information, visible dans l'Observateur d'évènements (eventvwr.msc) dans la catégorie Journaux des applications et services > Microsoft > Windows > NTLM :  

Ce journal peut également être consulté programmatiquement, par exemple dans une session PowerShell ouverte sur un contrôleur de domaine :

 

2. Blocage des authentifications sortantes

Une fois qu’il est avéré que les contrôleurs de domaine ne requièrent pas d’authentification NTLM sortante, modifier la GPO créée ci-dessus pour bloquer les tentatives d'authentification NTLM sortantes : Ou, sur un contrôleur installé en anglais : Une fois ce réglage déployé, toute authentification NTLM sortante d'un contrôleur de domaine est bloquée et génère un évènement Microsoft-Windows-NTLM/4001 (et non plus 8001) de niveau Avertissement, visible dans le même journal d'évènements.

Il convient finalement d'ajouter une alerte à tout système de détection d'incident de sécurité lorsqu'un tel évènement est généré pour une authentification à destination d'une adresse IP n'appartenant pas à un contrôleur de domaine.

Note : les tests effectués par l’ANSSI montrent :

• qu’un contrôleur de domaine peut spontanément s’authentifier en NTLM vers les services SMB et LDAP d’autres contrôleurs de domaine. Malgré ces évènements relevés, le blocage des authentifications sortantes déclenchera l’usage de Kerberos et n’aura pas d’impact sur le bon fonctionnement du domaine ;
• que des blocages concernant des authentifications vers des services désignés par adresse IP doivent suggérer la mauvaise configuration d’un service. Il est recommandé d’utiliser des noms FQDN associés à des SPN pour permettre l’usage de Kerberos en remplacement de NTLM ;
• que les relations d’approbation resteront fonctionnelles et que leurs secrets resteront renouvelés périodiquement (via le mécanisme NetLogon qui n’implique ni NTLM ni Kerberos) ;
• que la configuration est réversible et que l’interdiction peut être rapidement annulée en modifiant la GPO mise en place.

Une fois cette mesure de durcissement déployée, dans une optique de défense en profondeur pour se protéger contre d’autres d’attaques de type « relai NTLM », il est fortement recommandé d’appliquer les mesures suivantes :

• Sur tous les contrôleurs de domaine [5] :
  • Exiger la signature des échanges sur le service LDAP [6]
  • Exiger le CBT (Channel Binding Token) TLS sur le service LDAP si le client le supporte
• Sur tous les contrôleurs de domaine ou tous les systèmes qui exposent le service SMB ou des RPC sur canaux nommées :
  • Exiger le CBT du nom de service (SPN) si celui-ci est fourni par le client [7]

Ces trois paramètres peuvent être définis dans les options de stratégie de sécurité : Ou, sur un contrôleur installé en anglais : Là encore, il est nécessaire de préalablement qualifier les impacts de ces paramètres. Pour cela, des évènements particuliers sont générés et peuvent aider à diagnostiquer une éventuelle incompatibilité [8][9].

Documentation :

[1] "KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)" : https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429

[2] "Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)" : https://msrc.microsoft.com/update-guide/vulnerability/ADV210003

[3] "Petit Potam" : https://github.com/topotam/PetitPotam

[4] "Sécurité réseau: restreindre NTLM: trafic NTLM sortant vers des serveurs distants" : https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers

[5] "Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing" : https://msrc.microsoft.com/update-guide/en-US/vulnerability/ADV190023

[6] "Comment activer la signature LDAP dans Windows Server" : https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server

[7] "Serveur réseau Microsoft : niveau de validation du nom de la cible de serveur SPN" : https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level

[8] "LDAP Channel Binding and LDAP Signing Requirements - March 2020 update final release" : https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536

[9] "2020 LDAP channel binding and LDAP signing requirements for Windows" : https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-ef185fb8-00f7-167d-744c-f299a66fc00a