Elad Shamir

Certaines personnes sont un marteau à la recherche d'un clou, mais je suis un marteau à la recherche de la délégation Kerberos. Ainsi, lorsque j'ai appris qu'une limite WriteSPN avait été introduite dans BloodHound 4.1, j'ai commencé à explorer d'autres techniques d'abus que le Kerberoasting ciblé, et j'ai trouvé un cas limite (jeu de mots) qui peut être enchaîné avec la Délégation Contrainte Kerberos.

En bref

Supposons qu'un attaquant compromette un compte configuré pour la délégation restreinte, mais qu'il ne dispose pas du privilège SeEnableDelegation. L'attaquant ne pourra pas modifier les contraintes (msDS-AllowedToDelegateTo). Cependant, si l'attaquant dispose des droits WriteSPN sur le compte associé au SPN cible, ainsi que sur le compte d'un autre ordinateur/service, il peut temporairement détourner le SPN (technique appelée SPN-jacking), l'affecter à l'autre ordinateur/serveur, et effectuer une attaque S4U complète pour le compromettre.

De même, si le SPN cible n'est actuellement associé à aucun compte, l'attaquant peut se l'approprier de la même manière.

Je serai le premier à admettre qu'il ne s'agit pas d'une découverte révolutionnaire, mais elle peut permettre de relancer des attaques apparemment sans issue dans certaines circonstances. Le piratage de SPN peut également être une technique de prise de contrôle alternative si RBCD ou Shadow Credentials ne sont pas viables.

Initiation à la délégation Kerberos

La délégation Kerberos est un mécanisme qui permet aux services d'usurper l'identité des utilisateurs auprès d'autres services. Par exemple, un utilisateur peut accéder à une application frontale, et cette application peut, à son tour, accéder à une API back-end avec l'identité et les autorisations de l'utilisateur.

La délégation Kerberos se présente sous trois formes : la délégation sans contrainte, la délégation avec contrainte et la délégation avec contrainte basée sur les ressources (RBCD).

Délégation sans contrainte

La délégation sans contrainte exige que les utilisateurs envoient leur ticket d'attribution de ticket (TGT) au service frontal (serveur A). Le service frontal peut ensuite utiliser ce ticket pour usurper l'identité de l'utilisateur auprès de n'importe quel service, y compris le service dorsal (serveur B).

Délégation restreinte

La délégation restreinte permet au service frontal (serveur A) d'obtenir des tickets de service Kerberos pour les utilisateurs auprès d'une liste prédéfinie de services spécifiés par leur nom de principal de service (SPN), tels que le service dorsal, le serveur B.

Notez que la délégation contrainte permet au service d'usurper l'identité d'utilisateurs à partir de rien, qu'ils se soient authentifiés auprès du service ou non. Beaucoup pensent que cela dépend de la configuration de l'attribut TrustedToAuthForDelegation. Cependant, lorsqu'elle est associée à la délégation contrainte basée sur les ressources, cette limitation peut être contournée, comme je l'explique dans ce billet de blog.

Délégation restreinte basée sur les ressources

La RBCD est très similaire à la délégation restreinte, sauf que le sens de la contrainte est inversé. Elle spécifie qui est autorisé à déléguer à un service plutôt que qui est autorisé à déléguer au service. En d'autres termes, si le serveur A est autorisé à déléguer au serveur B dans le cadre de la délégation restreinte, la contrainte sera configurée dans un attribut du serveur A. Dans le cadre de la délégation restreinte, elle sera configurée dans un attribut du serveur B.

Une autre différence importante entre la délégation restreinte et le RBCD est que la délégation restreinte spécifie le SPN du service cible. En revanche, RBCD spécifie le SID du service d'origine dans un descripteur de sécurité.

Privilèges requis

La configuration de la délégation sans contrainte et de la délégation avec contrainte nécessite le privilège SeEnableDelegation, qui, par défaut, n'est accordé qu'aux administrateurs de domaine. Par conséquent, même si un utilisateur dispose d'un contrôle total (GenericAll) sur un compte AD, il ne pourra configurer aucun de ces types de délégation Kerberos s'il ne dispose pas également du privilège SeEnableDelegation. Contrairement à la délégation sans contrainte et à la délégation avec contrainte, RBCD requiert le droit de modifier l'attribut msDS-AllowedToActOnBehalfOtherIdentity, mais aucun privilège particulier.

