Kerberos : théorie et exploitaiton

Enumération Kerberos

Pour ce premier court article de la série « exploitation de Kerberos » nous allons voir comment faire de l’énumération d’utilisateurs grâce au protocole Kerberos.

Lors d’une authentification, trois message peuvent être renvoyés par l’Authentication Service :

KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN : si le nom d’utilisateur n’existe pas.
KRB5KDC_ERR_PREAUTH_REQUIRED : si l’utilisateur est valide mais qu’il doit s’authentifier.
KDC_ERR_CLIENT_REVOKED : le compte utilisateur n’existe plus.

En analysant le type de message envoyé par l’AS nous allons donc pouvoir définir si un utilisateur existe, a existé ou n’existe pas.

Pour la suite de l’article nous allons nous servir de Metasploit qui propose un module auxiliaire pour exploiter ce défaut de conception : auxiliary/gather/kerberos_enumusers

Trois options sont à spécifier : le domaine, l’IP du KDC et un fichier contenant la liste des utilisateurs à tester :

enum1.png

Ici quatre utilisateurs ont été découvert. Ils pourront nous servir plus tard notamment pour une session de brute force. Attention cependant à respecter la politique de blocage de comptes afin de ne pas bloquer tous les utilisateurs de tout un réseau Active Directory  !

Authentification Kerberos

Kerberos (en référence au chien à trois têtes qui protège l’accès aux enfers) est un protocole d’authentification développé par le MIT puis repris par Windows et introduit pour la première fois sur Windows 2000 afin de remplacer NTLM.

Kerberos offre plusieurs avantages à NTLM : il est plus rapide dans l’authentification,  ne stocke aucun mot de passe sur la machine, n’envoie aucun mot de passe sur le réseau (hashé ou en clair) et, cerise sur le gâteau,  il permet une authentification Single Sign On.

Pas mal non ?!

Sur chaque contrôleur de domaine (serveur qui héberge l’Active Directory) se trouve un serveur un peu particulier : le KDC (Key Distribution Center). Ce KDC est une entité de confiance absolue sur le réseau. C’est à dire que tous les services/serveurs/utilisateurs/ressources font confiance au KDC.

Ce KDC est divisé en deux rôles. Le premier c’est l’Authentication Service (AS) : c’est le service sur lequel s’authentifie le client. Le second : c’est le Ticket Granting Service (TGS) : celui qui fournit le droit d’accès à la ressource :

kb1.png

La première étape est celle de l’authentification. Généralement, c’est un utilisateur qui va se connecter à une session Windows en entrant un couple identifiant/mot de passe. A partir de ces informations, le client Kerberos présent sur chaque machine va dériver le mot de passe en un hash qui sera utilisé afin de chiffrer, entres autres, un timestamp.

Une première requête, nommée KRB_AS_REQ, sera ainsi émise et contiendra le nom de l'utilisateur en clair ainsi qu'un ensemble de données chiffrées qui contiendra entres autres un timestamp:

 

L’Authentication Service, lorsqu’il va recevoir le message, va directement vérifier que le nom d’utilisateur correspond à un utilisateur dans l’AD. Si c’est le cas, il va récupérer le hash du mot de passe de cet utilisateur puis tenter de déchiffrer le bloc chiffré contenant le timestamp. S'il y arrive c'est que le mot de passe renseigné par le client est valide.

Dans ce là, l’Authentication Service va renvoyer un Ticket Granting Ticket (que l’on abrège TGT) ainsi qu'une clé de session qui sera utilisée pour les futures communiques. Le tout est chiffrée à l'aide du hash NTLM de l'utilisation et émis via la requête KRB_AS_REP:

Mais de quoi est composé un TGT ? Un TGT est composé de deux parties:

Le PAC, pour Privileged Attribute Certificate, contient tout un tas de données relative à l'utilisateur, à ses droits et à la validité du TGT. Pour information il est possible de déchiffrer un TGT à la volée dès lors que l'on connait le hash NTLM du compte krbtgt. Pour cela on pourra utiliser des outils tels que decryptKerbTicker.py. Vous trouverez ci-dessous un extrait de ticket TGT déchiffré

ticketdecrypted.png

Une fois le TGT acquis, le client pourra faire une demande d’accès à un service auprès du TGS (Ticket Granting Service) du KDC en émettant une requête  KRB_TGS_REP. Cette requête contiendra le TGT de l'utilisateur, le SPN du service qu'il cherche à joindre ainsi qu'un nouveau timestamp chiffré à l'aide de la clé de session précédement émise par l'AS.


