Risques associés aux délégations Kerberos

Le protocole Kerberos s’est imposé ces dernières années comme le principal service d’authentification dans les environnements Active Directory. L’authentification mutuelle est en effet un apport non négligeable par rapport aux autres protocoles historiques implémentés par Microsoft. Le protocole NTLMv2 a été développé en réponse à différentes attaques sur les protocoles Lan Manager (LM) et NTLMv1 aujourd’hui obsolètes, mais celui-ci souffre lui aussi de l’absence d’authentification du serveur par le client.

Kerberos est néanmoins un protocole complexe et ses fonctionnalités peuvent engendrer d’autres problèmes de sécurité. Comme nous allons le voir, différentes attaques qui exploitent les mécanismes de délégation d’authentification du protocole peuvent conduire à une escalade de privilège voire à une compromission du domaine Active Directory.

Pour rappel, la délégation Kerberos permet à un service, après authentification d’un utilisateur, de s’authentifier au nom de celui-ci auprès d’autres services. Cette délégation peut être réalisée selon plusieurs modes [1] :

Délégation complète (unconstrained delegation) : lorsqu’un compte de service est préalablement autorisé pour la délégation via le drapeau “TRUSTED_FOR_DELEGATION”, l’utilisateur délègue complètement son authentification à ce service en lui transmettant son TGT (Ticket Granting Ticket) en plus du TGS (ticket de service) utilisé pour l’accès au service. Le service est alors en mesure d’utiliser le TGT pour demander au KDC (Key Distribution Center) des TGS au nom de l’utilisateur pour n’importe quel autre service.
Transition de protocole (protocol transition) : lorsqu’un utilisateur accède à un service sans présenter de TGS (authentification NTLM, par exemple), l’extension S4U2Self (Service For User To Self) autorise ce service à demander au KDC un TGS pour lui-même au nom de l’utilisateur. Le compte de service doit préalablement être autorisé pour la délégation via le drapeau “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”.
Délégation contrainte (contrained delegation) : lorsqu’un utilisateur accède à un service en lui transmettant un TGS, l’extension S4U2proxy (Service For User To Proxy) autorise ce service à demander au KDC des TGS au nom de l’utilisateur pour d’autres services. Le service doit être préalablement être déclaré dans l’attribut “msDS-AllowedToDelegateTo” des comptes des autres services (outgoing trust).

Une variante de la délégation contrainte, appelée resource-based constrained delegation, fonctionne dans le sens inverse : elle permet d’autoriser un service à accéder à d’autres services au nom de l’utilisateur, en déclarant préalablement ce service dans l’attribut “msDS-AllowedToActOnBehalfOfOtherIdentity” des autres services (incoming trust).

Délégation complète

La délégation complète est un mécanisme Kerberos particulièrement dangereux : si un attaquant compromet un serveur approuvé pour la délégation, alors celui-ci est en mesure de récupérer les TGTs de tous les utilisateurs authentifiés ou qui se sont récemment authentifiés auprès de ce serveur.

Plusieurs scénarios d’attaque exploitant ce type de délégation peuvent mener à la compromission du domaine Active Directory.

Une première attaque, appelée printer bug, a été présentée en 2018 par Will Schroeder, Lee Christensen et Matt Nelson lors de la conférence DerbyCon 8 [3].
Lorsque le service Windows “Spouleur d’impression” (Printer Spooler) est actif sur un hôte du réseau, il est possible d’invoquer la méthode “RpcRemoteFindFirstPrinterChangeNotification” pour forcer cet hôte à ouvrir une connexion vers une adresse arbitraire à travers le protocole SMB. Via un appel à cette méthode, un attaquant peut capturer le TGT d’une machine sur laquelle le service Spooler est actif en forçant celle-ci à se connecter à un serveur approuvé pour la délégation complète sous son contrôle. Cela devient particulièrement critique si ce service Windows est actif sur un contrôleur de domaine Active Directory : l’obtention d’un TGT lié au compte d’un contrôleur de domaine permet à l’attaquant de mener une attaque DCSync, qui exploite les mécanismes de réplication AD pour récupérer l’ensemble des secrets d’authentification stockés dans l’annuaire. Ce attaque peut également être menée pour étendre la compromission à d’autres forêts Active Directory liées par des relations d’approbation bidirectionnelles, comme illustré par le schéma ci-dessous [4]:

Sur le même principe, une autre attaque consiste à invoquer l’API “PushSubscription” d’un serveur Exchange pour capturer son TGT [5]. Les privilèges du serveur Exchange peuvent alors être exploités pour compromettre le domaine. Ce scénario découle de l’attaque PrivExchange qui a déjà été présentée sur ce blog [6].

Transition protocolaire et délégation contrainte

Bien qu’à priori plus sûrs que la délégation complète, d’autres mécanismes de délégation du protocole Kerberos sont affectés par plusieurs faiblesses de conception mises en lumière fin janvier 2019 par le chercheur en sécurité Elad Shamir [7] :