Il convient de noter que les utilisateurs ont besoin de privilèges spéciaux pour modifier la configuration de la délégation restreinte, mais qu'aucun privilège spécial n'est nécessaire pour modifier les SPN. Par conséquent, il peut être intéressant d'aborder les scénarios avec le compromis de la délégation restreinte sous un angle différent, en manipulant l'attribut SPN plutôt que la configuration de la délégation.

Préparer le terrain

Supposons que l'environnement comporte trois serveurs : ServeurA, ServeurB et ServeurC. Le serveur A est configuré avec une délégation restreinte à un certain SPN. L'attaquant a compromis ServerA et le compte NotAdmin, qui a des droits d'écriture sur les comptes d'ordinateur/service dans l'environnement. L'objectif de l'attaquant est de compromettre le serveur C.

Fantôme SPN-jacking

Le premier scénario est le plus simple. Le serveur A est configuré pour une délégation restreinte à un SPN précédemment associé à un ordinateur ou à un compte de service qui n'existe plus. Il peut s'agir d'un SPN standard, tel que cifs/nom d'hôte, associé à un compte d'ordinateur/de service supprimé ou à un compte calculé renommé si les SPN ont été mis à jour en conséquence. Le compte peut également être un SPN personnalisé avec une classe de service non standard qui a été supprimée du compte d'ordinateur/de service, ou le compte lui-même peut ne plus exister.

Dans ce scénario, l'attaquant peut ajouter le SPN concerné au serveur C, puis exécuter l'attaque S4U complète en utilisant le compte du serveur A pour obtenir un ticket de service pour un utilisateur privilégié sur le serveur C.

Le nom de service de ce ticket ne serait pas valide pour accéder au serveur C car le nom d'hôte ne correspondrait pas, et la classe de service pourrait être inutile. Cependant, ce qui est important, c'est que le ticket est crypté pour ServiceC, et que le nom du service n'est pas dans la partie cryptée du ticket, de sorte que l'attaquant peut le changer en un nom valide.

Enfin, l'attaquant peut passer le ticket et compromettre le serveur C.

La chaîne d'attaque est illustrée dans le diagramme suivant :

L'attaque est illustrée dans la capture d'écran suivante :

Piratage en direct du SPN

Le second scénario est un peu plus artificiel. Le serveur A est configuré pour une délégation restreinte à un SPN actuellement associé au serveur B, et l'attaquant a des droits d'écriture sur le serveur B et le serveur C.

Dans les environnements entièrement corrigés, seuls les administrateurs de domaine sont autorisés à configurer des SPN conflictuels, c'est-à-dire des SPN associés à deux comptes différents ou plus. Par conséquent, si l'attaquant dans ce scénario essayait d'ajouter le SPN cible au ServeurC, le DC rejetterait ce changement parce qu'il est déjà associé au ServeurB.

L'attaquant peut contourner cet obstacle en supprimant temporairement le SPN cible du serveur B et en l'ajoutant ensuite au serveur C. L'attaquant peut alors exécuter l'attaque S4U complète en utilisant le compte de ServerA pour obtenir un ticket de service pour un utilisateur privilégié sur ServerC.

Comme dans le scénario précédent, le nom de service de ce ticket ne serait pas valide pour accéder au serveur C. Toutefois, ce qui importe, c'est que le ticket est crypté pour le serveur C et que le nom du service ne figure pas dans la partie cryptée du ticket, de sorte que l'attaquant peut le modifier.

Enfin, l'attaquant peut passer le ticket et compromettre le serveur C.

Un attaquant bien élevé devrait également annuler les modifications en supprimant le SPN cible du serveur C et en le rétablissant sur le serveur B.

La chaîne d'attaque est illustrée dans le diagramme suivant :

SPN-jacking avec la classe de service HOST

La situation devient plus intéressante lorsque le SPN ciblé n'est pas explicitement défini. Par défaut, les comptes d'ordinateur ont des SPN associés aux classes de service TERMSRV, RestrictedKrbHost et HOST. Si d'autres services sont installés, tels que LDAP ou SQL Server, des SPN supplémentaires sont également ajoutés pour ceux-ci.

