(Active Directory) Authentification Kerberos

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Kerberos (en référence au chien à trois têtes qui protège l’accès aux enfers) est un protocole d’authentification développé par le MIT puis repris par Windows et introduit pour la première fois sur Windows 2000 afin de remplacer NTLM.

Kerberos offre plusieurs avantages à NTLM : il est plus rapide dans l’authentification,  ne stocke aucun mot de passe sur la machine, n’envoie aucun mot de passe sur le réseau (hashé ou en clair) et, cerise sur le gâteau,  il permet une authentification Single Sign On.

Pas mal non ?! Alors petit disclaimer, le protocole Kerberos est plutôt compliqué à comprendre et encore plus à expliquer simplement. Par conséquent je vais me permettre d’omettre certaines informations. Par contre je vais vous donner d’autres informations extrêmement importantes. Ces informations seront soulignées et en gras et vous en aurez besoin pour comprendre l’article sur l’exploitation de Kerberos.

I/ Fonctionnement global de Kerberos

Sur chaque contrôleur de domaine (serveur qui héberge l’Active Directory) se trouve un serveur un peu particulier : le KDC (Key Distribution Center). Ce KDC est une entité de confiance absolue sur le réseau. C’est à dire que tous les services/serveurs font confiance au KDC (un peu comme les navigateurs web avec les autorités de certification).

Ce KDC est divisé en deux rôles. Le premier c’est l’Authentication Service (AS) : c’est le service sur lequel s’authentifie le client. Le second : c’est le Ticket Granting Service (TGS) : celui qui fournit le droit d’accès à la ressource :

6

La première étape est celle de l’authentification. Généralement, c’est un utilisateur qui va se connecter à une session Windows en entrant un couple identifiant/mot de passe. Suite à ça, un premier message va être envoyé par le client à l’Authentication Service. Dans ce message il y a deux éléments :
-Le nom de de l’utilisateur en clair
-Le nom de l’utilisateur et un timestamp (une date et une heure) chiffrés (en rouge sur le schéma).

Cette partie, chiffrée, va être créée à partir du hash NTLM du mot de passe fourni précédemment par l’utilisateur. Notez bien cependant, qu’à aucun moment, ni le mot de passe de l’utilisateur ni le hash NTLM de ce mot de passe n’est envoyé sur le réseau :

1

L’Authentication Service, lorsqu’il va recevoir le message, va directement vérifier que le nom d’utilisateur correspond à un utilisateur dans l’AD. Si c’est le cas, il va récupérer le mot de passe de ce compte. Puis il va tenter de déchiffrer l’élément : {nom d’utilisateur, timestamp}. S’il y arrive, c’est que le client a fourni le bon mot de passe donc l’authentification est réussie.

A partir de là, l’Authentication Service va renvoyer un Ticket Granting Ticket (que l’on abrège TGT). Ce TGT est un peu comme une carte d’identité pour nous le Hommes. Il représente le client et est une donnée de confiance puisqu’elle a été fournie par le KDC :

2.png

Attention cependant, le client ne peut pas lire l’entièreté du TGT puisqu’une partie de ce dernier est chiffrée. En fait, le client n’a connaissance que des métadonnées du ticket (date de validité, date de renouvellement, sur quel domaine l’utiliser etc…). La partie la plus importante du ticket est chiffrée à l’aide du hash NTLM du mot de passe du compte krbtgt que seul le KDC connaît. Il est donc impossible pour le client (ou pour un attaquant) de modifier son TGT.

A partir de ce ticket, le client va pouvoir faire une demande d’accès à un service auprès du TGS (Ticket Granting Service) du KDC. Pour cela il va devoir envoyer son TGT ainsi que le SPN du service qu’il veut joindre au TGS.

« Mais c’est quoi un SPN ? »

SPN est l’acronyme de Service Principal Name. Concrètement, ça permet -sous Kerberos- d’associer un nom de service à une machine, c’est un identifiant unique sur un réseau. Ici, le SPN de notre serveur mail est IMAP/mail.local :

4.png

Comme c’est le KDC qui a chiffré le TGT, il va aussi pouvoir le déchiffrer. Et comme c’est lui qui l’a créé et émis, il va avoir une totale confiance en ce TGT. Si les informations sont correctes alors le TGS va émettre un Service Ticket (ST ou TGS selon les normes). Notez bien que le Ticket Granting Service permet d’authentifier le client mais en aucun cas il ne donne une autorisation d’accès à la ressource.

5.png

Encore une fois, ce TGS est partiellement chiffré. Les métadonnées sont utilisables par le client mais le contenu du TGS lui est chiffré à partir du hash NTLM du mot de passe du compte de service relatif à la ressource demandée.

Et encore une fois, le client n’aura plus qu’à forwarder ce TGS directement vers la ressource demandée pour y avoir accès :

6.png

Vu que le TGS est chiffré à partir du hash NTLM du mot de passe du compte de service du serveur mail, ce dernier sera en mesure de le déchiffrer et donc de donner un accès ou non au client. C’est ici que l’accès est autorisé ou refusé au client.

Voilà, vous avez accès au serveur mail. A priori le processus semble plutôt bien sécurisé. Pourtant il existe plusieurs faiblesses dans ce protocole. Et croyez moi, c’est extrêmement violent 😎


Une deuxième partie axée sur l’exploitation du protocole Kerberos est en cours d’écriture, le plus long étant de mettre en place un environnement de laboratoire. Je mettrais un lien direct vers l’article quand il sortira (d’ici quelques jours promis 😀 )

2 commentaires

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s