Menu
Kerberos en Active Directory

Kerberos en Active Directory

Active Directory est une solution de Microsoft utilisée pour la gestion d’un système d’information, articulée sur les points suivants :

  • Un système d’annuaire de ressources (LDAP)
  • Un système d’authentification (Kerberos)
  • Un système de résolution de noms (DNS)
  • Une politique logicielle homogène

Nous allons nous intéresser dans cet article à la partie authentification au sein d’un Active Directory, donc à la partie Kerberos.

Kerberos est un protocole qui permet à des utilisateurs de s’authentifier sur le réseau, et d’accéder à des services de manière authentifiée.

Fonctionnement

Le besoin auquel répond Kerberos est celui d’un utilisateur qui souhaite utiliser un service exposé quelque part sur le réseau, sans pour autant que l’utilisateur ait besoin d’envoyer son mot de passe, et sans que le serveur ait besoin de connaitre les mots de passe de tout le monde. C’est une authentification centralisée.

Pour répondre à cette problématique, il faut au minimum trois entités

  • Un client, qui peut être un ordinateur, un service, une personne, …
  • Une machine proposant un service
  • Un Key Distribution Center ou centre de distribution de clés (KDC) qui est le contrôleur de domaine (DC) en environnement Active Directory

Entité en jeu

L’idée est que lorsque le client veut accéder au service, aucun mot de passe ne sera envoyé sur le réseau, évitant ainsi des fuites de ceux-ci qui pourraient compromettre le réseau, et l’authentification est centralisée, c’est au niveau du KDC que ça se passe.

Pour cela, le processus est un peu lourd, et se découpe en trois étapes :

  1. Authentication Service (AS) : Le client doit s’authentifier auprès du KDC
  2. Ticket-Granting Ticket (TGT) : Il doit ensuite demander un ticket permettant d’accéder au service choisi (par exemple CIFS)
  3. Accès au service (AP) : Il communique enfin avec le service en lui fournissant le ticket

C’est un peu comme dans certaines soirées. Si vous voulez consommer quelque chose, vous devez vous présenter à la caisse avec une pièce d’identité pour demander un ticket de consommation. Une fois que la caisse a vérifié que vous étiez bien autorisé à boire, elle vous donne un ticket de consommation tamponné, non falsifiable (théoriquement). Une fois en possession de ce ticket, vous pouvez aller au bar et demander votre consommation en présentant le ticket. Le bar peut vérifier que ce ticket vient bien de la caisse grace au tampon, et vous sert un petit Ricard.

Très sommairement, le processus ressemble à ça :

Processus simplifié

Très bien, mais concrètement, comment ça fonctionne ?

Nous sommes donc dans un contexte Active Directory, ce qui fait que le KDC est également le contrôleur de domaine (Domain Controller ou DC). Le KDC possède l’ensemble des informations du domaine, dont les clés de chacun des services, machines, utilisateurs, … Tous les autres éléments ne connaissent que leur clé, et n’ont de ce fait pas connaissance des clés des autres objets dans l’Active Directory.

Nous sommes donc dans la situation suivante :

DC avec clés

Prenons comme exemple l’utilisateur pixis qui veut communiquer avec un service donné. Il faudra pour cela qu’il s’authentifie auprès du KDC pour ensuite pouvoir demander d’utiliser le service. Cette phase s’appelle Authentication Service (AS).

Authentication Service (AS)

KRB_AS_REQ

pixis va dans un premier temps envoyer une demande de Ticket Granting Ticket (TGT) au contrôleur de domaine (DC). Cette demande est appelée KRB_AS_REQ (Kerberos Authentication Service Request). Le TGT que demande le client est un bout d’information chiffrée contenant entre autre une clé de session et des informations sur l’utilisateur (ID, nom, groupes, …).

Afin d’effectuer cette demande de TGT, pixis va envoyer son nom au KDC ainsi que l’heure précise de la demande (heure qu’il va chiffrer avec son secret) et quelques autres informations en clair.

Clé de session

Le KDC va alors recevoir ce nom, et va vérifier qu’il existe dans sa base de données.

Clé de session

S’il le trouve, il va alors récupérer le condensat (ou hash) du mot de passe de pixis qu’il utilisera pour tenter de déchiffrer le timestamp envoyé. S’il n’y arrive pas, c’est que le client n’est pas celui qu’il prétend être.

