Kerberos en Active Directory

Pour ce premier « vrai » article, le sujet sera le fonctionnement de Kerberos, l’un des protocoles d’authentification au cœur d’Active Directory. Le comprendre permet de comprendre une bonne partie des attaques sur celui-ci (AS-REP roasting, Kerberoasting, Golden et Silver Tickets, etc.). L’objectif de cet article est surtout d’expliquer :

• comment un utilisateur prouve son identité sans envoyer son mot de passe ;
• pourquoi copier un ticket ne suffit pas à s’en servir (et où un attaquant va donc le chercher) ;
• qui chiffre quoi, avec quelle clé ;
• ce qu’un attaquant regarde à chaque étape.

Cet article doit beaucoup à celui de Pixis sur hackndo, qui m’a permis de comprendre de nombreuses bases d’Active Directory lorsque j’ai débuté le pentest. Je ne peux donc que vous recommander d’aller le lire et de profiter de son contenu comme j’ai pu le faire il y a quelques années.

Maintenant, allons-y pour l’explication !

Le problème : ouvrir un partage sans donner son mot de passe

Alice, comptable dans l’entreprise, veut ouvrir le partage \\FS01\compta depuis son poste. Le serveur doit savoir à qui il a affaire, avec deux contraintes :

• le mot de passe d’Alice ne doit jamais circuler sur le réseau, même chiffré ;
• FS01 ne doit pas avoir à connaître le mot de passe de tous les utilisateurs du domaine.

Kerberos résout ce problème avec un tiers de confiance, le KDC (Key Distribution Center). Dans un domaine Active Directory, c’est le contrôleur de domaine qui joue ce rôle. Le parcours se fait en trois temps :

1. Alice se fait reconnaître par le KDC, une seule fois, et reçoit un justificatif ;
2. avec ce justificatif, elle demande un ticket pour le service qui l’intéresse ;
3. elle présente ce ticket au service.

Ces trois échanges portent des noms qu’on retrouve partout (dans Wireshark, dans les outils, dans les journaux) : AS (Authentication Service), TGS (Ticket-Granting Service) et AP (Application). Le justificatif obtenu au premier échange s’appelle le TGT (Ticket-Granting Ticket).

Une image pour fixer les idées : un grand hôtel, avec une piscine, une salle de sport, un spa et un restaurant.

1. La réception : prouver son identité. En arrivant, Alice présente sa carte d’identité. Le réceptionniste vérifie qu’elle est bien cliente de l’hôtel et lui remet une carte de résident, qui prouve qu’elle a été identifiée. C’est l’échange AS, et la carte de résident, c’est le TGT.
2. La conciergerie : demander un accès. Alice veut aller au spa. Elle présente sa carte de résident au concierge, qui la vérifie et lui remet un pass valable pour le spa, et pour lui seul. C’est l’échange TGS, et le pass, c’est le ticket de service.
3. Le spa : utiliser son accès. À l’entrée du spa, l’employé vérifie que le pass est valide et qu’il correspond bien au spa, puis laisse entrer Alice, sans appeler la conciergerie. C’est l’échange AP.
4. Et la piscine ? Pas besoin de repasser à la réception avec sa carte d’identité : Alice retourne à la conciergerie avec sa carte de résident et obtient un nouveau pass, pour la piscine cette fois.

La réception et la conciergerie sont deux guichets du même acteur, le KDC : c’est lui qui distribue à la fois les TGT et les tickets de service.

L’image a une limite : une carte ou un pass, ça se vole. En Kerberos, présenter un ticket ne suffit pas, il faut aussi prouver qu’on en est le propriétaire légitime. C’est tout l’objet de la section « Pourquoi copier un ticket ne suffit pas ».

Qui connaît quelle clé

Kerberos repose entièrement sur des clés secrètes partagées : c’est du chiffrement symétrique, la même clé chiffre et déchiffre. Chaque compte du domaine, utilisateur ou machine, possède une clé dérivée de son mot de passe, et ne connaît que sa propre clé. Le KDC, lui, les connaît toutes, plus une qui n’appartient qu’à lui : celle du compte spécial krbtgt.

