Cours Sécurité des réseaux Authentification avec Kerberos

Cours Sécurité des réseaux Authentification avec Kerberos

...

1.1 Qu’est-ce que Kerberos ?

Selon la mythologie, Kerberos est le chien à trois têtes gardant le pont me¬nant aux portes de l’enfer. Plus ”récemment”, Kerberos fut le nom choisi pour le mécanisme d’authentification d’un projet menéau MIT appeléAthena. Aujour¬d’hui, Kerberos est un protocole d’authentification réseau. La version actuelle du protocole, la version 5, est un standard défini dans la RFC 1510 [1]. Les versions 1 à 3 ne sont restées que des versions de développement. La version 4 est décrite dans [2] et [3].

1.2 Intérêts du protocole

Peu de mécanismes résolvent le problème de l’authentification réseau unifiée en milieu hétérogène, qui plus est, mixte Unix/MS Windows. L’utilisation pour l’authentification, des NIS (Network Information Services), de SSH pour la dis¬tribution de fichiers passwd et shadow, d’UIS (Unix Integration Services) ser¬vice Microsoft qui n’est plus supporté, des SFU (Service For Unix) sous Win¬dows, de LDAP, sont des techniques qui souffrent toutes de défauts de mise en œuvre et de sécurité. Kerberos présente l’avantage d’être un standard dispo¬nible sous les systèmes ”libres” (Linux, *BSD) et sous les systèmes propriétaires, Solaris (SunMicrosystem), Irix (SGI), Windows 2000 et XP. La portabilitédes implémentations ”OpenSource” permet de compléter cette liste. Bien sûr, Ker¬beros résout plusieurs problèmes de sécuritéclassiques dans l’authentification des clients et des services au sein d’un réseau. Enfin, Kerberos est aujourd’hui le principal mécanisme de sécuritésous-jacent supportédans les implémentations de la GSSAPI [4,5]. Cette API étant la base des RPCSEC GSS, mécanisme désignépour sécuriser la prochaine version de NFS (version 4, [6]).

1.3 Objectif de cet article

Pour mieux évaluer la pertinence de ce protocole dans un contexte donné, il convient d’en comprendre non seulement les avantages mais aussi les limites, y compris en termes de sécurité. Cet article propose de rappeler le fonctionnement du protocole Kerberos, puis de décrire certains problèmes de sécuritéqui peuvent se poser lors du déploiement de Kerberos. Les points abordés sont regroupés en deux catégories :

– Les problèmes inhérents au protocole lui-même;

– Les problèmes liés aux difficultés pratiques de déploiement.

Dans la suite, une application sera dite ”kerbérisée” pour signifier qu’elle supporte le protocole Kerberos.

2 Le protocole Kerberos

2.1 Caractéristiques du protocole

Le protocole Kerberos se base sur les deux articles [7] et [8]. Il permet l’au¬thentification des utilisateurs et des services sur un réseau supposénon sûr. Par exemple, les données sur ce réseau peuvent être lues ou modifiées, les adresses des machines peuvent être faussées. Ces informations ne peuvent donc servir à l’authentification. Kerberos utilise une tierce partie de confiance. Toutes les entités du réseau, utilisateurs et services, appelés principaux, font confiance à cette tierce partie (le serveur Kerberos ou KDC pour Key Distribution Center).

Enfin, Kerberos utilise des mécanismes de chiffrement basés sur des algorithmes à clef symétrique (ou secrète) : tous les principaux partagent cette clef secrète avec le serveur Kerberos.

2.2 Fonctionnement détaillé: de l’authentification par secret partagéà Kerberos v5

Dans toute la suite, Alice (A) sera l’entitéqui initie la communication (ana¬logie avec le client, l’utilisateur), Bob (B) l’entitéqui répond (analogie avec le service, serveur applicatif). Kab sera la clef partagée entre Alice et Bob (on a Kab = Kba).

Authentification par secret partagéKerberos utilise des algorithmes de chiffrement à clef secrète pour l’authentification. La manière la plus simple de faire de l’authentification à l’aide de tels algorithmes est la suivante :