A partir du TGT de tout compte de service, il est possible d’obtenir un TGS pour un utilisateur arbitraire via la transition de protocole (extension S4U2Self). Si ce compte ne porte pas le drapeau “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” alors le TGS qui lui est délivré au nom de l’utilisateur par le KDC n’est PAS marqué comme FORWARDABLE et ne peut donc pas être directement utilisé pour l’accès à d’autres services.
Alors qu’une délégation contrainte “classique” nécessite l’utilisation d’un TGS marqué comme FORWARDABLE, un ticket de service NON marqué comme FORWARDABLE est accepté dans le cadre d’une resource-based constrained delegation. Un TGS marqué comme FORWARDABLE est toujours délivré en réponse de la délégation, même si le TGS transmis par le service invoquant l’extension S4U2proxy n’est PAS marqué comme FORWARDABLE.

Les faiblesses induites par la combinaison des extensions S4U2Self et S4U2Proxy (S4U attack) se traduisent en chemins de compromission, dont voici les principaux :

Si un attaquant contrôle un compte de service qui est par ailleurs déclaré dans l’attribut “msDS-AllowedToActOnBehalfOfOtherIdentity” d’autres comptes services (resource-based constrained delegation), alors l’attaquant est à même d’usurper l’identité d’un utilisateur arbitraire pour accéder aux hôtes associés à ces services.
Par extension, si un attaquant contrôle un compte de service alors celui-ci est à même d’usurper l’identité d’un utilisateur arbitraire pour accéder à l’hôte associé à ce service, comme illustré par le schéma ci-dessous. Par défaut, une permission autorise en effet tout compte de service à configurer une resource-based constrained delegation pour lui-même.

Elad Shamir a par ailleurs décliné l’attaque S4U pour différents scénarios concrets, par exemple :

Compromission d’un serveur hébergeant un service MSSQL à partir d’un accès simple à ce service (exécution de code arbitraire), via un appel à la procédure stockée xp_dirtree par défaut accessible par tout utilisateur authentifié
Compromission d’une machine Windows 10, 2016 ou 2019 à partir d’un accès non-privilégié à la machine (escalade de privilège local), via la modification de l’avatar du compte utilisateur

Dans ces scénarios l’attaque S4U est combinée avec d’autres faiblesses de configuration par défaut d’Active Directory, notamment :

Tout utilisateur du domaine est par défaut autorisé à créer jusqu’à 10 nouveaux comptes machine dans l’annuaire, tel que spécifié par l’attribut “MachineAccountQuota” de l’objet domaine [8]
Tout utilisateur du domaine est par défaut autorisé à créer de nouveaux enregistrements DNS dans Active Directory Integrated DNS (ADIDNS), tant que le nom d’hôte n’est pas déjà déclaré [9]

Enfin, Elad expose également dans son article une technique de persistance qui consiste à configurer une unconstrained resource-based delegation au niveau du compte “krbtgt” pour pouvoir générer des TGTs à la demande au nom d’un utilisateur arbitraire.

Détection

L’attaque S4U peut être détectée dans les journaux des contrôleurs de domaine via l’événement 4769 (demande de ticket de service Kerberos) :

Un abus de l’extension S4U2Self est caractérisé par la présence d’un même identifiant de compte dans les sections “Account Information” et “Service Information”
Un abus de l’extension S4U2Proxy est caractérisé par la présence d’un attribut “Transited Services” non-vide dans la section “Additional Information”

La technique de persistance évoquée peut être détectée par le même type d’événement, avec la présence de l’identifiant de compte “krbtgt” dans la section “Service Information” et un attribut “Transited Services” non-vide.

Remédiation

La délégation complète est à proscrire avant tout, puisqu’elle augmente le risque de compromission du domaine Active Directory et des éventuelles forêts qui y sont liées par des relations d’approbation.

Certaines contre-mesures peuvent par ailleurs s’avérer efficaces contre les attaques exploitant les délégations Kerberos :

Protéger les comptes à privilège avec l’option “sensitive for delegation” ou en plaçant ses derniers dans le groupe “Protected Users” (disponible à partir de Windows Server 2012 R2), même si cette protection n’est pas toujours efficace dans le contexte d’une attaque S4U
Forcer la signature du trafic LDAP et SMB pour se prémunir des attaques de type NTLM Relay, qui peuvent être combinées à l’attaque S4U
Positionner à 0 la valeur de l’attribut ms-DS-MachineAccountQuota pour interdire à un utilisateur non-privilégié de créer de nouveaux comptes machines dans l’AD
Envisager un durcissement des DACL pour interdire à tout compte du domaine d’écrire dans son propre attribut “msDS-AllowedToActOnBehalfOfOtherIdentity”
Envisager un durcissement des DACL pour interdire à tout utilisateur authentifié de créer des enregistrement DNS dans ADIDNS