Go to content

Kerberos : Le KRBTGT

Dans la mythologie, Kerberos (également connu sous le nom de Cerberus) est un grand chien à trois têtes avec une queue de serpent. Doté d’un très mauvais caractère, il garde l’entrée des Enfers pour empêcher les âmes de s’échapper. Dans le domaine informatique, Kerberos est le protocole d’authentification de réseau informatique initialement développé dans les années 1980 par les informaticiens du Massachusetts Institute of Technology (MIT). L’idée derrière Kerberos est d’authentifier les utilisateurs tout en empêchant l’envoi de mots de passe en clair sur le réseau.

Initialement, il a été conçu pour le projet éducatif du MIT appeler Project Athéna, mais aujourd’hui, il prend en charge un large éventail de fonctions, y compris les implémentations d’authentification unique (SSO), et sert de protocole d’authentification de référence pour les sites Web. C’est désormais la technologie d’authentification par défaut de Microsoft Windows. Des implémentations Kerberos existent également pour d’autres systèmes d’exploitation tels que Apple OS, FreeBSD, UNIX et Linux.

Les trois têtes de Kerberos représentent le client, le serveur et le centre de distribution de clés (KDC). Il est largement utilisé et éprouvé et depuis un certain temps, ce qui le rend efficace en termes de sécurité. 

Dans cet article, nous discuterons de l’attaque de type Golden ticket. Mais avant cela, nous approfondirons le fonctionnement de l’authentification Kerberos.

Kerberos, NTLM ?

NTLM (New technology LAN Manager) est un protocole d’authentification propriétaire de Microsoft. Il est basé sur un procédé cryptographique à clé symétrique et a besoin de serveurs de ressources pour fournir l’authentification, l’intégrité et la confidentialité aux utilisateurs. NTLM ne prend pas en charge la délégation d’authentification et l’authentification à deux facteurs.

Kerberos présente un certain nombre d’avantages par rapport à l’authentification NTLM, notamment en ce qui concerne l’utilisation de l’authentification mutuelle. L’authentification mutuelle dans Kerberos permet une authentification bidirectionnelle, de sorte qu’un serveur peut authentifier un client, mais un client peut également authentifier un serveur. Ainsi, l’authentification mutuelle garantit non seulement qu’un client autorisé essaie d’accéder au réseau, mais également qu’un serveur autorisé est celui qui répond à la demande du client. Kerberos est le seul protocole d’authentification à utiliser des tickets qui prouvent l’identité d’un utilisateur à un serveur donné sans envoyer de mots de passe sur le réseau ou mettre en cache les mots de passe sur le disque dur de l’utilisateur local.

NTLMKerberos
Ne prend pas en charge la délégation d’authentificationPrend en charge la délégation d’authentification dans les applications à plusieurs niveaux
Utilise un mécanisme de « stimulation/réponse »Utilise un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets
Protocole d’authentification propriétaire de MicrosoftOpen source et propose des services gratuits
Ne gère pas l’authentification mutuelle.Gère l’authentification mutuelle.
Moins sécurisé par rapport à Kerberos.Offre une sécurité élevée
Une connexion à deux facteurs par l’utilisation de cartes à puce n’est pas possible par les protocoles NTLMUne procédure de connexion à deux facteurs à l’aide d’une carte à puce est possible par le protocole Kerberos.

 

Description du protocole

Kerberos est un protocole d’authentification conçu pour fournir une authentification unifiée pour les applications client/serveur sur les réseaux classés comme non sécurisés en utilisant un chiffrement symétrique. Les algorithmes de chiffrement sont publics (AES, DES, 3DES…), toute la sécurité du système repose sur la confidentialité de la clé de chiffrement.

Pour faciliter la gestion d’un tel système, l’authentification repose sur un tiers de confiance, le Centre de distribution de clés (KDC). Le KDC est séparé en deux services :

  • AS (Authentication Service) : il s’agit du service sur lequel l’utilisateur s’authentifie. Il délivre un TGT (Ticket Granting Ticket) en cas d’authentification réussie. Ce ticket est en fait une demande d’accès au TGS.
  • TGS (Ticket Granting Service) : il s’agit d’un service qui fournit les tickets d’accès aux différents services du réseau.

