La faille de sécurité Orpheus’ Lyre : le dernier BWAIN au sein du protocole Kerberos

De temps en temps, une nouvelle vulnérabilité fait son apparition en faisant parler d’elle un peu plus que les autres.

Parfois, il s’agit vraiment d’un cas très sérieux qui génère de réelles inquiétudes à travers le monde, et parfois il s’agit simplement de ce que nous appelons un BWAIN, un Bug With An Impressive Name qui attire l’attention, souvent lié à un site web avec un logo pour accompagner le nom accrocheur (vous vous rappelez de Heartbleed ?).

Et parfois, pour être franc, c’est un mélange des 2 !

Le dernier BWAIN est un bug d’authentification avec le nom très chic d’Orpheus’ Lyre, mais nous allons éviter cette apostrophe plutôt pénible en désignant à partir de maintenant ce bug avec son acronyme, à savoir OL.

Bizarrement, OL n’a pas seulement son propre site web et son logo, mais aussi sa propre mélodie au niveau de son thème, qui se lance d’ailleurs automatiquement de façon assez ennuyeuse lorsque vous visitez le site OL (cette mélodie est un peu inquiétante, et sans doute cyniquement, appelée Crocodile Tears).

OL est une faille de sécurité dans un protocole d’authentification réseau appelé Kerberos, probablement connu car il est largement utilisé par Windows pour la connexion et le contrôle d’accès.

En savoir plus sur le protocole Kerberos

En bref, le protocole Kerberos est un protocole d’authentification basé sur un système de ticket.

Si le client X veut accéder au serveur Y, par exemple, il ne négocie pas directement avec le serveur Y, mais il entre en contact au préalable avec le serveur Kerberos et demande un “ticket d’accès”, ce qui permet de centraliser et de gérer correctement le processus d’authentification.

Avec le protocole Kerberos, il n’est pas nécessaire d’avoir des dizaines ou des centaines de serveurs pour stocker, gérer et valider des listes de mots de passe, une tâche qui est étonnamment facile de mal exécuter et qui peut rapidement entraîner des incohérences, des mauvaises configurations et des failles de sécurité.

Le concept derrière le protocole Kerberos ressemble beaucoup à la façon dont les tickets de train fonctionnent : les barrières de la plate-forme qui s’ouvrent pour vous permettre d’accéder à votre train ne doivent pas forcément être en mesure d’accepter les paiements, d’émettre des tickets, de rendre la monnaie ou encore de vous aider à choisir parmi les options disponibles concernant le trajet que vous avez choisi de faire. Au lieu de cela, elles ont juste besoin de savoir comment valider le ticket que vous avez déjà acheté auprès d’un automate ou d’une billetterie.

Les tickets Kerberos utilisent un chiffrement puissant afin qu’ils ne puissent pas être piratés ou modifiés après leur émission, du moins en théorie.

Si les cybercriminels peuvent modifier de façon indétectable certains des champs de données au sein d’un ticket sécurisé, ils pourraient ainsi être en mesure de prolonger la durée de  validité d’un ticket, prétendre être un utilisateur différent, échanger le ticket pour qu’il soit valide sur un autre serveur, ou encore duper un client en l’incitant à faire confiance à un serveur pirate, en lieu et place du vrai.

Des données redondantes dans le protocle Kerberos

Malheureusement, et sans doute parce que sa conception remonte aux années 1980 avant que la cybercriminalité ne devienne le phénomène qu’il est aujourd’hui, le protocole Kerberos ne chiffre pas tout ce qu’il stocke dans les tickets d’accès qu’il génère.

Certains champs de données dans un ticket Kerberos apparaissent deux fois, une fois en clair, et une autre fois chiffré.

À proprement parler, cette redondance des données n’est ni nécessaire ni souhaitable, mais elle a néanmoins un vague objectif pratique, de la même manière que les tickets de train (au Royaume-Uni, en tout cas) font apparaître la date de votre voyage et votre destination imprimées de façon illisible sur le devant, de sorte que vous puissiez rapidement et de manière informelle distinguer deux tickets, mais aussi avoir un numéro d’identification unique encodé sur ces derniers afin de pouvoir valider le ticket convenablement si nécessaire.