S’il y arrive, en revanche, c’est que c’est bien pixis qui est en train de lui parler puisque l’utilisateur a connaissance du secret de pixis, donc le KDC va générer une clé de session qui sera unique pour cet utilisateur, ce ticket, et limitée dans le temps.

Clé de session

KRB_AS_REP

Le KDC va alors renvoyer à pixis différents éléments dans sa réponse (KRB_AS_REP)

  • La clé de session, chiffrée avec le hash de pixis;
  • Le TGT, contenant différentes informations dont les principales sont les suivantes :
    • Le nom de l’utilisateur
    • La période de validité
    • La clé de session générée
    • Le Privilege Attribute Certificate (PAC) qui contient des informations spécifiques sur le client permettant de connaitre ses droits (son ID, les groupes auxquels il appartient, …)

    Le TGT sera chiffré avec la clé du KDC. Ainsi, seul le KDC est en mesure de déchiffrer et lire le contenu de ce ticket.

Réponse KDC

Notons que ce TGT est considéré comme une information publique. Il peut très bien être intercepté pendant la phase d’authentification. Nous verrons dans le paragraphe suivant l’importance de l’authentifiant qui accompagne le TGT quand le client communique avec le KDC.

Le client reçoit alors ces informations. En utilisant son secret, le premier message va être déchiffré afin de récupérer la clé de session nécessaire pour la suite des échanges.

Ticket-Granting Service (TGS)

Maintenant que le client a pu s’authentifier, nous voici dans la situation suivante : Le client possède sa clé ainsi qu’une clé de session limitée dans le temps que seul lui connait, et un TGT chiffré par le KDC qui contient, entre autre, cette même clé de session.

Etat actuel

KRB_TGS_REQ

Si pixis veut utiliser un service, par exemple CIFS sur le serveur \\SERVER01, il va envoyer plusieurs informations au KDC pour que celui-ci lui renvoie un ticket de service.

  • Le TGT;
  • L’identifiant du service qu’il veut utiliser et l’hôte associé, donc CIFS/SERV01 dans cet exemple;
  • Un authenticator, qui est un message contenant son nom, et un timestamp, le tout chiffré avec la clé de session qu’il a en sa possession.

Requête service

Ces informations reçues par le KDC permettent deux choses.

La première est de s’assurer que c’est bien pixis qui fait la demande. Pour cela, le KDC va comparer le contenu du TGT avec le contenu de l’authenticator. Comme seul le KDC peut lire le contenu du TGT, il est certain que ce contenu n’a pas été falsifié. Le KDC va donc lire le contenu du TGT, donc les informations de l’utilisateur qui possède le TGT, mais également la clé de session. Ensuite, il va déchiffrer le contenu de l’authenticator avec la clé de session. Si le déchiffrement fonctionne, et que les données dans l’authenticator correspondent aux données dans le TGT, alors pixis est bien qui il prétend être. En effet, cela assure au KDC que celui qui a fait la requête possède le TGT et a connaissance de la clé de session négociée.

La deuxième est de savoir à quel service pixis veut avoir accès, information qu’il obtient en recevant l’identifiant de ce service.

Voici un schéma qui permet de résumer ce processus de vérification au niveau du KDC :

Process de vérification

KRB_TGS_REP

Maintenant que le KDC a pu vérifier que l’utilisateur était bien pixis, il va lui renvoyer des informations qui lui permettront de faire une demande auprès du service. Ce message est le KRB_TGS_REP. Il est composé des éléments suivants :

  • Un ticket contenant le nom et l’instance du service demandé (CIFS/SERV01), le nom d’utilisateur (pixis), le PAC et une nouvelle clé de session qui est valide uniquement pour pixis voulant discuter avec CIFS sur //SERVER01 pendant un certain temps. Ce ticket est chiffré avec la clé du service en question (donc celle de la machine, puisque le service CIFS tourne sous l’utilisateur machine);
  • La nouvelle clé de session

Ces deux informations (le ticket et la clé de session) sont chiffrées avec la première clé de session, celle qui a été échangée au début entre le KDC et le client.

Ticket pour le service

Le client va recevoir ce paquet, et va pouvoir déchiffrer la première couche pour obtenir la clé de session créée pour la communication avec le service, ainsi que le ticket généré pour l’utilisation de ce service. Ce ticket s’appelle le Ticket-Granting Service (TGS).

Dechiffrement chez le client

Accès au service (AP)

KRB_AP_REQ

