Def :

https://www.tarlogic.com/blog/how-kerberos-works/#What_is_Kerberos
https://medium.com/identity-beyond-borders/kerberos-explained-3bc2ddb7b0eb
Version détaillée : https://blog.devensys.com/2018/07/18/kerberos-principe-de-fonctionnement/
Kerberos est un protocole d'autorisation, il est principalement et massivement utilisé dans le principe d'authentification AD.
ATTENTION : Kerberos authentifie les utilisateurs pour vérifier leur identité seulement, Kerberos ne donne pas de d'autorisation. En coopération avec un AD il permet bien de faire du AAA.
Exemple :
Le principe de fonctionnement général est simple. L’utilisateur s’authentifie auprès du service d’authentification (le vigile). Celui-ci lui donne un ticket d’accès prouvant qu’il s’est authentifié (un badge). L’utilisateur se rend auprès du service de gestion des tickets. Il demande un accès au service de fichiers par exemple. Grâce au badge donné par le vigile le service de ticket sait que l’utilisateur s’est bien authentifié. Il va donc lui remettre un ticket d’accès au service de fichier. L’utilisateur peut maintenant aller voir le service de fichier avec son ticket. Le service lui donnera accès aux ressources correspondantes à ses autorisations.

Fonctionnement :

Kerberos est composé de nombreux modules, qui fonctionnent ensembles :

Transport Layer :

Kerberos, utilise UDP ou TCP comme protocole de transport. Ce protocole ne chiffre pas les communications, et donc Kerberos doit s'en charger.

Ports :

• UDP : 88
• TCP : 88

Agents :

3 agents fonctionnent en symbiose pour fournir l'authentification Kerberos.

• Client ou utilisateur : la personne qui veut accéder au service d'authentification
• AP : application server, qui offre le service demandé par l'utilisateur
• KDC : Key Distribution Center, est le service principal de Kerberos qui fournit les ticket d'authentification. Cela fonctionne grâce à l'AS (authentification service), qui fournit les tickets.

Encryption Keys :

Pour protéger les échanges de Kerberos plusieurs moyens de signature et de chiffrement existent :

• KDC key ou krbtgt key : ce qui est un dérivé de krbtgt avec des hash NTLM.
  https://www.tarlogic.com/cybersecurity-glossary/krbtgt/
• User Key : qui est un dérivé des hash NTLM des utilisateurs
• Service Key : dérivé des hash NTLM du propriétaire du service. Ça peut être un utilisateur ou un PC
• Session Key : négotié entre l'utilisateur et le KDC (service d'authentification)
• Service Session Key : pour être utilisé entre un utilisateur et un service

Tickets :

La structure principale gérée par Kerberos sont les tickets. Les tickets sont délivrés aux utilisateurs pour qu'ils puissent faire des action dans le royaume Kerberos (Kerberos Realm).
Il existe deux types de tickets :

• TGS : Ticket Granting Service est le ticket qui peut être utiliser pour authentifier contre un service. La service Key chiffre tout ça.
• TGT : Ticket Granting Ticket est le ticket présenté par KDC pour faire des requêtes TGS. Chiffré avec la clé KDC.

PAC :

https://blog.netwrix.com/2023/01/10/what-is-the-kerberos-pac/Un Privilege Attribute Certificate est inclus dans quasiment tous les tickets. Le PAC permet de gérer les autorisation dans les tickets et est signé avec la clé KDC.
Le PAC n'est généralement pas vérifié au niveau de sa validité. Les services vérifient uniquement la signature dans le PAC sans vérifier sa validité.
Le PAC contient de nombreuses informations sur les droits de l'utilisateur.
Un client peut vérifier l'inclusion d'un PAC dans un ticket en spécifiant :

KERB-PA-PAC-REQUEST

De nombreuses attaques existent sur le PAC pour faire une escalade de privilèges.

Messages :

Kerberos utilise de nombreux messages, les principaux sont les suivants :

• KRB_AS_REQ : Utilisé pour faire des requêtes TGT au KDC
• KRB_AS_REP : Utilisé pour distribuer le TGT au KDC
• KRB_TGS_REQ : Utilisé pour faire des requêtes TGS au KDC en utilisant des TGT
• KRB_TGS_REP : Utilisé pour délivrer un TGS par le KDC
• KRB_AP_REQ : Utilisé pour authentifier un utilisateur contre un service avec le TGS
• KRB_AP_REP : Utiliser pour identifier une identité contre un utilisateur (Optionnel)
• KRB_ERROR : Un message de communication de erreurs

Processus d'Authentification :

Processus détaillé :
https://blog.devensys.com/2018/07/18/kerberos-principe-de-fonctionnement/
Pour effectuer une authentification un échange de nombreux messages est nécessaire.
On veut d'abord un TGT, puis demander un TGS. Une fois obtenu on peut s'authentifier avec un time stamp pour sécuriser le moment de la connexion.

KRB_AS_REQ :

On doit comme préciser obtenir un TGT du KDC (Key Distribution Center). Pour cela, on transmet une requête KRB_AS_REQ, qui possède les champs suivants :

• Un timestamp avec la clé client, pour authentifier l'utilisateur et se protéger des replays attacks
• Username pour l'utilisateur authentifier
• Le service SPN associé avec le Compte Krbtgt
• Un Nonce généré par l'utilisateur
  Le timestamp est seulement nécessaire si il y a une préauthentification. Ce qui est courant sauf si le flag DONT_REQ_PREAUTH
  Le User hash doit être formé (spéculatif) à partir des identifiants de l'utilisateurs (par exemple les hash ntlm)

KRB_AS_REP :

Une fois la première requête reçue, le KDC vérifie l'identité de l'utilisateur en déchiffrant le timstamp. Si la demande est correcte alors on envoie la réponse KRB_AS_REP.
Les données du KRB_AS_REP sont les suivantes :

• Username
• TGT
  • Username
  • Session Key
  • Expiration date of TGT
  • PAC avec des privilèges utilisateurs signés par le KDC
• Données chiffrées avec la clé utilisateur :
  • Session Key
  • Expiration date of TGT
  • User nonce pour empêcher les attaques replays (une sorte de timestamp pour la communication en cours)
    Cet échange donne donc un TGT à l'utilisateur qui va pouvoir faire une requête pour le TGS.

KRB_TGS_REQ

Ce message sert pour obtenir un TGS qui doit être envoyé à un KDC.
Ce message inclut :

• Donnée chiffrée avec la clé de session (du message précédent):
  • Username
  • Timestamp
• TGT
• SPN du service demandé
• Nonce de l'utilisateur

KRB_TGS_REP :

Une fois avoir reçu un message KRB_TGS_REQ correct, on reçoit une REP qui nous donne le TGS.
Le message KRB_TGS_REP contient :

• Username
• TGS qui contient :
  • Service session key
  • Username
  • Expiration date tu TGS
  • PAC avec les privilèges utilisateurs signés par le KDC
• Données chiffrées la clé de session :
  • Service session key
  • Expiration date of TGS
  • User nonce

KRB_AP_REQ :

L'utilisateur à maintenat un TGS valide, l'utilisateur doit maintenant envoyer la requête au service dont l'utilisateur demande l'accès.
Ce message inclut :

• TGS
• Données chiffrés avec la clé de session :
  • Username
  • Timestamp
    Si les droits de l'utilisateur permettent de se connecter au service alors c'est bon. Parfois, l'AP vérifie le PAC contre le KDC dans une nouvelle transmission.

Avec ces données il faut maintenant comprendre les attaques possibles sur le Kerberos de l'AD : Kerberos exploitation.