Un SPN, pour Service Principal Name, permet d'associer un nom de service à une machine. C'est un identifiant unique sur un réseau. Pour illustrer la suite de cet article nous partirons du principe que notre client veut accéder à un serveur mail donc le SPN est IMAP/mail.whiteflag.local.


 

Comme c’est le KDC qui a chiffré le TGT, il va aussi pouvoir le déchiffrer. Et comme c’est lui qui l’a créé et émis, il va avoir une totale confiance en ce TGT. Si les informations sont correctes alors le TGS va émettre un Service Ticket (ST ou TGS selon les normes) via le requête KRB_TGS_REP. Notez bien que le Ticket Granting Service permet d’authentifier le client mais en aucun cas il ne donne une autorisation d’accès à la ressource.

Encore une fois, ce TGS est partiellement chiffré. Les métadonnées sont utilisables par le client mais le contenu du TGS lui est chiffré à partir du hash NTLM du mot de passe du compte de service relatif à la ressource demandée. Et encore une fois, un clé de session unique sera créée pour un temps limité. Cette clé sera utilisée afin de chiffrer les échanges entre le client et la ressource demandée.

Le client n'aura plus qu'à forwarder son TGS vers la ressource demandée pour s'y voir attribuer (ou non) l'accès:

Vu que le TGS est chiffré à partir du hash NTLM du mot de passe du compte de service du serveur mail, ce dernier sera en mesure de le déchiffrer et donc de donner un accès ou non au client. C’est ici que l’accès est autorisé ou refusé au client.

Golden Tickets : how you got willy wokaed

Tout au long de cet article nous allons nous intéresser à une notion essentielle lorsque l’on parle de pentest sur un environnement Active Directory : les Golden Tickets.

Pour faire simple, et passer directement à la partie pratique, un golden ticket c’est tout simplement un TGT toujours valide. Ainsi un attaquant qui réussit à créer un Golden Ticket pourra se déplacer librement sur l’ensemble du domaine Active Directory.


Si les notions de TGT, TGS, krbtgt et globalement Kerberos ne vous disent rien je vous invite fortement à lire cet article qui vous présentera le fonctionnement de l’authentification via Kerberos.


Let’s dive into the wonderful world of Kerberos ! 

I/ Création d’un Golden Ticket

Pour tester en live le fonctionnement des Golden Tickets nous n’avons besoin que de deux VM (un DC et une machine faisant parti du domaine), un domaine (ici whiteflag.local) et deux comptes utilisateur (ici Administrateur et victime).

La première chose importante à retenir c’est que pour forger un Golden Ticket il faut au préalable avoir d’importants privilèges sur un DC. Autrement dit il faut déjà être administrateur du domaine.

Pour vous prouver que l’utilisateur victime n’a aucun privilège nous allons tenter de lister le répertoire c$ du dc1 :

gt1.png

Comme prévu il n’y a pas accès. En revanche nous savons que l’administrateur du domaine s’est connecté sur cette machine et comme nous venons de la rooter nous avons pu dumper le contenu de la mémoire du processus LSASS.

Par chance nous y avons trouvé le mot de passe du compte de l’administrateur. Nous sommes donc en mesure de nous connecter au DC et par la même occasion dumper le contenu de la base NTDS.dit. Pour cela plusieurs outils peuvent être utilisés. Pour ma part j’utilise l’outil CrackMapExec développé par le plus que connu Byt3bl33d3r :

sudo cme smb 192.168.0.80 -u Administrateur -p Admin@WF --ntds

Comme prévu nous y trouvons le hash NTLM du mot de passe du compte krbtgt. A noter que nous aurions très bien pu nous connecter au DC et utiliser l’utilitaire Mimikatz afin de dumper la base grâce à cette commande :

lsadump::dcsync /domain:whiteflag.local /all

Mais pourquoi est ce qu’on a besoin de ce hash ? Eh bien comme vous devez le savoir la première étape de l’authentification kerberos consiste à récupérer un TGT auprès de l’Authentication Service (AS). Ce TGT c’est une sorte de carte d’identité qui nous représente sur un réseau Active Directory. Cependant, le TGT n’est pas lisible puisqu’une grosse partie de son contenu est chiffré à l’aide… du hash NTLM du mot de passe du compte krbtgt.

Pa conséquent, pour créer un TGT valide nous devons le chiffrer avec le bon hash (d’où la nécessité de dumper la base NTDS.dit).

Revenons sur notre machine compromise. Avant de lancer Mimikatz nous allons avoir besoin de récupérer le SID du domaine. Pour le récupérer il suffira de lancer la commande whoami /all ou encore utiliser la console WMIC :

wmic useraccount get name,sid