Tout le reste découle de là : le KDC peut écrire à n’importe qui un message que seul ce destinataire saura lire, et un destinataire qui arrive à ouvrir un message chiffré avec sa clé sait qu’il a été écrit par le KDC (ou par lui-même).

Étape 1 (AS) : obtenir un TGT

Suivons Alice, elle vient de taper son mot de passe à l’ouverture de session : son poste en a dérivé sa clé, et ne se servira plus du mot de passe lui-même.

KRB_AS_REQ : prouver qu’on connaît son secret

Alice demande un TGT au KDC. Sa requête contient son nom (en clair) et l’heure actuelle (chiffrée avec sa propre clé). Cette heure chiffrée est la pré-authentification : seul quelqu’un qui connaît la clé d’Alice a pu la produire.

À la réception de ce message, le KDC récupère la clé d’Alice dans sa base et déchiffre l’horodatage. S’il obtient une heure proche de la sienne (5 minutes d’écart tolérées par défaut), la demande vient bien de quelqu’un qui connaît le secret d’Alice. Sinon, elle est rejetée (c’est l’une des raisons pour lesquelles les horloges d’un domaine doivent rester synchronisées).

KRB_AS_REP : deux parties pour deux lecteurs

Ensuite, le KDC génère au hasard une clé de session, valable le temps du TGT, puis répond avec deux parties :

• une partie pour Alice, chiffrée avec la clé d’Alice, qui contient la clé de session ;
• le TGT, chiffré avec la clé krbtgt. Il contient le nom d’Alice, la période de validité du TGT, la même clé de session et le PAC, qui décrit les groupes d’Alice (on l’ouvrira à l’étape 3).

À ce stade, on peut se demander : pourquoi deux parties ? Parce qu’il y a deux lecteurs. La première est pour Alice, tout de suite. Le TGT est pour le KDC lui-même, plus tard : c’est une note qu’il s’adresse à lui-même et qu’il confie au client. Alice ne peut pas la lire, elle la garde telle quelle pour la présenter à sa prochaine demande. Grâce à elle, le KDC n’a pas besoin de se souvenir d’Alice entre deux échanges.

Pourquoi copier un ticket ne suffit pas

Le TGT voyage sur le réseau. Un attaquant qui écoute le trafic peut donc en récupérer une copie. Que peut-il en faire ?

Rien, grâce à la clé de session. Chaque fois qu’elle présente un ticket, Alice y joint un authentifiant : son nom et l’heure, chiffrés avec la clé de session. Le ticket dit « voici Alice » ; l’authentifiant ajoute « et c’est bien moi qui le présente, la preuve : je connais la clé qui va avec ».

Or la clé de session n’a jamais circulé qu’à l’intérieur de boîtes fermées : avec la clé d’Alice dans l’AS-REP, et avec la clé krbtgt dans le TGT. L’attaquant qui a copié le trafic ne peut donc ni fabriquer un authentifiant neuf, ni lire les réponses du KDC, chiffrées elles aussi avec cette clé.

Retenez cette paire : un ticket ne sert à rien sans sa clé de session. Les deux échanges suivants appliquent exactement ce principe.

Étape 2 (TGS) : demander un ticket pour un service

KRB_TGS_REQ : présenter son TGT

Alice veut maintenant utiliser le service de partage de fichiers de FS01, appelé CIFS. Elle envoie au KDC :

• son TGT, tel quel ;
• le nom du service visé, son SPN (Service Principal Name) : CIFS/FS01 ;
• un authentifiant, chiffré avec la clé de session.

Le KDC ouvre le TGT avec la clé krbtgt, y lit l’identité d’Alice et la clé de session, puis déchiffre l’authentifiant avec cette clé. Si les deux concordent et que l’heure est récente, la demande vient bien du détenteur légitime du TGT. À aucun moment la clé d’Alice n’intervient : le TGT en tient lieu pendant toute sa durée de validité (10 heures par défaut).

