Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/kerberos-authentication.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

12 KiB
Raw Blame History

Authentification Kerberos

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Ces informations ont été extraites de l'article : https://www.tarlogic.com/en/blog/how-kerberos-works/

Kerberos (I) : Comment fonctionne Kerberos ? - Théorie

20 - MAR - 2019 - ELOY PÉREZ

L'objectif de cette série d'articles est de clarifier le fonctionnement de Kerberos, plutôt que de simplement présenter les attaques. En effet, il n'est pas toujours clair pourquoi certaines techniques fonctionnent ou non. Cette connaissance permet de savoir quand utiliser l'une de ces attaques lors d'un test de pénétration.

Par conséquent, après un long parcours de plongée dans la documentation et plusieurs articles sur le sujet, nous avons essayé de résumer dans cet article tous les détails importants que tout auditeur devrait connaître pour comprendre comment tirer parti du protocole Kerberos.

Dans ce premier article, seule la fonctionnalité de base sera discutée. Dans les articles suivants, nous verrons comment effectuer les attaques et comment fonctionnent les aspects les plus complexes, tels que la délégation.

Si vous avez des doutes sur le sujet qui ne sont pas bien expliqués, n'hésitez pas à laisser un commentaire ou une question à ce sujet. Maintenant, passons au sujet.

Qu'est-ce que Kerberos ?

Tout d'abord, Kerberos est un protocole d'authentification, pas d'autorisation. En d'autres termes, il permet d'identifier chaque utilisateur, qui fournit un mot de passe secret, mais il ne valide pas à quelles ressources ou services cet utilisateur peut accéder.

Kerberos est utilisé dans Active Directory. Dans cette plateforme, Kerberos fournit des informations sur les privilèges de chaque utilisateur, mais il incombe à chaque service de déterminer si l'utilisateur a accès à ses ressources.

Éléments de Kerberos

Dans cette section, plusieurs composants de l'environnement Kerberos seront étudiés.

Couche de transport

Kerberos utilise soit UDP soit TCP comme protocole de transport, qui envoie des données en clair. Pour cette raison, Kerberos est responsable de la fourniture de chiffrement.

Les ports utilisés par Kerberos sont UDP/88 et TCP/88, qui doivent être écoutés dans le KDC (expliqué dans la section suivante).

Agents

Plusieurs agents travaillent ensemble pour fournir l'authentification dans Kerberos. Ce sont les suivants :

  • Client ou utilisateur qui veut accéder au service.
  • AP (Application Server) qui offre le service requis par l'utilisateur.
  • KDC (Key Distribution Center), le service principal de Kerberos, responsable de l'émission des tickets, installé sur le DC (Domain Controller). Il est soutenu par le AS (Authentication Service), qui émet les TGT.

Clés de chiffrement

Il existe plusieurs structures gérées par Kerberos, telles que les tickets. Beaucoup de ces structures sont chiffrées ou signées afin d'empêcher toute altération par des tiers. Ces clés sont les suivantes :

  • Clé KDC ou krbtgt qui est dérivée du hachage NTLM du compte krbtgt.
  • Clé utilisateur qui est dérivée du hachage NTLM de l'utilisateur.
  • Clé de service qui est dérivée du hachage NTLM du propriétaire du service, qui peut être un compte utilisateur ou un compte d'ordinateur.
  • Clé de session qui est négociée entre l'utilisateur et le KDC.
  • Clé de session de service à utiliser entre l'utilisateur et le service.

Tickets

Les principales structures gérées par Kerberos sont les tickets. Ces tickets sont remis aux utilisateurs pour être utilisés par eux pour effectuer plusieurs actions dans le royaume Kerberos. Il y en a 2 types :

  • Le TGS (Ticket Granting Service) est le ticket que l'utilisateur peut utiliser pour s'authentifier auprès d'un service. Il est chiffré avec la clé de service.
  • Le TGT (Ticket Granting Ticket) est le ticket présenté au KDC pour demander des TGS. Il est chiffré avec la clé KDC.

PAC

Le PAC (Privilege Attribute Certificate) est une structure incluse dans presque tous les tickets. Cette structure contient les privilèges de l'utilisateur et est signée avec la clé KDC.

Il est possible pour les services de vérifier le PAC en communiquant avec le KDC, bien que cela n'arrive pas souvent. Néanmoins, la vérification du PAC consiste à vérifier uniquement sa signature, sans inspecter si les privilèges à l'intérieur du PAC sont corrects.

De plus, un client peut éviter l'inclusion du PAC à l'intérieur du ticket en le spécifiant dans le champ KERB-PA-PAC-REQUEST de la demande de ticket.

