88 - Pentesting Kerberos

Définition et Histoire

Kerberos est un protocole d'authentification entre 2 appareils de confiance dans un Active Directory. Ce dernier est présent depuis Windows 2000, et est apparu en premier lieu dans la RFC 4120.

Entités Kerberos et royaume

Kerberos s'appuie sur 3 entités :

1. Le client, autrement dit l'entité cliente demandant un accès (utilisateur ou service)

Ce dernier peut être un user, de la forme classique [email protected]. Dans ce cas la, l'utilisateur est Thomas et le "royaume" est domaine.local. (nous reviendrons dans cette notion de royaume plus tard)

Mais il peut également être un service, de la forme SMB\[email protected]. Ici le service concerné est SMB, l'instance du service SMB (autrement dit le FQDN de l'hôte de ce service) est serveur_fichier.domaine.local et le royaume est domaine.local.

2. La ressource, ce qui peut être un service, un serveur, un fichier, etc.
3. Le KDC (Key Distribution Center), qui est le centre de distribution de clés qui authentifie les clients et délivre les tickets

Le royaume quant a lui, est une manière de regrouper de manière logique les ressources et identitiés Kerberos. Il est représenté par un nom de domaine, et est souvent le nom de domaine de l'Active Directory.

KDC (Key Distribution Center)

Le KDC est lui responsable de la distribution des clés de chiffrement entre les entités. Il est composé de 2 parties :

1. L'AS (Authentication Service), qui est le service d'authentification. Il est :

• Responsable de l'authentification des clients et de la distribution des TGT (Ticket Granting Ticket)
• Contient la base de données des principaux (utilisateurs et services)
• Utilise le compte krbtgt pour chiffrer les communications. Ce compte est créé lors de la création du domaine et est unique pour chaque domaine.

2. Le TGS (Ticket Granting Server), qui est le service de distribution de tickets. Il est :

• Utilise le TGT présenté par le client et la clé de session associée
• Vérifie que le client a le droit d'accéder à la ressource demandée
• Émet des tickets de services temporaires pour accéder aux ressources (nous parlerons ici de ST, ou Service ticket)

Schéma explicatif du fonctionnement de kerberos

Etape 1 : Authentification

Dans un premier temps le client doit s'authentifier auprès de l'AS. Cela se fait de cette manière

Le client envoie dans un premier temps un message en clair a l'AS précisant son Username, son IP ainsi que le service qu'il demande.

Dans ce message, le client précise une durée de vie pour le TGT, mais c'est l'AS qui le définira

L'AS répond avec 2 messages :

1. Le premier est chiffré avec la clé du compte client (récupéré depuis la base de donnée du KDC). Ce dernier contient le Nom/ID du TGS (Ticket Granting Server), Un timestamp, la durée de vie du TGT, ainsi que la clé de session du TGS
2. Le second est chiffré avec la clé du TGS. Ce dernier contient le Nom/ID du TGS, un timestamp, l'IP du client, la durée de vie du TGT, ainsi que la clé de session du TGS.

Le 2nd message est appelé TGT ou Ticket Granting Ticket.

Ce mécanisme permet à la fois :

• D'authentifier le client auprès de l'AS (si le client à pu déchiffrer le message 2 sur le schéma)
• De distribuer de manière sécurisée la clé de session TGS au client. Cette clé sera utile par la suite pour communiquer de manière sécurisée avec le TGS

Clé du compte client

La clé du compte client correspond au hash du password du compte, salé avec le nom de l'utilisateur + le domaine, soit utilisateur@domaine.

Cela permet donc, si aucune pré-authentification n'est activée, à un attaquant de pouvoir cracker le mot de passe d'un compte utilisateur.

Le client à donc en sa possession la clé de session TGS, il peut donc commencer à communiquer avec ce dernier pour obtenir son ST (Service Ticket)

Etape 2 : Commmunication avec le TGS

Le client envoie ensuite 3 messages différents au TGS :

4. Ce dernier est diffusé en clair, spécifiant le nom de l'utilisateur souhaitant accéder au service, ainsi que la durée de vie souhaitée du ST
5. Celui ci est chiffré avec la clé de session TGS (obtenue précédemment) et contient l'username/id du client ainsi qu'un timestamp
6. Enfin, ce dernier est chiffré avec la clé du TGS, et c'est une copie du message 3 (avec les attributs suivants : Username/Id du client, Nom/Id du TGS, Timestamp, IP du client, Durée de vie du TGT et la clé de session TGS)

Le TGS va donc :

• Déchiffrer le message 6 avec la clé du TGS, et récupérer la clé de session TGS
• Déchiffrer le message 5 avec la clé de session TGS, et vérifier que le timestamp est valide (pour éviter les replays). Il va aussi vérifier que le username est valide et correspond bien à une entrée dans la base de données du KDC
• Vérifier que le nom du service demandé dans le message 4 est bien valide et existe bien dans la base de données du KDC
• Stocker le message 5 déchiffré dans le cache pour éviter les replays

Le TGS à donc authentifié le client (si le client à pu utiliser la clé de session du TGS), et le client à authentifié le TGS (si le TGS à pu déchiffrer le message 6)

Etape 3 : Obtention du ST

Le TGS envoie ensuite 2 messages au client :

7. Ce message est chiffré avec la ** clé de session TGS** et contient le Nom/Id du service, un timestamp, La durée de vie du ST ainsi que la clé de session du service
8. Ce message est chiffré avec la clé du service et contient l'username/id du client, le nom/id du service, un timestamp, l'IP du client, la durée de vie du ST ainsi que la clé de session du service

Ce mécanisme permet de diffuser la clé de session du service de manière sécurisée au client. Cette clé sera utilisée par la suite pour communiquer avec le service.

Le message 8 est donc appelé ST ou Service Ticket.

Etape 4 : Communication avec le service

Pour communiquer avec le service, le client envoie 2 messages au service :

9. Ce message est chiffré avec la clé du service et contient l'username/id du client, le nom/id du service, un timestamp, l'IP du client, la durée de vie du ST ainsi que la clé de session du service. Ce message est une copie du ST évoqué précédemment
10. Ce message est chiffré avec la clé de session du service et contient l'username/id du client ainsi qu'un timestamp

Le service va donc :

• Déchiffrer le message 9 avec la clé du service, et vérifier que le timestamp est valide (pour éviter les replays). Il va aussi vérifier que le username est valide et correspond bien à une entrée dans la base de données du KDC
• Déchiffrer le message 10 à l'aide de la clé de session obtenue dans le message 9, et vérifier que le nom de l'utilisateur est bien le même que pour le message 9
• Stocker le message 10 déchiffré dans le cache pour éviter les replays
• Envoyer un message (11) au client, chiffré avec la clé de session du service, contenant le nom/id du service ainsi qu'un timestamp

Le client va pouvoir authentifier le service, en déchiffrant le message 11 avec la clé de session du service. Il va aussi stocker le message 11 déchiffré dans le cache pour éviter les replays

Le service à donc authentifié le client (si le client à pu utiliser la clé de session du service), et le client à authentifié le service (si le service à pu déchiffrer le message 10)

La communication entre les 2 entités peut se faire avec la clé de session du service, transmise par le TGS précédemment.

Schéma complet