Grâce à ce système de tickets, il est beaucoup plus difficile pour les attaquants d’infiltrer votre réseau. Mais comme tous les protocoles il n’est pas infaillible, et afin de se défendre, il faut d’abord comprendre le fonctionnement de l’authentification Kerberos.

Principes de fonctionnement

Tout d’abord, il existe plusieurs acteurs dans un scénario d’authentification via Kerberos :

Agents :

Les agents qui travaillent ensemble pour fournir l’authentification dans Kerberos sont :

  • Le client qui souhaite s’authentifier auprès d’un serveur
  • L’AP (Application Server) qui offre le service requis par l’utilisateur.
  • Le KDC, un tiers de confiance.

Le tiers de confiance (KDC) est responsable de l’émission des tickets, installé sur le DC (Domain Controller). Il est pris en charge par l’AS (Authentication Service), qui émet les TGT et il connaît également tous les secrets des entités de son royaume de confiance Kerberos (appelé realm).

Tickets :

TGT est un ticket particulier permettant à l’utilisateur d’obtenir des tickets TGS.

TGS est le ticket que l’utilisateur peut utiliser pour s’authentifier auprès d’un service.

PAC (Privilege Attribute Certificate) :

PAC est une structure incluse dans presque tous les tickets. Cette structure contient des informations telles que les identificateurs de sécurité, l’appartenance à un groupe, les informations de profil utilisateur et les informations autour du mot de passe (PWD Last Set, PWD Can Change, etc…). Cette structure est signée avec la clé KDC, et la vérification de la signature de la structure PAC est systématiquement réalisée lors de la réception d’un ticket Kerberos afin d’empêcher l’usurpation de PAC.

Processus d’authentification

Dans cette section, la séquence des messages pour effectuer l’authentification sera étudiée, à partir d’un utilisateur sans ticket, jusqu’à l’authentification   au service souhaité.

 

L’authentification d’un client auprès d’un serveur va s’opérer en trois phases auprès de trois services distincts

 

Phase A

1) Demande d’obtention d’un ticket TGT 

Cette étape est l’authentification du client auprès du service d’Authentication (AS). Le client envoie une demande KRB_AS_REQ au KDC. Ce message, transmis en clair, contient :

  • L’identité de l’utilisateur.
  • Le SPN, nom du service auquel il souhaite accéder.
  • La durée de vie du ticket ainsi que la liste des machines où le ticket peut être utilisé.
  • Un timestamp chiffré avec la clé du client, pour authentifier l’utilisateur et empêcher les attaques par rejeu.

 

2) Réception d’un ticket TGT

Le serveur va chercher le mot de passe du client dans sa base de données pour déchiffrer le message. Si la demande est approuvée, le KDC ou plus précisément l’AS générera un ticket TGT et une clé de session entre l’utilisateur et le TGS et qui seront renvoyé au client dans le cadre de la réponse KRB_AS_REP.  Le TGT est chiffré avec la clé secrète du KDC (KKDC) et n’est donc pas modifiable par l’utilisateur.

KRB_AS_REP inclut les informations suivantes :

  • Nom d’utilisateur
  • TGT, qui comprend :
    • Nom d’utilisateur
    • Clé de session KSTGS
    • Date d’expiration du TGT
    • PAC avec privilèges d’utilisateur, signé par KDC
  • Certaines données sont chiffrées avec la clé secrète de l’utilisateur, qui comprennent :
    • Clé de session KSTGS
    • Date d’expiration du TGT
    • Nonce de l’utilisateur, pour empêcher les attaques par rejeu

NB : Nonce est un nombre arbitraire destiné à être utilisé une seule fois. Il est  souvent émis dans un protocole d’authentification afin d’éviter que les anciennes communications ne peuvent pas être réutilisées dans des attaques par rejeu.

 

La clé de session KSTGS connue uniquement par l’AS et l’utilisateur car elle est chiffrée avec la clé secrète de l’utilisateur. Cette clé de session servira pour les échanges ultérieurs avec le TGS.

La clé secrète de l’utilisateur n’est connue que par le client et le serveur (AS) parce que c’est lui qui gère la base de données utilisateur. Cela veut dire que le mot de passe n’est pas transmis à travers le réseau.

 