1. Alice appelle Bob
2. Bob répond à Alice avec un nombre généréaléatoirement, Nb
3. Alice retourne Kab{Nb}

A l’issue de cet échange, Bob en déchiffrant la réponse de Alice, vérifie que Alice connaît bien la clef secrète Kab. Pour une authentification mutuelle, Alice émet à son tour un nombre aléatoire (Na) que Bob retourne chiffrépar Kab.

Une autre méthode pour l’authentification mutuelle à l’aide d’un algorithme à clef secrète est de faire envoyer par Bob, non pas un nombre aléatoire, mais ce nombre chiffrépar Kab. Alice déchiffre ce message, effectue une opération triviale sur le nombre obtenu et le renvoie chiffré. On obtient le schéma suivant :

1. Alice appelle Bob
2. Bob envoie Kab{Nb}
3. Alice déchiffre le message, obtient Nb et envoie Kab{Nb − 1}
4. Alice envoie Kab{Na}
5. Bob déchiffre le message, obtient Na et envoie Kab{Na − 1} Ce qui, en regroupant les messages indépendants, donne (schéma 1) :
6. Alice envoie Kab{Na}
7. Bob déchiffre le message, obtient Na, envoie Kab{Na − 1} et Kab{Nb}
8. Alice déchiffre le message, obtient Nb et envoie Kab{Nb − 1}

C’est ce schéma qui apparaît dans le protocole de Needham et Schroeder [7]. Avec une amélioration toutefois :

Utilisation d’une tierce partie de confiance L’un des inconvénients majeurs du schéma 1 est son manque d’extensibilité. La généralisation à m utilisateurs et n services, implique la distribution préalable de m x n clefs partagées. Une solu¬tion à cette problématique est l’introduction d’une tierce partie de confiance (une autre solution est l’utilisation d’un algorithme de chiffrement asymétrique pour négocier une clef de session symétrique). Cette tierce partie (TP) de confiance connaît les secrets partagés de chaque entitéà authentifier (Ka pour Alice, Kb pour Bob). L’authentification mutuelle peut alors se faire comme suit :

1. Alice demande à TP d’accéder à Bob
2. TP génère une clef de session entre Alice et Bob, Kab
3. TP envoie Ka{Kab, Bob} à Alice et Kb{Kab, Alice} à Bob

A ce niveau, on peut appliquer le schéma 1 pour l’authentification mutuelle par algorithme à clef secrète. En effet, Alice connaissant Ka, peut en déduire Kab. De même, Bob connaissant Kb peut en déduire Kab.

On remarque cependant que pour la distribution de Kab, Alice, le client envoie un message alors que la tierce partie commune à tous les utilisateurs en envoie deux. On préfère en général faire porter la charge sur le client et non sur la tierce partie qui doit gérer tous les clients. On modifie donc légèrement le schéma précédent qui devient :

1. Alice demande à TP d’accéder à Bob
2. TP génère une clef de session entre Alice et Bob, Kab
3. TP envoie Ka{Kab, Bob} et Kb{Kab, Alice} à Alice
4. Alice appelle Bob et lui envoie Kb{Kab, Alice}

Alice, qui ne connaît pas Kb, ne peut rien faire de Kb{Kab, Alice} si ce n’est l’envoyer à Bob. Cette information est le ticket pour dialoguer avec Bob.

On abouti alors au schéma de Needham et Schroeder, le nombre aléatoire Nl, envoyéavec la première requête n’est làque pour rendre unique cette requête et sa réponse pour éviter des attaques de type ”rejeu”.

1. Alice demande à TP d’accéder à Bob et joint Nl
2. TP génère une clef de session entre Alice et Bob, Kab
3. TP envoie Ka{Nl, Kab, Bob, Ticketb} à Alice, oùTicketb = Kb{Kab, Alice}
4. Alice déchiffre la réponse, en tire Ticketb et Kab
5. Alice appelle Bob avec Ticketb et Kab{Na} (schéma 1)
6. Bob déchiffre le Ticket, en tire Kab, répond avec Kab{Na − 1, Nb}
7. Alice répond avec Kab{Nb − 1}

