Kerberos est le protocole d’authentification en Active Directory. Ce protocole sert à avoir accès aux services de l’AD. Il est divisé en plusieurs étapes:
Vous pouvez le voir comme un parc d’attraction vraiment chelou: vous avez plusieurs stands un peu partout dans le parc qui vous permettent d’avoir un ticket pour accéder à des tickets pour les attractions. Donc vous revenez au même stand de tickets pour demander un ticket pour une attraction grâce au ticket qu’on vous a donné juste avant. On vous donne un nouveau ticket pour accéderà l’attraction: vous vous hâtez avant qu’il ne soit plus valide, vous le donnez au mec qui gère l’attraction, il le vérifie et enfin vous laisse accéder à l’attraction.
Ces étapes sont en réalités définies comme ceci:
Source: Obtaining a Service Ticket
Source: Kerberos Network Authentication Service (V5) Synopsis
Pour référence à cet article, munissez vous de la RFC 4120
La phase AS de Kerberos permet de s’authentifier auprès du KDC/DC. Ensuite, le KDC/DC offre au client un TGT (Ticket-Granting-Ticket) et une clef de session. C’est du TCP donc on a le classique “3 handshakes” SYN-SYNACK-ACK sur le port 88 (TCP/88).
En premier lieu, le client se connecte sur le réseau en tapant sont login et son password. Le client Kerberos sur la machine de l’utilisateur convertit le mot de passe utilisateur en clef de chiffrement symétrique.
On peut aussi utiliser un clef publique en guise de mot de passe, c’est au autre mécanisme d’authentification comme pkinit (RFC 4556) (donc par une clef PKI)
Votre client Kerberos envoie donc une demande de TGT au KDC avec comme payload:
| Champ | Description |
|---|---|
| pvno | Version du protocole Kerberos, actuellement 5 |
| msg-type | Type de message, ici KRB_AS_REQ |
| kdc-options | Flags |
| cname | Client/User Principal Name (CPN / UPN)) (exemple: utilisateur@domain.com |
| realm | Kerberos Principal Name (KPM) / Windows domain name |
| sname | Service Principal Name* (SPN), ici “krbtgt” |
| from | Timestamp, c’est le starttime dont on parle dans la RFC |
| till | Temps d’expiration de KRB_AS_REQ |
| rtime | Temps d’expiration pour un ticket RENEWABLE |
| nonce | Nombre random de type uint32_t généré par le client |
| etype | Encryption Types: c’est les methodes de chiffrement acceptées par notre client |
| addresses | Adresse du client, contient d’autres adresses si on passe par un proxy |
Source: Kerberos Authentication - HackTricks
Le serveur d’authentification (KDC) reçoit donc les données. Il vérifie le cname et en extrait les clefs respectives, car oui il peut y avoir plusieurs clefs. Dans ce cas il prend celles définient par le champ etype de KRB_AS_REQ pour sélectionner la méthode de chiffrement à utiliser pour protéger une partie de KRB_AS_REP. Si il y a plusieurs valeurs dans etype, on prend la première valide.
Il est à noter que si votre Kerberos en AD utilise un système de chiffrement symétrique faible, il sera faillible à plusieurs attaques informatique. Vous avez plusieurs méthodes de chiffrement disponibles:
Le KDC renvoie plusieurs éléments de réponse:
En plus détaillé, ça fait:
| Champ | Description |
|---|---|
| padata | Pre-Authentication Data |
| crealm | Contient le nom du realm où le client s’est auth initialement |
| ticket | Structure de donnée pour un ticket/authenticator |
| tkt-vno | Version du format du ticket |
| realm | Quel realm a fournit le ticket |
| enc-part | Encrypted Part, chiffré symétriquement et uniquement lisible par le KDC |
| key | Clef de session pour être passée du Kerberos à l’AP et au Client |
| transited | Kerberos realms qui ont participé à l’authentification du client |
| authtime | Timestamp de l’auth initiale |
| starttime | Timestamp à partir duquel le ticket est valide |
| endtime | Timestamp à partir duquel le ticket est invalide |
| renew-till | Si RENEWABLE. Indique le maximum endtime pour un renouvellement, peut-être considéré comme le endtime absolu |
| caddr | Adresses qui peuvent utiliser le ticket, si vide, n’importe quelle adresse peut utiliser le ticket |
| authorization-data | Le PAC, c’est la liste des restrictions du ticket |
| enc-part | Chiffré symétriquement et lisible par KDC et Client |
| last-req | Timestamp de la dernière requête pour un TGT dans un contexte spécifique |
| lr-type | last-req type, aide pour interpréter lr-value (contexte) |
| lr-value | last-req value, timestamp |
| key-expiration | Timestamp à partir duquel la clef secrète du client expire |
Source: Kerberos Authentication - HackTricks
Maintenant que notre client a son TGT avec ses droits inscrits dessus, il peut demander au KDC d’accéder aux services du réseau en demandant un TGS (Un ticket qui donne accès à un service) sous la forme d’un couple Clef de session/TGS.
Le client Kerberos de l’utilisateur demande donc au KDC sous la forme d’un KRB_TGS_REQ un TGS. Grosso merdo, le message consiste à donner :
Définition de l’authenticator
| Champ | Description |
|---|---|
| authenticator | Chiffré avec la clef de session |
| authenticator-vno | Version de l’authenticator |
| ck-sum | checksum |
| cusec | Client USeconds (micro seconds) du timestamp |
| ctime | Timestamp du client |
| subkey | Clef a utiliser pour KRB_TGS_REP, si vide: clef de session du TGT |
| seq-number | Détecter les requêtes rejouées, agit un peu comme l’ACK de TCP |
| authorization-data | restrictions additionnelles par rapport à celles du TGT |
Ce qui change dans la requête c’est le flag ENC-TKT-IN-SKEY qui permet de dire au KDC qu’on ajoute le TGT à la requête dans le champ additional-tickets, ainsi qu’un champ optionnel enc-authorization-data.
| Champ | Description |
|---|---|
| enc-authorization-data | PAC désiré, chiffré avec la clef de session (sinon clef TGT) |
| additional-tickets | Tickets additionnels à la requête |
Source: Kerberos Authentication - HackTricks
Le KDC reçoit le KRB_TGS_REQ. Il est processé pareillement que KRB_AS_REQ, mais avec plus de checks, ce qui est logique.. s’il y a plus de données, il y a plus de checks à faire. Par exemple on va comparer le TGT et l’Authenticator.. histoire de voir si le TGT appartient bien au client, donc on va comparer cname et key. Ensuite on check si le client a bien le droit d’accéder au sname grâce au PAC (authorization-data du ticket TGT)
La requête détaillée se trouve ci-dessous:
| Champ | Description |
|---|---|
| ticket:enc-part | Chiffré symétriquement et lisible par KDC et le service/AP |
| enc-part | Chiffré symétriquement et lisible par KDC et le Client |
C’est son ticket d’entrée pour rentrer dans le service ! Hooray \o/ !
Source: Kerberos Authentication - HackTricks
On y est ! Désormais le but est de créer une communication sécursiée avec le service et nous. Le service pourra déchiffrer notre TGS grâce à sa propre clef. On rappelle que le TGS permet d’authentifier le client sur le service.
Notre client doit faire le premier par vers le service. Par conséquent, grâce à la KRB_TGS_REP nous avons accès à la clef de session du service. On va donc générer nos nouveaux authentifiant pour le service: un authenticator chiffré avec la clef de session du service. On enverra à la suite notre TGS qu’on ne peut pas lire (mais le service oui).
| Champ | Description |
|---|---|
| authenticator | Chiffré avec la clef de session du service |
Source: Kerberos Authentication - HackTricks
Enfin, si tout est bon, c’est-à-dire après comparaison entre le TGS et l’authenticator, le client peut accéder au service. Attention cependant, le service peut demander confirmation du PAC au KDC. Dans le cas où le bit mutual-required(2) est mis dans ap-options, le service renverra bien un KRB_AP_REP.
Kerberos en Active Directory (Hackndo) Kerberos Authentication Obtaining a Service Ticket Authentication Service Exchange Kerberos Network Authentication Service (V5) Synopsis Kerberos Explained Kerberos (protocole) Are there any reasons for Kerberos being based on symmetric cryptography? Kerberos authentication explained RFC 4120 RFC 4120 FR