Attaque sur le protocole Kerberos

1. Le protocole Kerberos

Kerberos est un protocole d'authentification développé par le MIT (Massachusetts Institue of Technology) [1]. Il a été conçu afin de fournir une authentification unifiée pour les applications de type client/serveur sur des réseaux qualifiés de non sûrs à l'aide de chiffrement symétrique. L'authentification repose sur une tierce partie de confiance nommée Key Distribution Center (KDC) pour l'attribution de tickets permettant l'accès aux différents services du réseau.

Les implémentations connues de Kerberos sont les suivantes :

- Kerberos MIT : implémentation originale développée par le MIT sous la licence BSD ;

- Microsoft Kerberos V5 : implémentation fournie par Microsoft depuis les versions Windows 2000 ;

- Heimdal : une implémentation alternative du MIT développée en Suède.

Afin de bien comprendre le fonctionnement du protocole Kerberos, il est important de rappeler les différentes entités impliquées dans le processus d'authentification :

- le client (C) souhaitant obtenir un accès à un service ;

- le service d'authentification (AS), qui authentifie le client vis-à-vis du service d'émission de tickets ;

- le service d'émission de tickets (TGS), qui authentifie le client vis-à-vis du service final, à condition que l'authentification avec le serveur d'authentification ait réussi ;

- le serveur (V), qui héberge le service auquel souhaite accéder le client.

Le fonctionnement du protocole Kerberos peut être comparé au processus mis en place dans les salles de cinéma. Tout d'abord, le client (C) achète son ticket d'entrée auprès de la caisse (AS). Dans cette situation, il obtient son ticket en échange d'un moyen de paiement. Ensuite, le client doit présenter son ticket au contrôle (TGS) afin de pouvoir accéder au cinéma. Enfin, devant la salle (V), un dernier contrôle s'assure que le client possède un ticket valable pour accéder à cette salle. Il est à noter que la durée de vie du ticket est limitée à une seule séance.

Il est important de souligner que l'AS et le TGS sont des fonctions du KDC. Le fonctionnement du protocole est décrit par le schéma suivant :

 

 

Détaillons maintenant les différentes phases [2] du processus dans le cas d'une authentification sur un poste de travail ou un serveur.

1.1 Authentication Server Request (AS_REQ)

Le processus débute lorsque l'utilisateur tape son identifiant et son mot de passe. Par la suite, un message de demande d'authentification (AS_REQ) est envoyé au service d'authentification (AS).

Ce message, transmis en clair, contient :

- l'identité de l'utilisateur (dupont@DOMAINE.FR) ;

- le nom du service auquel il souhaite accéder ;

- la durée de vie du ticket ainsi que la liste des machines où le ticket peut être utilisé.

1.2 Authentication Server Response (AS_REP)

Le service d'authentification (AS) s'assure que le nom de l'utilisateur, ainsi que le service auquel il souhaite accéder, existent. Si tel est le cas, une réponse (AS_REP) contenant les éléments suivants est envoyée :

- Un ticket nommé TGT (Ticket-Granting Ticket). Ce ticket, chiffré avec la clé secrète du TGS, contient les informations sur les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, …), ainsi qu'une clé de session que nous appellerons SKtgs.

- La clé de session SKtgs chiffrée avec la clé secrète de l'utilisateur. Dans le cas d'une authentification par mot de passe, la clé secrète de l'utilisateur est un condensat de son mot de passe.

Au terme de cet échange AS_REQ/AS_REP, l'utilisateur et l'AS ont donc échangé :

- Une clé de session SKtgs connue uniquement par l'AS et l'utilisateur (car chiffrée avec la clé secrète de l'utilisateur). Cette clé de session servira pour les échanges ultérieurs avec le TGS.

- Un TGT contenant les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, ...).Ce TGT est chiffré avec la clé secrète du TGS et n'est donc pas modifiable par l'utilisateur.

1.3 Ticket Granting Server Request (TGS_REQ)

Dès lors que le client reçoit le TGT, une demande (TGS_REQ) est adressée au service d'émission de tickets (TGS) pour la connexion à la station de travail.