Kerberos Le protocole Kerberos améliore le schéma de Needham et Schroeder d’une part en remplaçant les nombres aléatoires par des dates (timestamps), d’autre part en séparant le rôle de la tierce partie de confiance en deux services : – Le service d’authentification (AS pour Authentication Service)

– Le générateur de ticket de service (TGS pour Ticket Granting Service)

L’utilisation des timestamps permet d’introduire la péremption de ticket et de réduire la fenêtre de temps pendant laquelle le rejeu de ticket est possible. Ce type d’attaque est surtout empêchépar l’utilisation d’un cache stockant les authentificateurs reçus et dont la date de validitén’a pas expiré. On note que cette propriétéintroduit une dépendance entre Kerberos et le service de temps.

La séparation du rôle du KDC en deux services induit deux types de ticket différents :

– Le TGT (Ticket Granting Ticket) est envoyépar l’AS. Une demande de TGT est en fait une demande d’accès au service TGS. Le TGT est donc le ticket du service TGS. La réponse de l’AS contient aussi la clef de session entre le client (A) et le service TGS (Ka,tgs) chiffrée par la clef secrète du client (Ka).

– Le TS (Ticket Service) pour un service donné(S) est envoyépar le TGS sur présentation d’un TGT et d’un timestamps chiffréavec la clef de session Ka,tgs. Le TGS sait donc que le client a pu déchiffrer la réponse de l’AS et donc connaît la clef secrète Ka. Le TGS génère une clef de session entre A et S, Ka,s. La réponse du TGS contient donc notamment, cette clef de session chiffrée par Ka,tgs (A pourra ainsi la déduire) et le TS proprement dit, constitué, entre autre, de Ka,s chiffrépar Ks, la clef secrète du service S (S, sur présentation de ce ticket pourra en déduire Ka,s).

La même clef Ka,tgs permet d’obtenir les clefs de session des services accédés pendant toute la validitédu TGT. Le principal avantage de cette séparation des rôles du KDC est de permettre le SSO (Single Sign On). En effet, seul l’exploitation du TGT nécessite l’utilisation de la clef secrète du client. Ainsi, tant que son TGT est valide, le client pourra acquérir des TS sans réutiliser sa clef, qui est directement déduite du mot de passe dans le cas d’un utilisateur. Cette propriété, couplée avec la possibilitéde rendre le TGT ”forwardable”, c’est¬à-dire réutilisable une fois connectéau service, permet à Kerberos de fournir un SSO.

La pré-authentification Au cours du dialogue précédent, on constate qu’il n’est pas nécessaire de connaître Ka pour obtenir de la tierce partie de confiance un TGT et un message chiffrépar Ka. Il suffit de le demander à l’AS pour l’obtenir.

La pré-authentification résout ce problème. Elle exige que la requête à l’AS, émise par le client, soit accompagnée d’un timestamp chiffrépar Ka. L’AS peut ainsi valider que la requête émane bien d’une entitéconnaissant sa clef secrète.

2.3 Les relations de confiance inter-royaume

Kerberos prévoit la possibilitéqu’un principal puisse s’authentifier auprès de principaux n’appartenant pas à son royaume : Il s’agit de l’authentification inter-royaume. Cela implique d’établir une relation de confiance entre les deux royaumes. Cette relation peut être unilatérale ou bilatérale.

Deux méthodes sont possibles pour établir une telle relation.

Méthode directe Les deux KDC partagent une clef secrète utilisée pour prou¬ver l’identitéd’un principal lorsqu’il change de royaume. L’inconvénient de cette méthode est son manque d’extensibilité. La généralisation à n royaumes impose l’échange de n x (n − 1)/2 clefs ou n x (n − 1) clefs dans le cas de relations bilatérales. Ceci peut être résolu par l’utilisation de la méthode transitive.

Méthode transitive Dans ce cas, on définit le chemin des royaumes partageant une clef secrète. Ce chemin peut être soit explicite (mécanisme des CApath, Certificate Authority Path) soit hiérarchique via le DNS.