La classe de service HOST est associée par défaut aux classes de service suivantes :
alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc.

Si l'attaquant tente de cibler une classe de service mappée sur HOST, le contrôleur de domaine refusera d'ajouter cette classe de service à ServerC, même si elle n'est pas directement associée à ServerB. L'attaquant devrait d'abord supprimer les SPN HOST du serveur B, puis ajouter explicitement le SPN cible au serveur C. Cependant, après avoir ajouté le SPN cible au serveur C, l'attaquant peut ajouter les SPN HOST au serveur B sans rencontrer d'erreur de validation, bien qu'un SPN mappé soit déjà associé au serveur C, comme le montre la capture d'écran suivante :

Lorsque l'on demande des tickets de service au SPN ambigu, cifs/SERVERB dans la capture d'écran ci-dessus, le contrôleur de domaine les émet pour le ServeurC plutôt que pour le ServeurB.

La chaîne d'attaque est illustrée dans le diagramme suivant :

Comment les attaquants peuvent-ils utiliser le piratage SPN ?

Si un attaquant compromet un compte avec des droits GenericAll ou GenericWrite sur des comptes d'ordinateur, il peut utiliser RBCD ou Shadow Credentials pour compromettre l'hôte ou le service associé. Je pense qu'il est peu probable qu'un compte disposant uniquement de droits WriteSPN sur des comptes d'ordinateur soit compromis. Cependant, en enchaînant avec la compromission d'un hôte où la délégation restreinte est déjà configurée, les attaquants pourraient utiliser cette technique dans des environnements où le RBCD et les Shadow Credentials sont surveillés ou bloqués. Les défenseurs devraient suivre les recommandations ci-dessous pour atténuer les attaques de piratage SPN.

Détecter le piratage SPN

Les modifications de l'attribut ServicePrincipalName d'un compte d'ordinateur génèrent des événements de sécurité avec l'ID 4742 (Un compte d'ordinateur a été modifié) sur le contrôleur de domaine. Les détails de l'événement indiquent les attributs modifiés et leur nouvelle valeur. Les défenseurs peuvent détecter les SPN dont le nom d'hôte est différent des noms DNS de l'ordinateur, comme le montre la capture d'écran ci-dessous :

La suppression de la classe de service HOST d'un compte d'ordinateur peut également être suspecte.

L'attaque S4U génère deux événements de sécurité avec l'ID 4769 (Un ticket de service Kerberos a été demandé).

Le premier événement concerne S4U2Self. Les défenseurs peuvent le détecter lorsque les informations sur le compte et les informations sur le service pointent vers le même compte, comme le montre la capture d'écran ci-dessous :

Le deuxième événement concerne S4U2Proxy. Les défenseurs peuvent le détecter lorsque l'attribut Transited Services n'est pas vide, comme le montre la capture d'écran ci-dessous :

Prévenir le piratage SPN

Les défenseurs peuvent appliquer plusieurs tactiques pour prévenir ce type d'abus :

  • Auditer régulièrement Active Directory pour détecter les délégations restreintes pointant vers des SPN fantômes.
  • Auditer régulièrement Active Directory à la recherche de droits d'écriture anormaux.
  • Ajouter tous les comptes privilégiés au groupe Protected Users afin de bloquer toute tentative d'usurpation d'identité par le biais de la délégation Kerberos.

Les attaquants peuvent manipuler le SPN des comptes d'ordinateur/service pour rediriger la délégation restreinte préconfigurée vers des cibles non souhaitées, même sans obtenir les privilèges SeEnableDelegation.

Bien que les scénarios décrits dans cet article ne soient pas courants, ils peuvent constituer des pistes d'attaque viables lorsqu'un compte compromis est configuré pour une délégation restreinte qui serait autrement considérée comme bénigne ou comme une alternative à RBCD et Shadow Credentials.

Les défenseurs doivent prendre les mesures nécessaires pour détecter et prévenir ces attaques.

Références

Cet article a également été publié sur shenaniganslabs.io et eladshamir.com.