Cette demande contient :

- Le nom d'utilisateur et un timestamp de la demande chiffrée avec la clé de session SKtgs. Cet élément est appelé authentificateur(authenticator). Il est à noter que seul un utilisateur légitime est capable de générer un tel élément.

- Le TGT précédemment obtenu.

- Le nom du service auquel l'utilisateur souhaite se connecter, ainsi que la durée de vie du ticket.

1.4 Ticket Granting Server Response (TGS_REP)

À la réception de la demande (TGS_REQ) du client, le TGS effectue les actions suivantes :

- Déchiffre le TGT avec sa clé et vérifie sa validité.

- Vérifie la validité de l'authentificateur en utilisant la clé de session SKtgs présente dans le TGT.

Si le TGS_REQ est valide, il émet alors une réponse TGS_REP contenant :

- Une clé de session (SKservice) entre le service et l'utilisateur. Cette clé est envoyée chiffrée par SKtgs.

- Un ticket de service TS chiffré avec la clé du service et contenant le nom de l'utilisateur, le nom du service, la liste des adresse IP autorisées à accéder au service, un timestamp, une durée de validité, ainsi que la clé de session SKservice.

Quand l'utilisateur reçoit cette réponse, il peut donc déchiffrer la clé SKservice, grâce à la clé SKtgs obtenue lors de l'échange AS_REQ/AS_REP.

1.5 Application Request (AP_REQ) (optionnel)

Dans le cas d'utilisation d'un service sur un équipement tiers, une autre requête (AP_REQ) est envoyée au serveur fournissant le service.

Cette requête contient :

- un nouvel authentificateur, chiffré cette fois avec SKservice ;

- le ticket de service TS.

Le fournisseur de service commence par extraire la clé SKservice présente dans le ticket de service TS. À l'aide de cette clé, il extrait le nom d'utilisateur présent dans l'authentificateur et s'assure qu'il est identique à celui contenu dans le ticket de service.

1.6 Application Response (AP_REP) (optionnel)

Ce dernier échange, qui est optionnel, est envoyé uniquement afin d'assurer une authentification mutuelle entre le client et le serveur fournissant le service (V).

Cette requête contient un timestamp généré par le serveur et est chiffrée avec la clé SKservice.

2. Historique des attaques sur Kerberos

Depuis la publication du protocole Kerberos en 1989, différentes faiblesses ont été identifiées. Dans cette section, nous vous présentons deux attaques connues : KDC Spoofing et Replay attack. Les faiblesses présentées dans ces deux attaques ont été utilisées pour réaliser l'attaque Pass the ticket.

2.1 KDC Spoofing

Comme son nom l'indique, cette attaque se base sur la possibilité d'usurper les réponses du KDC. Néanmoins, comme évoqué précédemment, le protocole Kerberos est censé être protégé contre ce type d'attaques. En effet, Kerberos a été conçu pour fonctionner sur des réseaux non sûrs, ainsi que d'assurer une authentification mutuelle.

Cependant, certaines applications n'utilisent pas le protocole Kerberos dans son ensemble. Par exemple, sur certains systèmes Linux/Unix, les premières versions du module PAM utilisaient un « raccourci ». Le client n'envoyait que les requêtes destinées à l'AS. Ainsi, lorsque l'utilisateur fournissait son mot de passe, une requête AS_REQ était envoyée au KDC, et à la réception de la réponse AS_REP, le module PAM tentait de déchiffrer une partie du message avec la clé dérivée du mot de passe de l'utilisateur.

Concrètement, un utilisateur possédant un accès physique à la machine et étant en mesure de contrôler les requêtes du client peut obtenir un accès à l'équipement avec le compte d'un utilisateur précis et un mot de passe quelconque. Pour cela, il suffit à l'attaquant d'effectuer une authentification avec un mot de passe fixé et de bloquer l'envoi de la requête AS_REQ au KDC. En effet, l'attaquant va répondre lui-même à cette requête en forgeant une requête AS_REQ avec le mot de passe précédemment utilisé. Un code d'exploitation de l'attaque a été fourni par Dug Song [7].