6             Actes du symposium SSTIC04

3 Kerberos et la sécuritéCette partie rappelle certains des problèmes de sécuritéqui peuvent être rencontrés au cours du déploiement de Kerberos sur un réseau.

3.1 Problèmes inhérents au protocole

Les problèmes décrits ci-après sont connus de longue date. Pour certains, Dug Song [9] notamment a démontréla faisabilitéde leur exploitation. L’objectif de ce paragraphe est d’en rappeler le principe et de montrer que sans précaution, ces attaques sont toujours valables dans les implémentations actuelles du protocole.

Attaque par dictionnaire et pré-authentification Dans la version 4 du protocole, le mécanisme de pré-authentification n’était pas prévu. N’importe qui pouvait obtenir un message chiffréavec la clef secrète d’un utilisateur donné. Toute la sécuritéreposait sur l’incapacitéde déduire la clef secrète de ce message. Bien sûr, compte tenu de la propension des utilisateurs à choisir des mots de passe faibles, une attaque par dictionnaire avait clairement de fortes chances d’être fructueuse.

Sans pré-authentification, écrire un outil qui ferait l’équivalent d’un ypcat passwd avec les NIS ne pose pas de difficultés.

Dès lors, adapter un outil de craquage de mots de passe pour lui permettre d’attaquer ces messages chiffrés est assez simple. Dug Song propose un patch pour John the Ripper [10] et la version 4 de Kerberos. Avec l’avènement de la version 5 de Kerberos et l’apport de la pré-authentification, la conscience de cette faiblesse du protocole s’est estompée. Les documentations insistent peu sur son utilité. Il convient alors de faire les remarques suivantes sur ce sujet :

– La pr&authentification n’est pas activée par défaut sur nombre d’impl& mentations du protocole. Elle est notamment impossible si l’on souhaite une compatibilitéavec Kerberos version 4.

– L’activation de la pr&authentification diminue le risque mais ne l’élimine pas puisque dans le cas d’une authentification licite, le message chiffrépeut être lu sur le réseau. Modifier un sniffer à cette fin est simple.

– Adapter un outil de craquage de mot de passe à la version 5 du protocole est simple.

En conséquence, il est important de rappeler que la pr&authentification est une option indispensable à la sécuritéde Kerberos mais n’élimine pas complè¬tement le risque d’attaque par dictionnaire tant que la clef secrète sera dérivée d’un mot de passe statique choisi par l’utilisateur.

La mise en place de mesures assurant la robustesse des mots de passe choisis par les utilisateurs est un moyen efficace de lutter contre ce problème. Le support par Kerberos d’algorithmes de chiffrement asymétrique (PKINIT [11]) coupléavec l’utilisation d’un deuxième facteur pour l’authentification, une carte à puce par exemple, supprimerait le risque d’une telle attaque. Espérons que les efforts actuels pour l’intégration de PKINIT et de la pré-authentfication ”matérielle” aboutiront rapidement.

Usurpation du KDC Cette deuxième attaque a aussi étémise en évidence par Dug Song notamment. Le but de ce paragraphe est d’en expliquer le principe, de donner les moyens de s’en protéger et leurs limites, ceux-ci n’étant que rarement préconisés dans les documentations.

Fondamentalement, Kerberos permet d’authentifier un utilisateur auprès d’un service kerbériséet réciproquement. Cependant, on peut dans le cadre du d& ploiement de Kerberos, utiliser ce protocole comme point d’entrée sur un réseau, c’est-à-dire au niveau de l’authentification système.

Le moyen le plus simple pour y parvenir est l’utilisation d’un module PAM, d’autres font exécuter la commande kinit à la connexion de l’utilisateur ou encore changent la commande de login. Dans le cas de l’utilisation d’un module PAM, le système se sert de la capacitéà déchiffrer la réponse du KDC avec le mot de passe fourni par l’utilisateur pour l’authentifier. Il ne s’agit pas d’une réelle authentification Kerberos auprès d’un service. Le défaut de cette configuration est qu’il n’y pas authentification de la réponse du KDC. La requête et l’analyse de sa réponse sont faites par le client. Si la clef donnée par l’utilisateur permet de déchiffrer le TGT obtenu, l’utilisateur est autoriséà se connecter et possède un TGT. Ce n’est que s’il cherche à accéder à un service kerbériséqu’il s’en servira pour faire une demande de TS.