pixis va alors générer un nouvel authentifiant qu’il va chiffrer avec cette nouvelle clé de session, et enverra le ticket par la même occasion pour envoyer la requête KRB_AP_REQ au service. C’est le même processus qu’avec le KDC.

message envoyé au service

Le service CIFS reçoit le ticket qu’il peut déchiffrer. Il est certain que celui-ci est valide et authentique puisque seul le KDC est l’autre entité possédant sa clé. Dedans, il trouvera la clé de session qu’il utilisera pour déchiffrer l’authentifiant. En comparant le contenu du ticket de service avec le contenu de l’authentifiant, le service peut être certain de l’authenticité du client, et il peut lui envoyer les informations dont il a besoin.

Vérification côté service

Résumé

C’est un processus relativement complexe, mais une fois que les étapes ont été vues en détails, on comprend mieux l’utilité de chacunes d’elles. Voici un schéma récapitulatif des trois étapes pour un client qui demande un accès à deux services différents (cliquez sur l’image si vous voulez l’agrandir) :

Kerberos

Exemple d’attaque : Unconstrained Delegation

Ce protocole est relativement complexe mais permet de se protéger contre un grand nombre d’attaques. Ainsi, si un attaquant se place sur le réseau et écoute les communications, il ne sera pas en mesure d’extraire quelconque secret. Il pourra trouver le TGT d’un utilisateur, mais il n’aura pas connaissance de la clé de session utilisée pour chiffrer l’authentifiant. Comme nous l’avons vu, les clés sont toujours protégées par un secret déjà partagé entre les différentes parties.

Cependant, ce protocole a été étendu et complexifié pour satisfaire ses utilisateurs qui avaient des besoins très variés. La fonctionnalité “Unconstrained Delegation” est une fonctionnalité qui peut être utile pour un attaquant.

Nous avons expliqué qu’un client pouvait s’authentifier auprès d’un service pour l’utiliser. Cependant, il arrive que ce service ait besoin d’autres informations pour répondre au client. Prenons l’exemple d’un serveur Web. Si le client communique avec le service Web, mais que celui-ci a besoin de trouver des informations dans une base de données, le service Web doit pouvoir s’authentifier auprès de la base de données pour vérifier que l’utilisateur a le droit de récupérer telle ou telle information. Pour cela, il existe un drapeau qui peut être placé sur un service indiquant qu’il peut impersonner un utilisateur. Cela veut dire que si un utilisateur s’authentifie auprès de ce service, ce dernier est en mesure de s’authentifier auprès d’un (ou plusieurs) autre(s) service(s) en se faisant passer pour l’utilisateur.

Deux drapeaux existent alors :

  • Constrained Delegation : Une liste de services auprès desquels le premier service peut s’authentifier est décidée par l’administrateur.
  • Unconstrained Delegation : Ce drapeau indique que le service peut se faire passer pour l’utilisateur lorsqu’il s’authentifie auprès de n’importe quel autre service.

Concrètement, si le drapeau “Unconstrained Delegation” est positionné pour un service, lorsque l’utilisateur s’authentifie auprès du service, il fournira en plus une copie de son TGT au service, copie qui possède le drapeau forwarded, ainsi que la clé de session associée à ce nouveau TGT. Ces deux éléments seront utilisés auprès du KDC pour s’authentifier auprès d’un autre service en tant que l’utilisateur.

Si un attaquant arrive à prendre le contrôle d’une machine sur laquelle tourne un service en “Unconstrained Delegation”, alors il suffit qu’il force un compte à s’authentifier sur ce service pour récupérer le TGT de l’utilisateur et la clé de session. Pour peu que ce soit un administrateur du domaine qui est impersonné, l’attaquant pourra alors effectuer n’importe quelle action de la part de l’utilisateur sur le domaine.

Conclusion

Le protocole Kerberos est très robuste face à un grand nombre d’attaques. Sa conception permet de ne jamais exposer les secrets d’authentification des utilisateurs ou des services.

Cependant, des attaques existent pour relayer des tickets ou demander des tickets pour trouver le mot de passe via une attaque hors-ligne. Un exemple a été présenté de manière succinte dans cet article, cependant nous plongerons un peu plus en détails dans les prochains articles afin de présenter d’autres attaques, telles que celles sur les comptes sans pré-authentification, les SPN placés sur les utilisateurs, les attaques permettant de forcer une authentification de la part d’une machine, le relai d’authentification, etc.


logo
Auteur : Pixis
Créateur du blog, suivez-moi sur twitter ou discord