Exploration du protocole KERBEROS – Déchiffrer le PAC

Posted On 7 juillet 2018

Rappel concernant le protocole Kerberos

L’authentification a lieu en 3 phases (ou sous-protocoles) chacune composées d’une demande et d’une réponse correspondante comme ci dessous:
Phase A: Authentication Service (AS): 1 fois par session de logon
1. KRB_AS_REQ: Requête au contrôleur de domaine (KDC) pour l’obtention d’un TGT (Ticket-Granting Ticket)
2. KRB_AS_REP: Le contrôleur de domaine retourne un TGT et une clé de session pour communiquer avec le KDC.

Phase B: Ticket-Granting Service (TGS): 1 fois par serveur de ressource
3. KRB_TGS_REQ: Requête au contrôleur de domaine (KDC) pour l’obtention d’un TGS (Ticket-Granting Service) pour accéder à un service cible. Cette requête se compose du « TGT » et d’un « authenticator » contenant l’ID de l’utilisateur et l’horodatage actuel chiffré à l’aide de la clé de session partagée entre le client et le KDC qui doivent s’authentifier.
4. KRB_TGS_REP: Le contrôleur de domaine retourne un TGS et une clé de session.

Phase C: Client/Server Authentication (AP): 1 fois par session sur un serveur
5. KRB_AP_REQ: Le ticket acquis à l’étape B est envoyé avec un « authenticator » au serveur de ressources / service pour demander un accès.
6. KRB_AP_REP: Le serveur répond éventuellement au client avec un autre « authenticator » pour que le client authentifie le serveur.

Le « ticket » Kerberos

En simplifiant au maximum, le ticket Kerberos contient des informations chiffrées et non chiffrées.
Certaines sont chiffrées par la clé Kc (clé dérivée du hash du mot de passe du compte du client) d’autres par Ks (clé dérivée du hash du mot de passe du compte de la ressource) ou encore par Kkdc (clé dérivée du hash du mot de passe du compte krbtgt). Enfin nous pouvons trouver des informations chiffrées par une clé de session partagée entre le Client et le KDC…

• Généralement, la partie non chiffrée d’un ticket contient:
  – Le nom du domaine Windows (domaine) dans lequel ce ticket a été émis.
  – Le nom du service principal que ce ticket identifie.
• La partie chiffrée du ticket contient un peu plus d’informations:
  – Divers drapeaux: Ticket Management / Impersonation / Transited : Cross-Realm Flags
  – Clé de cryptage (appelée clé de session)
  – Copies chiffrées du nom principal et du domaine de l’utilisateur
  – Les heures de début et de fin de validité du ticket
  – Les adresses d’hôte identifiant le système de l’utilisateur
  – Les données d’autorisation de l’utilisateur (PAC), généralement utilisées par le serveur pour déterminer ce à quoi cet utilisateur est autorisé à accéder
  – Les extensions

Les informations non-chiffrées sont facilement accessibles en faisant une analyse de trame sous wireshark par exemple (TGS-REP msg-type 13 dans l’exemple ci dessous).
Les autres informations présentes sont quand à elles un peu plus intéressantes à consulter mais malheureusement heureusement elles sont chiffrées 😉 La 1ere partie présente dans ticket / enc-part est chiffrée par Ks qui est la clé dérivée du hash du mot de passe du compte exécutant la ressource, la seconde sous enc-part est chiffrée par Kc (clé dérivée du hash du mot de passe du compte du client):

Dans cet article nous allons déchiffrer la partie la plus intéressante pour nous et nous nous focaliserons donc sur la lecture des données présentes dans le PAC.

PAC – Privilege Attribute Certificate

Kerberos est un protocole d’authentification, mais il est également possible de l’utiliser pour transporter des données d’autorisation d’un contrôleur de domaine vers un serveur via le champ authorization-data des tickets Kerberos.

Il 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…)

Le PAC est généré par le KDC dans les conditions suivantes:

• Lors d’une requête AS validée avec une pré-authentification
• Lors d’une demande TGS lorsque le client n’a pas de PAC et que la cible est un service du domaine ou un service d’attribution de ticket (ticket de référence).

Nous retrouverons le PAC dans les sous-protocoles suivants: AS_REP, TGS_REQ, TGS_REP, AP_REQ.

 