Ce manque d’authentification de la réponse du KDC permet une attaque par usurpation du KDC si l’on a la possibilitéd’écouter et d’injecter du trafic entre le système cible et le KDC. Si la seule présentation d’un TGT correspondant à la clef secrète fournie au login permet de se connecter à un système, il est possible de contourner cette authentification comme suit :

1. L’attaquant se connecte au nom de la victime en entrant un mot de passe quelconque
2. Le système émet une requête de TGT
3. L’attaquant répond en utilisant la clef dérivée du mot de passe qu’il a lui-même fournie au système
4. La réponse peut être déchiffrée par la clef : l’utilisateur est autoriséà se connecter

Bien sûr, le TGT ainsi obtenu ne permettra pas d’obtenir de TS valide. Mais une fois connecté, l’utilisateur peut accéder au disque et à tous les services non kerbérisés (Home en NFSv3 non kerbérisépar exemple).

Une contre-mesure pour cette attaque est de vérifier l’authenticitéde la réponse du KDC en demandant un TS avec ce TGT pour le service host du système local et d’en vérifier la validité. Si la réponse est valide, le KDC partage non seulement la clef secrète de l’utilisateur mais aussi celle du service host du système. Il est à noter que le module PAM Kerberos le plus utilisé[12] prévoit cette fonctionnalitémais elle n’est pas documentée.

Kerberos et son environnement On décrit parfois Kerberos comme un pro¬tocole faisant peu d’hypothèses sur la sécuritédu réseau oùil est déployé. Il convient cependant de comprendre les conséquences d’une compromission même partielle du réseau sur l’authentification.

La compromission, au niveau adminstrateur, d’une machine quelconque du réseau aboutit à la compromission des clefs des services de cette machine et des tickets des utilisateurs qui y sont connectés. L’attaquant peut alors usurper l’identité:

– des services de cette machine tant que leurs clefs ne sont pas changées

– des utilisateurs authentifiés sur cette machine pendant la durée de validitéde leurs tickets

L’installation d’un cheval de Troie pourra aboutir à la compromission de mots de passe des utilisateurs, rendant l’usurpation de leur identitépossible jusqu’au changement de leur mot de passe. En conséquence, le déploiement de Kerberos ne permet pas de s’abstenir d’autres mesures élémentaires de sécuritécomme l’ins¬tallation des mises à jour de sécurité. Enfin, dans un environnement kerbérisé, la compromission d’une seule machine spécifique, un KDC, conduit au contrôle total par l’attaquant de tous les authentifiants de entités Kerberos (utilisateurs et services) de ce royaume. On comprend la nécessitéde sécuriser avec soin les machines assurant cette fonction et aussi de cloisonner les différents groupes d’utilisateurs dans des royaumes différents.

Kerberos et l’autorisation L’objectif d’une solution de sécuritéest de s’at¬taquer à la problématique des trois ’A’ (Authentication, Autorization, Accoun¬ting). Kerberos cherche à résoudre le problème du premier ’A’, l’authentification. Il fournit au service l’assurance que l’utilisateur qui se présente à lui est bien celui qu’il prétend être (àla sécuritéde la clef secrète près). Réciproquement, l’utilisateur sait qu’il s’adresse bien au service escompté(àla sécuritédu fi¬chier keytab près). De plus, en centralisant les demandes (échouées ou réussies) de connexions des clients aux services, Kerberos permet de tracer précisément l’accès de qui à quoi. Il participe ainsi à la traçabilité, le troisième ’A’. Par contre, Kerberos ne participe pas au processus d’autorisation. Celui-ci revient au service, confiant dans l’identitéde son client. Cependant, les services clas-siques des implémentations de Kerberos, ne fournissent pas de mécanisme d’au¬torisation générique. L’utilisation à des fins d’autorisation du fichier .k5login est limitée. L’intégration du support des PAM, par exemple, est difficile compte tenu principalement du fait que ce mécanisme ne garantit pas la distinction entre authentification et autorisation.