Afin de se protéger de cette attaque, il est nécessaire d'effectuer l'étape suivante du protocole, c'est-à-dire réaliser une demande de ticket au TGS.

2.2 Replay Attack

Comme évoqué précédemment, le serveur s'assure que le client peut accéder au service en validant uniquement la dernière requête envoyée : Application Server Request (AP_REQ).

Cette attaque par rejeu nécessite que l'attaquant mette en place un Man-In-The-Middle entre le client et le serveur. Par la suite, il y a deux possibilités :

- Soit l'attaquant effectue une écoute du réseau et renvoie la requête AP_REQ émise par le client afin d'obtenir un accès au service.

- Soit l'attaquant empêche le client d'envoyer la requête AP_REQ au serveur et l'utilise pour obtenir l'accès au service à la place du client.

Plusieurs contre-mesures ont été proposées afin de réduire l'impact de cette vulnérabilité :

- Timestamp : La durée d'utilisation de l'AP_REQ est limitée à un certain temps (en général 5 minutes).

- Cache : Le serveur (V) stocke en mémoire les requêtes (ou plus précisément les authentificateurs) effectuées par le client pendant la durée d'utilisation autorisée. Ainsi, toutes les requêtes en double sont rejetées.

- Adresse IP : Le ticket fourni par le KDC peut contenir la liste des adresses IP autorisées à utiliser ce ticket. Cette information est conservée dans la requête AP_REQ. Ainsi, le serveur est en mesure de vérifier si l'expéditeur de la requête a le droit d'utiliser ce ticket.

2.3 Kerberos et le chiffrement

Une autre catégorie d'attaque consiste à exploiter les faiblesses des algorithmes de chiffrement utilisés par Kerberos.

Historiquement, Kerberos utilisait uniquement l'algorithme DES (dont la faiblesse n'est plus à démontrer [12]). Le protocole a depuis évolué pour intégrer un mécanisme de négociation de l'algorithme de chiffrement entre le client et le KDC.

Malheureusement, cette négociation n'est pas protégée. Il est donc possible pour un attaquant ayant accès aux flux réseau entre le client et le KDC de modifier ces échanges afin de forcer l'utilisation de l'algorithme de chiffrement le plus faible [11].

La seule contre-mesure est alors de limiter les algorithmes acceptés côté client et serveur. Sous environnement Windows, les algorithmes faibles sont désactivés à partir de Windows 7 et Windows 2008 R2 [13].

3. L'attaque Pass the Ticket

La présentation originale de cette attaque date de 2008 par Emmanuel Bouillon à la conférence PacSec [3]. Une présentation à la BlackHat, ainsi qu'a la conférence Hack.lu, a été effectuée en 2009 et 2010 [4] [10].

Cette attaque permet de s'authentifier localement sur le poste client, et ce même si l'authentification Kerberos est complètement réalisée (AS_REQ/AS_REP + TGS_REQ/TGS_REP). Du côté attaquant, cela nécessite le contrôle des flux réseau échangés entre le client et le KDC, ainsi qu'un accès physique sur l'équipement.

L'attaque se déroule en deux phases :

1. Écoute d'une authentification Kerberos légitime

Durant cette phase, l'attaquant va enregistrer les échanges Kerberos effectués lors d'une connexion légitime de l'utilisateur victime. L'objectif est d'obtenir le ticket de service TS.

2. Rejeu d'un ticket valide

L'attaquant va alors tenter de se connecter physiquement sur le poste client, en utilisant un nom d'utilisateur valide, ainsi qu'un mot de passe quelconque (par exemple « password ») de la façon suivante :

A) Le poste client va alors générer un AS_REQ qui sera intercepté par l'attaquant.

B) L'attaquant répondra avec un AS_REP contenant :

- Un ticket TGT forgé. Ce ticket sera chiffré avec une clé choisie par l'attaquant en lieu et place de la clé secrète du TGS.

- Une clé de session SKtgs* choisie par l'attaquant et chiffrée avec une clé dérivée du mot de passe « password ».