Vous commencez à comprendre où tout cela nous mène !

Les experts qui ont découvert la vulnérabilité OL ont réalisé, dans plus d’un lieu où Kerberos était implanté et largement utilisé, que les programmeurs étaient incompatibles.

Il existait un endroit où le logiciel se fiait à tort au nom du serveur piraté et non chiffré au niveau du ticket d’accès, au lieu de regarder la version chiffrée et protégée contre une telle falsification.

C’est un peu comme si un contrôleur dans un train partant de Central London vous demandait votre ticket, sur lequel la destination EALING BROADWAY était clairement affichée, mais qui néanmoins vous croyait sur parole lorsque vous insistiez pour dire que le ticket était en fait valable jusqu’à EDINBURGH (Édimbourg est en Écosse, une destination plus de 50 fois plus éloignée que Ealing et peut-être 15 fois plus chère au niveau du prix du ticket).

Selon les experts qui ont trouvé la faille de sécurité au sein d’OL, ce bug signifie qu’un cybercriminel sur votre réseau pourrait modifier une réponse officielle de Kerberos afin de duper un ordinateur client non patché vis à vis d’un serveur pirate.

Pour continuer notre analogie avec le train, les cybercriminels pourraient modifier les tickets Kerberos de manière non-détectable pour persuader les ordinateurs clients de voyager en toute confiance, et ce durant tout le trajet jusqu’à EDINBURGH, au lieu de descendre à EALING BROADWAY comme prévu au départ.

Résolution de ce bug

Voici comment une implantation open source populaire du protocole Kerberos appelée Heimdal décrivait de manière plutôt technique ce patch a priori incroyablement simple :

Dans _krb5_extract_ticket(), le nom du service KDC-REP doit être obtenu à partir de la version chiffrée stockée dans enc_part au lieu de la version non chiffrée stockée sur le ticket. L’utilisation de la version non chiffrée permet de mener à bien des attaques par imitation au niveau du serveur ainsi que d’autres cyberattaques.  

Sans le jargon technique, cela signifie : lorsque vous extrayez des informations à partir des réponses envoyées par le serveur d’authentification Kerberos, utilisez uniquement des champs de données protégés contre la falsification. Ignorez les données Kerberos non chiffrées, elles peuvent être modifiées de manière indétectable, du coup elles ne sont plus fiables.

Quoi faire ?

La mise en œuvre du protocole Kerberos par Windows était jusque-là vulnérable, mais elle a été corrigée dans la mise à jour de sécurité de Microsoft de juillet 2017 sous la désignation CVE-2017-8495, ainsi assurez-vous d’avoir installé les derniers correctifs de Windows.

De nombreuses implantations open source, telles que celles présentes dans diverses distributions Linux, dans le logiciel de réseau Samba et dans FreeBSD, ont été corrigées, ainsi installez les mises à jour concernant les composants Kerberos open source affectés dès que vous le pouvez.

Comme les découvreurs d’OL l’ont noté, ce bug ne peut pas être exploité par un client contre un serveur non patché, au lieu de cela, le risque est qu’un client non patché puisse être induit en erreur par un serveur pirate.

En d’autres termes, il ne suffit pas de patcher vos serveurs uniquement et de laisser tous vos autres ordinateurs en l’état.

Par ailleurs, si vous prévoyez de chiffrer quelque chose, essayez de tout chiffrer, de cette façon vous n’aurez pas à vous inquiéter d’avoir oublié de chiffrer un élément et vous ne vous retrouverez pas accidentellement dans une situation identique à celle où rien n’aurait été chiffré.

Si Kerberos avait enregistré le nom du serveur ne serait-ce qu’une fois, sous forme chiffrée, cette erreur qui a engendré cette vulnérabilité aurait été impossible à faire.

Billet inspiré de Windows security hole – the “Orpheus’ Lyre” attack explained, sur Sophos nakedsecurity.