Phase B

3) Demande d’obtention d’un ticket TGS

Le client envoie le TGT chiffré au serveur d’émission de tickets (TGS) demandant l’accès au serveur.

KRB_TGS_REQ inclut les informations suivantes :

  • Données chiffrées avec clé de session KSTGS
    • Nom d’utilisateur
    • Timestamp
  • TGT
  • SPN (Service Principal Name) du service demandé
  • Nonce généré par l’utilisateur

 

4) Réception d’un ticket TGS

Le TGS déchiffre le ticket TGT, récupère la clé de session KSTGS pour déchiffrer le timestamp et nom de l’utilisateur. Il compare le contenu avec les informations contenues dans le ticket TGT et si tout concorde, l’utilisateur est authentifié. Le KDC va retourner un ticket TGS et une nouvelle clé de session.

KRB_TGS_REP inclut les informations suivantes :

  • Nom d’utilisateur
  • TGS, qui contient :
    • Une nouvelle clé de session de service
    • Nom d’utilisateur
    • Date d’expiration de TGS
    • PAC avec privilèges d’utilisateur, signé par KDC
  • Données chiffrées avec la clé de session KSTGS :
    • Une nouvelle Clé de session de service
    • Date d’expiration de TGS
    • Nonce de l’utilisateur, pour empêcher les attaques par rejeu

 

Le client va recevoir ce paquet, et va pouvoir déchiffrer avec la clé de session KSTGS 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 TGS.

 

Phase C

5) Demande d’accès à L’AP (Serveur d’application)

Le client est prêt à s’authentifier auprès du service. Le client va générer un nouvel authentifiant qu’il va chiffrer avec cette nouvelle clé de session et envoie le ticket de service au serveur d’application.

KRB_AP_REQ inclut les informations suivantes :

  • TGS
  • Données chiffrées avec clé de session de service :
    • Nom d’utilisateur
    • Timestamp, pour éviter les attaques de relecture

Le serveur d’application déchiffre le ticket avec la clé partagée avec le TGS validant ainsi son authenticité. Dans ce ticket, se trouve la clé de session qui sera utilisée pour déchiffrer le nom d’utilisateur et le timestamp.

6) Demande de Vérification du PAC (facultatif)

KERB_VERIFY_PAC

L’application déchiffrer le message et vérifie le PAC à partir du KDC pour identifier le privilège de l’utilisateur.

7) Réponse de la vérification du PAC par le KDC (facultatif)

Le KDC vérifie les privilèges de l’utilisateur pour l’application en question et renvoi la réponse à l’application.

8) Réponse à la demande d’accès à l’AP

KRB_AP_REP

Si une authentification mutuelle est nécessaire, elle répondra à l’utilisateur avec un message KRB_AP_REP. Le client déchiffre le message d’authentification du serveur avec la clé de session qu’il partage avec le serveur et compare l’heure renvoyée par le service avec l’heure dans son message d’authentification d’origine. S’ils correspondent, le client est assuré que le service est authentique et la connexion se poursuit.

Conclusion

Kerberos est un protocole de sécurité de réseau informatique qui authentifie les demandes de service entre deux hôtes de confiance ou plus sur un réseau non approuvé, comme Internet. Il utilise la cryptographie à clé secrète et un tiers de confiance pour authentifier les applications client-serveur et vérifier l’identité des utilisateurs. Les utilisateurs, les machines et les services qui utilisent Kerberos dépendent uniquement du KDC, qui fonctionne comme un processus unique offrant deux fonctions : l’authentification et l’octroi de tickets.

Malgré cela, Kerberos reste le meilleur protocole d’authentification sécurisé disponible aujourd’hui. Il est suffisamment flexible pour adopter de nouveaux algorithmes de chiffrement en fonction des évolutions de kerberos afin d’en renforcer la fiabilité et la sécurité. Mais, des contournements du protocole reste toujours possible comme les golden tickets et silver tickets. Les attaquants ont eu l’occasion au fil des ans de trouver des moyens de le contourner, comme par exemple en forgeant des tickets en utilisant des outils comme Mimikatz.