C) Le client génère alors une requête TGS_REQ. Celui-ci contient alors le TGT forgé précédemment reçu, ainsi qu'un authentificateur chiffré avec la clé de session SKtgs et choisie par l'attaquant. Ce TGS_REQ est également intercepté par l'attaquant.

D) L'attaquant envoie alors un TGS_REP au poste client, contenant :

- Le ticket de service TS intercepté lors de l'étape 1. Ce TS contient la clé de session SKservice utilisée lors de l'échange original.

- L'attaquant envoie également une clé de session forgée (appelons la SKservice*), chiffrée avec la clé de session SKtgs*.

Les vérifications effectuées du côté du poste client pour l'authentification de l'utilisateur sont :

- Vérification que la clé de service légitime du poste client est capable de déchiffrer le ticket TS.

- Vérification que la clé de session SKtgs* est capable de déchiffrer SKservice*.

- Vérifie les limites de validité contenues dans le ticket de service TS.

Dans notre attaque, toutes ces conditions sont remplies.

Pour récapituler, cette attaque permet de se connecter localement à un ordinateur membre d'un domaine Active Directory si :

- L'attaquant est capable d'écouter et de modifier les flux réseau entre l'ordinateur cible et le contrôleur de domaine.

- Un utilisateur légitime se connecte sur le poste.

- L'attaquant dispose par la suite d'un accès au poste client cible (physiquement ou par un accès type VNC/terminal server).

L'attaquant disposera alors des privilèges de l'utilisateur dont l'authentification Kerberos a été capturée sur l'ordinateur cible.

4. Démonstration

Passons maintenant à la phase pratique. Cette démonstration se base sur les travaux effectués par Secgroup [5]. Notre environnement de test se compose d'un contrôleur de domaine Active Directory 2003 et d'un poste victime, membre du domaine, sous Windows XP.

Les éléments dont nous aurons besoin pour réaliser cette attaque sont :

- une machine Unix ;

- la bibliothèque de manipulation de paquets Scapy ;

- le code d'exploitation [6] et la bibliothèque cryptographique [7] Kerberos développés par Secgroup.

Si la version de Scapy installée sur votre système n'a pas été mise à jour récemment, il vous sera nécessaire d'appliquer le patch suivant :

Comme nous l'avons vu précédemment, cette attaque nécessite comme pré-requis le contrôle des flux réseau transitant entre le poste client et le contrôleur de domaine.

Nous commençons donc par nous mettre en situation en déclenchant une attaque de type ARP Poisoning et en prenant soin au préalable d'activer le routage, ainsi que de bloquer l'envoi des messages de type ICMP Redirect avec une règle iptables.

Nous lançons ensuite l'outil kdcreplay en fournissant les options suivantes :

- d : sauvegarde les requêtes TGS_REP dans le fichier spécifié ;

- k : l'adresse IP du KDC ;

- t : l'adresse IP du poste victime ;

- e : spécifie le chiffrement à utiliser (3des, rc4win ou aes) ;

- r : le nom du domaine Active Directory ;

- u : le nom d'utilisateur de notre victime ;

- p : le mot de passe à utiliser.

Dans notre exemple, l'utilisateur se nomme « victime » et le nom du domaine est « SECURITE ».

L'outil se met alors en mode écoute du trafic pour extraire les tickets envoyés lors d'une authentification légitime :

En appuyant sur Ctrl-C, nous passons l'outil en mode rejeu :

Nous ajoutons alors une règle iptables pour bloquer la transmission des paquets vers le contrôleur de domaine afin d'éviter toute interférence lors de notre attaque :

Nous pouvons alors nous connecter sur le poste client avec le mot de passe « password ». Le poste client Windows va alors générer la séquence d'authentification AS_REQ/ TGS_REQ. Ces deux requêtes vont alors être interceptées par notre outil en Man-In-The-Middle :

Nous obtenons alors un accès sur l'équipement.

5. Moyens de protection