Messages

Kerberos utilise différents types de messages. Les plus intéressants sont les suivants :

  • KRB_AS_REQ : Utilisé pour demander le TGT à KDC.
  • KRB_AS_REP : Utilisé pour remettre le TGT par KDC.
  • KRB_TGS_REQ : Utilisé pour demander le TGS à KDC, en utilisant le TGT.
  • KRB_TGS_REP : Utilisé pour remettre le TGS par KDC.
  • KRB_AP_REQ : Utilisé pour authentifier un utilisateur auprès d'un service, en utilisant le TGS.
  • KRB_AP_REP : (Optionnel) Utilisé par le service pour s'identifier auprès de l'utilisateur.
  • KRB_ERROR : Message pour communiquer les conditions d'erreur.

De plus, même s'il ne fait pas partie de Kerberos, mais de NRPC, l'AP pourrait éventuellement utiliser le message KERB_VERIFY_PAC_REQUEST pour envoyer au KDC la signature de PAC, et vérifier si elle est correcte.

Ci-dessous est présenté un résumé de la séquence de messages pour effectuer l'authentification

Résumé des messages Kerberos

Processus d'authentification

Dans cette section, la séquence de messages pour effectuer l'authentification sera étudiée, en partant d'un utilisateur sans tickets, jusqu'à être authentifié contre le service désiré.

KRB_AS_REQ

Tout d'abord, l'utilisateur doit obtenir un TGT du KDC. Pour ce faire, un KRB_AS_REQ doit être envoyé :

Schéma de message KRB_AS_REQ

KRB_AS_REQ a, entre autres, les champs suivants :

  • Un horodatage
  • Un Nonce généré par l'utilisateur

Note : le timestamp chiffré n'est nécessaire que si l'utilisateur exige une pré-authentification, ce qui est courant, sauf si le drapeau DONT_REQ_PREAUTH est défini dans le compte utilisateur.

KRB_AS_REP

Après avoir reçu la demande, le KDC vérifie l'identité de l'utilisateur en déchiffrant le timestamp. Si le message est correct, il doit alors répondre avec un KRB_AS_REP :

Schéma de message KRB_AS_REP

KRB_AS_REP inclut les informations suivantes :

  • Nom d'utilisateur
  • TGT, qui inclut :
    • Nom d'utilisateur
    • Clé de session
    • Date d'expiration du TGT
    • PAC avec les privilèges de l'utilisateur, signé par le KDC
  • Certaines données chiffrées avec la clé de l'utilisateur, qui incluent :
    • Clé de session
    • Date d'expiration du TGT
    • Nonce de l'utilisateur, pour éviter les attaques de rejeu

Une fois terminé, l'utilisateur a déjà le TGT, qui peut être utilisé pour demander des TGS, et ensuite accéder aux services.

KRB_TGS_REQ

Pour demander un TGS, un message KRB_TGS_REQ doit être envoyé au KDC :

Schéma de message KRB_TGS_REQ

KRB_TGS_REQ inclut :

  • Données chiffrées avec la clé de session :
    • Nom d'utilisateur
    • Horodatage
  • TGT
  • SPN du service demandé
  • Nonce généré par l'utilisateur

KRB_TGS_REP

Après avoir reçu le message KRB_TGS_REQ, le KDC renvoie un TGS dans KRB_TGS_REP :

Schéma de message KRB_TGS_REP

KRB_TGS_REP inclut :

  • Nom d'utilisateur
  • TGS, qui contient :
    • Clé de session du service
    • Nom d'utilisateur
    • Date d'expiration du TGS
    • PAC avec les privilèges de l'utilisateur, signé par le KDC
  • Données chiffrées avec la clé de session :
    • Clé de session du service
    • Date d'expiration du TGS
    • Nonce de l'utilisateur, pour éviter les attaques de rejeu

KRB_AP_REQ

Pour finir, si tout s'est bien passé, l'utilisateur dispose déjà d'un TGS valide pour interagir avec le service. Pour l'utiliser, l'utilisateur doit envoyer un message KRB_AP_REQ à l'AP :

Schéma de message KRB_AP_REQ

KRB_AP_REQ inclut :

  • TGS
  • Données chiffrées avec la clé de session du service :
    • Nom d'utilisateur
    • Horodatage, pour éviter les attaques de rejeu

Après cela, si les privilèges de l'utilisateur sont corrects, il peut accéder au service. Si c'est le cas, ce qui n'arrive pas habituellement, l'AP vérifiera le PAC contre le KDC. Et aussi, si une authentification mutuelle est nécessaire, il répondra à l'utilisateur avec un message KRB_AP_REP.

Références