La validation PAC est une fonction de sécurité qui résout l’usurpation de PAC, empêchant un attaquant d’accéder sans autorisation à un système ou à ses ressources en utilisant un PAC falsifié. La vérification de la signature de la structure PAC (présente dans un ticket Kerberos) est systématiquement (*) réalisée lors de la réception d’un ticket kerberos en vue de créer un jeton d’accès (Access Token). La validation de PAC garantit que l’utilisateur présente des données d’autorisation exactes telles qu’elles ont été accordées dans le ticket Kerberos.
L’une des principales raisons pour lesquelles un PAC doit être vérifié est de s’assurer qu’aucun privilège supplémentaire n’a été ajouté de manière malveillante à un ticket ou supprimé de celui-ci.

(*) sauf dans certains cas ou le processus devant vérifier le PAC s’exécute dans le contexte du compte « Local Service », « Network Service » ou dans un contexte de sécurité disposant du privilège SeTcbPrivilege (Act as part of Operating System).

Keytab / ktpass

L’utilitaire ktpass est fourni par Microsoft pour répondre aux scénario d’interopérabilité Kerberos avec le monde Linux. Les applications s’exécutant sur Unix / Linux ou les applications exécutées sous Windows, mais dans un environnement Java, qui souhaitent faire partie de la forêt Active Directory (en mode Single-Sign-On), peuvent avoir besoin d’un fichier keytab. Le fichier keytab contient l’identité complète d’un compte Active Directory à savoir les clés de chiffrement nécessaires pour chiffrer / déchiffrer les tickets Kerberos qui lui sont destinés. Il remplace le couple login/password. Ce fichier (non chiffré) est donc particulièrement sensible!

On a l’habitude de dire que seul un administrateur « Administrateurs du domaine » a le droit d’exécuter cette commande, pourtant il faut juste que le compte qui exécute la commande ait les droit « Reset password » sur le compte cible. L’outil doit être exécuté à partir d’un OS serveur et peut cibler un compte de service ou un compte machine. Dans notre cas nous utiliserons un compte de service.

Dans notre exemple nous allons nous concentrer sur le message TGS-REP msg-type 13 qui contient le PAC. Celui ci est chiffré par Ks qui est la clé dérivée du hash du mot de passe du compte du compte utilisé par la ressource, ici du compte avec lequel le pool IIS s’exécute. Nous allons donc cibler avec ktpass le compte exécutant notre ressources:

Exécuter la commande ci dessous pour générer le fichier keytab:

ktpass -out userApp.keytab -princ HTTP/monsite.test.local@TEST.LOCAL -mapUser TESTLOCAL\svc.monsite -mapOp set -pass Azerty123 -crypto All -pType KRB5_NT_PRINCIPAL

Explication de la commande:

• -out: Fichier généré contenant le résultat et qui contient les clés secrètes partagées du compte cible
• -princ: Concaténation de l’UserPrincipalName et du nom long du domaine. Ce dernier doit être en majuscule.
• -mapUser: Compte ciblé sous la forme Pré-2K
• -pass: Mot de passe compte spécifié par le paramètre princ
• -mapOp set: Définit la valeur du chiffrement DES
• -crypto All: Indique que tous les types cryptographiques supportés peuvent être utilisés. Ils seront présents dans le fichier générés.
• -pType: Spécifie le type de compté ciblé (pourrait être KRB5_NT_SRV_INST pour un utilisateur ou KRB5_NT_SRV_HST pour un hote)

Wireshark et consultation des données chiffrées

Wireshark est à ma connaissance le seul outil d’analyse de trame nous permettant de déchiffrer à la volée les tickets Kerberos. Il faut aller dans les préférences du protole KRB5 et cocher la case « Try to decrypt Kerberos blobs », en indiquant le chemin du fichier keytab précédemment généré.

Pour être certain d’avoir une analyse protocolaire complète, il faudra exécuter avant dans un cmd les commandes suivantes:

• klist purge
• nbtstat –R
• ipconfig /flushdns

…puis lancer une analyse Wireshark. Pour plus de facilité à la lecture, il est possible de filtrer uniquement sur « kerberos ».

Un nouvel onglet « Decrypted krb5 (xxxx bytes) » s’affiche en bas de l’écran. Sur l’écran intermédiaire il est alors possible de consulter la partie normalement chiffrée du ticket:

Et donc je trouve quoi dans le PAC? Vous pouvez consulter ici un exemple pour un TGS-REP: pac extracted