3.2 Problèmes liés aux difficultés pratiques de déploiement

Kerberos peut améliorer notablement la sécuritéd’un réseau. Cependant son déploiement est difficile, à tel point qu’on le déconseille parfois [13] :

”In our opinion, most sites are better off without it [sic].”

Ces difficultés aboutissent souvent à un compromis entre la meilleure solution du point de vue de la sécuritéet les contraintes d’administration opérationnelle. Ce paragraphe présente une liste non exhaustive de difficultés pratiques qui peuvent être rencontrées lors du déploiement de Kerberos et dont les solutions ou contournements auront des conséquences sur la sécurité.

Installation via le réseau À son installation, la machine n’est pas kerbérisée. Ce processus automatique ne peut donc pas complètement être sécurisépar Ker¬beros. Un moyen de distribuer les fichiers keytab d’une machine est d’utiliser la commande kadmin, de donner le mot de passe d’un principal privilégiéet d’ex¬traire le fichier keytab. Toute solution entièrement automatique aboutit à un certain niveau d’exposition du fichier keytab. Il est évidemment des environne¬ments oùl’intervention d’un administrateur à chaque (ré-)installation n’est pas envisageable.

Accès à un service sans mot de passe Plusieurs tâches d’administration classiques nécessitent l’accès à un service sans fournir de manière interactive l’au¬thentifiant de l’identitéutilisée. De telles procédures sont bien évidemment diffi¬cilement compatibles avec une méthode d’authentification sûre. Citons quelques exemples :

– Exécution de procédures automatiques :

L’obtention d’un TGT nécessite toujours l’utilisation de la clef secrète du principal concerné. Si une procédure automatique a besoin d’accéder à un service kerbérisé(un script en crontab par exemple), comment lui faire obtenir un TGT puis un TS pour ce service. Plusieurs solutions ont étéproposées pour résoudre ce problème [14,15]. Elles correspondent chacune à un compromis entre la sécuritéet la faisabilité. – Dépannage des utilisateurs :

Il est parfois nécessaire à un administrateur de prendre l’identitéd’un utilisateur, par exemple pour déboguer un problème qu’il n’arrive pas à reproduire dans son environnement. Que faire si ce problème nécessite l’accès à un service kerbérisé. Comment l’administrateur peut-il obtenir un TGT au nom de l’utilisateur?

Une solution évidente pour les implémentations qui utilisent un cache de ti¬cket local sur le disque dur est d’utiliser ce fichier sous root. Ceci nécessite toutefois que l’utilisateur soit simultanément connecté. Cette contrainte peut être jugée trop importante. Dans ces conditions, comment un utilisa¬teur peut obtenir le TGT d’un autre utilisateur?

Fondamentalement, un administrateur du KDC est omnipotent sur tous les principaux. Il peut donc obtenir un TGT pour un utilisateur. Cepen¬dant, certaines implémentations rendent ceci compliquési l’on ne sou¬haite pas réinitialiser le mot de passe de l’utilisateur. C’est le cas pour l’implémentation du MIT, pas pour Heimdal. De plus, la population des administrateurs des KDC n’est pas nécessairement la même que celle qui dépanne les utilisateurs.

– Exécution de commandes en mode batch :

Cette problématique regroupe les deux difficultés précédentes puisqu’il s’agit pour un processus système d’exécuter des commandes de manière automatique, au nom d’un utilisateur quelconque. Situation que l’on peut rencontrer au niveau de l’ordonnancement d’un serveur de calcul parallèle par exemple. [16] notamment propose une solution. Les relations inter royaume peuvent aussi être utilisées efficacement. Cela revient toutefois à dénaturer la sécuritéde Kerberos en redonnant aux administrateurs une partie de leur pouvoir.