Comme évoqué précédemment, seule l'implémentation du protocole Kerberos par Microsoft est vulnérable à l'attaque Pass the Ticket. À l'heure actuelle, aucun correctif n'a été fourni par Microsoft.

En revanche, l'implémentation Kerberos fournie par le MIT n'est pas vulnérable en raison du respect des spécifications du protocole. En effet, l'implémentation de Microsoft n'effectue que les deux premiers échanges pour authentifier un utilisateur (AS_REQ/AS_REP et TGS_REQ/TGS_REP), tandis que celle du MIT ajoute l'envoi de la requête AP_REQ. Pour rappel, cette requête contient un authentificateur chiffré avec la clé SKservice et le ticket de service (TS). Le service (V), qui est simulé en interne dans le cas d'une authentification sur le poste local, va s'assurer que le nom d'utilisateur présent dans l'authentificateur et le TS sont identiques. Or, lors de l'attaque, le TS fourni par l'attaquant provient d'une précédente session, ce qui implique que le service ne sera pas en mesure de déchiffrer l'authentificateur chiffré par la clé SKservice* forgée par l'attaquant et, par conséquent, refusera l'authentification de l'utilisateur.

Pour les administrateurs ne souhaitant pas attendre la sortie du correctif de Microsoft, il leur est nécessaire d'empêcher un attaquant d'obtenir un accès physique aux postes de travail utilisateur (badge, restriction des interfaces d'administration, ...) et/ou la possibilité de manipuler le trafic réseau (protection ARP poisoning, 802.1X, etc.). Bien entendu, la mise en place de ces solutions est beaucoup plus complexe.

Conclusion

Le protocole Kerberos assure une authentification unifiée sur des réseaux non sûrs et jouit d'une bonne réputation de par les travaux de durcissement réalisés depuis 20 ans par la communauté.

Toutefois, l'implémentation de Microsoft (disponible dans toutes les versions de Windows depuis Windows 2000) souffre actuellement d'un défaut non corrigé, qui permet à un attaquant contrôlant le trafic réseau de pouvoir ouvrir une session localement sous l'identité de n'importe quel utilisateur et sans connaître son mot de passe.

Cette faille ne permet toutefois pas de s'authentifier à distance sur d'autres ressources réseau, ni de déchiffrer les secrets locaux protégés par le mot de passe de l'utilisateur (ex. DPAPI) – c'est probablement pourquoi Microsoft a décidé de repousser la correction à un futur Service Pack.

L'exploitation des faiblesses présentes sur ce protocole n'est pas encore monnaie courante, la plupart des outils d'attaque s'étant focalisés sur les faiblesses d'autres protocoles d'authentification Windows (LM, NTLM). Nous espérons que cet article vous aura donné envie de vous y intéresser.

REMERCIEMENTS

Nous tenons à remercier Nicolas Ruff pour ses relectures, ainsi que l'opportunité offerte d'écrire dans MISC.

Enfin, nous tenons à remercier Nicolas Grenèche pour son aide et ses conseils avisés.

RÉFÉRENCES

[1] http://web.mit.edu/Kerberos/

[2] http://www.zeroshell.net/eng/kerberos/

Découverte originale de l'attaque :

[3] E. Bouillon : Gaining access through Kerberos, PacSec 2008

[4]http://www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf

Implémentation originale de l'attaque :

[5] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/m0t-krb5-08-2010.pdf

[6] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/kdcreplay-08062010.tar.gz

[7] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/Krb5Crypto-0.4.tar.gz

[8] http://www.monkey.org/~dugsong/kdcspoof.tar.gz

[9] KB244474 : http://support.microsoft.com/kb/244474/en-us

[10] http://archive.hack.lu/2010/Bouillon-Stealing-credentials-for-impersonation.pdf

[11] https://media.blackhat.com/bh-us-10/whitepapers/Stender_Engel_Hill/BlackHat-USA-2010-Stender-Engel-Hill-Attacking-Kerberos-Deployments-wp.pdf

[12] http://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html

[13] http://technet.microsoft.com/fr-fr/library/dd560670%28WS.10%29.aspx