KRB_TGS_REP : un ticket pour FS01

Le KDC cherche ensuite quel compte porte le SPN CIFS/FS01 : ici, le compte machine FS01$. Il prépare, sur le même modèle que l’AS-REP :

• un ticket de service destiné à FS01 : nom du service, identité d’Alice, PAC et une nouvelle clé de session, le tout chiffré avec la clé de FS01$ ;
• une partie pour Alice, chiffrée avec la première clé de session, qui contient la nouvelle.

Étape 3 (AP) : être reconnue, puis autorisée

KRB_AP_REQ : présenter le ticket au service

Alice envoie à FS01 le ticket de service et un nouvel authentifiant, chiffré avec la seconde clé de session. FS01 ouvre le ticket avec sa propre clé, sans appeler le KDC : en dehors de lui, seul le KDC connaît cette clé, donc seul le KDC a pu fabriquer ce ticket. Il y trouve la clé de session, déchiffre l’authentifiant et vérifie : même nom, heure récente, et un authentifiant qu’il n’a pas déjà reçu (il garde en mémoire ceux des dernières minutes, pour qu’une requête copiée ne puisse pas être rejouée). Alice est authentifiée.

Le PAC : qui est Alice, pour Windows

Kerberos dit qui est Alice, pas ce qu’elle a le droit de faire. Pour cela, Windows ajoute au ticket le PAC (Privilege Attribute Certificate) : le SID d’Alice, ceux de ses groupes, et des signatures qui empêchent de les modifier. Le KDC l’a rempli à la création du TGT, puis l’a recopié dans le ticket de service.

FS01 compare ces SID aux permissions du partage et des fichiers (les ACL), et décide. Le PAC ne donne aucun droit par lui-même : un ticket parfaitement valide n’ouvre que ce que les ACL autorisent. Et comme les groupes sont figés à la création du TGT, un utilisateur ajouté à un groupe doit obtenir un nouveau TGT (en pratique, rouvrir sa session) pour que cela compte.

Enfin, si le client demande l’authentification mutuelle, le serveur prouve à son tour son identité, en renvoyant une KRB_AP_REP chiffrée avec la clé de session : seul le vrai FS01 a pu ouvrir le ticket et en sortir cette clé.

Le voir sur un vrai poste

Le parcours complet, d’un trait : Alice ouvre sa session, puis le partage de FS01. Le TGT obtenu au début reste en cache : tant qu’il est valide, il suffit, avec sa clé de session, pour demander d’autres tickets sans repasser par le mot de passe.

Le cache de tickets avec klist

Sur un poste du domaine, klist affiche le cache Kerberos de la session. L’expérience est simple : on vide le cache, on accède au partage, puis on regarde ce qui est revenu.

klist purge
dir \\FS01\compta
klist

Deux tickets doivent apparaître. Le TGT, dont le serveur est krbtgt/LAB.LOCAL, et le ticket de service, pour cifs/FS01.lab.local. Chacun indique ses heures de début et de fin, et son type de chiffrement : AES-256-CTS-HMAC-SHA1-96 sur un domaine récent, RSADSI RC4-HMAC si RC4 est encore utilisé. Windows a redemandé un TGT tout seul, sans redemander le mot de passe : il garde la clé d’Alice en mémoire pour la durée de la session.

Ce qu’il faut retenir

Le mot de passe ne circule jamais : il sert une fois, sur le poste, à dériver une clé. Ensuite :

• chaque message n’est lisible que par ceux qui doivent le lire ;
• chaque ticket prouve qu’il a été fabriqué par un détenteur de la bonne clé ;
• aucun ticket ne sert sans sa clé de session.

C’est tout pour cet article, qui voulait présenter les bases de Kerberos (et mentionner certaines des attaques liées). J’espère que le contenu n’était pas trop indigeste et que les animations ont pu rendre sa compréhension plus simple.