Kerberos de bout en bout

Chaque fois qu’un utilisateur ouvre sa session dans un domaine, accède à un partage ou se connecte à une application d’entreprise, Kerberos travaille en coulisses. C’est un protocole élégant : le mot de passe ne circule jamais sur le réseau. Mais chacune de ses étapes a donné naissance à une attaque connue. Comprendre Kerberos, c’est comprendre la moitié des attaques sur Active Directory.

Le principe : des tickets plutôt que des mots de passe

Le nom vient de Cerbère, le chien à trois têtes qui garde les Enfers dans la mythologie grecque.

Kerberos repose sur un tiers de confiance, le KDC (Key Distribution Center), qui tourne sur chaque contrôleur de domaine. Le KDC connaît la clé secrète de tout le monde (dérivée du mot de passe de chaque compte). Au lieu d’envoyer son mot de passe à chaque service, l’utilisateur obtient des tickets chiffrés qu’il présente.

Trois acteurs :

• le client (l’utilisateur sur son poste) ;
• le KDC, qui regroupe l’AS (Authentication Service) et le TGS (Ticket Granting Service) ;
• le service que l’utilisateur veut utiliser (un partage, une base SQL, un site intranet).

L’analogie classique est celle du parc d’attractions : on passe une fois au guichet d’entrée avec sa pièce d’identité pour obtenir un bracelet (le TGT), puis on échange ce bracelet contre des tickets pour chaque attraction (les tickets de service), sans remontrer sa pièce d’identité.

Les trois échanges

  Client                         KDC (contrôleur de domaine)                 Service
    │                                                                           │
 1  │ ── AS-REQ (horodatage chiffré avec ma clé) ──►  AS                         │
    │ ◄── AS-REP : TGT (chiffré clé krbtgt) + clé de session                    │
    │                                                                           │
 2  │ ── TGS-REQ (TGT + SPN demandé) ──────────────►  TGS                        │
    │ ◄── TGS-REP : ticket de service (chiffré clé du service) + clé de session │
    │                                                                           │
 3  │ ── AP-REQ (ticket de service + authentificateur) ─────────────────────────►│
    │ ◄── (optionnel) AP-REP : authentification mutuelle ───────────────────────│

1. AS-REQ / AS-REP : obtenir le TGT

Le client envoie une demande à l’AS. Pour prouver qu’il connaît son mot de passe, il y joint un horodatage chiffré avec sa clé : c’est la pré-authentification. Le KDC, qui connaît cette clé, vérifie qu’il arrive à le déchiffrer.

Si c’est bon, il renvoie :

• un TGT (Ticket Granting Ticket), chiffré avec la clé du compte krbtgt. Le client ne peut ni le lire ni le modifier ;
• une clé de session, chiffrée avec la clé du client, qui servira pour la suite.

Le TGT contient l’identité de l’utilisateur, la clé de session et le PAC (Privilege Attribute Certificate), avec le SID de l’utilisateur et de tous ses groupes.

Ce qu’on voit : l’événement 4768 sur le contrôleur de domaine (ou 4771 en cas d’échec de pré-authentification).

2. TGS-REQ / TGS-REP : obtenir un ticket de service

Quand l’utilisateur veut accéder à un service, son poste envoie au TGS le TGT et le SPN du service voulu, par exemple cifs/fichiers.corp.local pour un partage.

Le TGS renvoie un ticket de service, chiffré avec la clé du compte qui fait tourner ce service, et une nouvelle clé de session pour dialoguer avec lui.

Ce qu’on voit : l’événement 4769 sur le contrôleur de domaine, avec le service demandé et le type de chiffrement.

3. AP-REQ : se présenter au service

Le client envoie le ticket de service au service, accompagné d’un authentificateur (son identité et un horodatage, chiffrés avec la clé de session). Le service déchiffre le ticket avec sa propre clé, vérifie l’authentificateur, et lit le PAC pour connaître les groupes de l’utilisateur et décider de ses droits.

Si le client le demande, le service répond pour prouver à son tour son identité : c’est l’authentification mutuelle, l’un des avantages de Kerberos sur NTLM.

Les SPN

Un SPN (Service Principal Name) relie un service à un compte du domaine.

SPN	Service
cifs/fichiers.corp.local	Partage de fichiers SMB
HTTP/intranet.corp.local	Site web avec authentification Windows
MSSQLSvc/db01.corp.local:1433	SQL Server
ldap/dc01.corp.local	LDAP sur un DC

Les services qui tournent avec le compte de la machine utilisent la clé de ce compte, dont le mot de passe est long, aléatoire et renouvelé automatiquement. Les services qui tournent avec un compte de service utilisateur utilisent un mot de passe choisi par un humain… souvent faible et jamais changé.

Le temps et la durée des tickets

• Décalage d’horloge : 5 minutes maximum par défaut. Au-delà, les authentificateurs sont refusés, pour empêcher le rejeu.
• Durée d’un TGT : 10 heures par défaut, renouvelable pendant 7 jours.
• Types de chiffrement : AES256 et AES128 aujourd’hui ; RC4-HMAC encore présent dans beaucoup de domaines, et apprécié des attaquants parce que sa clé est directement l’empreinte NT du mot de passe.

Pourquoi chaque étape a son attaque

C’est le tableau qui fait le lien avec l’article sur les attaques :

Étape	Faiblesse	Attaque
AS-REQ sans pré-authentification	Le KDC renvoie des données chiffrées avec la clé du compte, sans preuve préalable	AS-REP roasting
TGS-REP	Ticket chiffré avec la clé du compte de service, délivré à tout le monde	Kerberoasting
TGT chiffré par krbtgt	Avec la clé de krbtgt, on forge n’importe quel TGT	Golden ticket
Ticket de service chiffré par la clé du service	Avec la clé d’un service, on forge un ticket pour ce service	Silver ticket
Tickets présents en mémoire	Un ticket volé peut être réutilisé	Pass-the-ticket
Clé dérivée du mot de passe (RC4 = hash NT)	Avec le hash, on demande un TGT sans connaître le mot de passe	Overpass-the-hash

Kerberos ou NTLM ?

Dans un domaine, Kerberos est le protocole par défaut. Windows retombe sur NTLM quand Kerberos est impossible : accès par adresse IP au lieu du nom, machine hors domaine, SPN manquant ou en double, DC injoignable. Le prochain article explique pourquoi ces retours à NTLM sont un problème de sécurité.