Silverfort Des chercheurs découvrent une vulnérabilité d'usurpation de KDC dans F5 Big-IP [CVE-2021-23008]

L'année dernière, nous avons signalé trois vulnérabilités d'usurpation du centre de distribution de clés (KDC) dans Cisco ASA, PAN-OS de Palo Alto Networks ainsi que IBM QRadar. Nous avons mentionné qu'un autre allait arriver, et maintenant que F5 a publié un correctif, nous publions la quatrième vulnérabilité d'usurpation de KDC que nous avons identifiée, cette fois dans Big-IP. La vulnérabilité KDC Spoofing permet à un attaquant de contourner l'authentification Kerberos auprès de Big-IP Access Policy Manager, de contourner les politiques de sécurité et d'obtenir un accès illimité aux charges de travail sensibles. Dans certains cas, cela peut également être utilisé pour contourner l'authentification à la console d'administration Big-IP. Nous avons travaillé en étroite collaboration avec les ingénieurs de F5 pour aider à résoudre ce problème, ce qui a entraîné la avis récemment publié. Ce billet de blog décrit la vulnérabilité, explique comment éviter ces failles lors de la mise en œuvre Kerberos, et décrit les étapes d'atténuation pour les clients utilisant Big-IP et d'autres systèmes basés sur Kerberos.

Expliquer la vulnérabilité

F5 Big-IP Application Delivery Services est une solution qui fournit des applications de manière sécurisée et évolutive. L'un de ses composants principaux est Access Policy Manager (APM), qui gère et applique les politiques pour s'assurer que l'accès est correctement authentifié et autorisé. APM est parfois également utilisé pour protéger l'accès à la console d'administration Big-IP.

La vulnérabilité réside dans l'implémentation du protocole Kerberos par F5. Kerberos est le protocole d'authentification le plus courant pour l'authentification sur site. Il est largement utilisé dans les réseaux d'entreprise en raison de la popularité de Active Directory, et il est préféré aux protocoles d'authentification plus faibles tels que NTLM.

Kerberos peut être utilisé comme protocole d'authentification pour l'authentification requise par une politique APM. Lorsqu'un utilisateur accède à une application via Big-IP, un portail captif peut lui être présenté et il lui est demandé de saisir un nom d'utilisateur et un mot de passe. Le nom d'utilisateur et le mot de passe sont vérifiés par rapport à AD avec le protocole Kerberos pour s'assurer que l'utilisateur est bien celui qu'il prétend être. Par conséquent, le contournement de l'authentification Kerberos permet à un attaquant d'accéder aux applications Big-IP, sans disposer d'informations d'identification légitimes.

Pour que le protocole Kerberos fonctionne, trois choses doivent se produire :

1. L'utilisateur s'authentifie auprès du serveur
2. Le serveur s'authentifie auprès du client
3. Le KDC s'authentifie auprès du serveur

Apparemment, l'authentification KDC au serveur est souvent négligée. Peut-être parce que l'exiger complique les exigences de configuration. Cependant, si le KDC ne s'authentifie pas auprès du serveur, la sécurité du protocole est entièrement compromise, permettant à un attaquant qui a piraté le trafic réseau de s'authentifier auprès de Big-IP avec n'importe quel mot de passe, même invalide.

Pour la terminologie Kerberos et le contexte du fonctionnement d'une attaque d'usurpation KDC, consultez la fin de cet article de blog.

Vous trouverez ci-dessous une capture d'écran des instructions de configuration de l'authentification AD pour une politique d'accès, extraite du site F5.

Après cette configuration, lorsqu'un utilisateur tente de s'authentifier auprès d'une application située derrière le proxy, l'utilisateur est invité à saisir un nom d'utilisateur et un mot de passe. Lorsque l'utilisateur saisit son mot de passe, le produit utilise Kerberos pour s'authentifier auprès du contrôleur de domaine (DC). Cependant, APM ne demande pas de ticket de service et accorde l'accès en fonction d'un AS_REP réussi.
Contrairement à d'autres scénarios, F5 vous permet de configurer un nom d'utilisateur et un mot de passe d'administrateur.

Théoriquement, ce mot de passe pourrait être utilisé pour authentifier le DC et prévenir la vulnérabilité. Cependant, il n'est pas utilisé à ces fins, mais uniquement dans le but d'extraire des groupes principaux ou imbriqués, d'inviter l'utilisateur à modifier son mot de passe ou d'effectuer une vérification de la complexité ou une réinitialisation du mot de passe.

Usurper l'authentification Kerberos

Voici les étapes qu'un attaquant peut suivre pour usurper un DC afin de contourner ce type d'authentification. Supposons que nous ayons la capacité de détourner la communication réseau entre Big-IP et le DC. Dans ce cas, nous pouvons créer un faux DC avec un nom d'utilisateur identique au nom d'utilisateur de l'administrateur et un mot de passe de notre choix. Ensuite, nous initions une authentification à Big-IP et utilisons l'utilisateur et le mot de passe que nous avons choisis. Big-IP s'authentifie auprès de Kerberos, et nous détournons la communication Kerberos et renvoyons un AS_REP qui correspond au mot de passe que nous avons choisi ; et un TGS_REP qui consiste en un ticket de service, chiffré avec une clé de session de service de notre choix, et une clé de session de notre choix, chiffrée avec le mot de passe que nous avons choisi. Étant donné qu'à ces phases, la seule vérification effectuée du côté de Big-IP repose sur le mot de passe que nous avons choisi, Big-IP autorisera l'authentification.

Exploitation

Nous avons simulé une attaque en redirigeant le trafic entre Big-IP et le KDC (dans ce cas un contrôleur de domaine) sur le port 88 (le port Kerberos) vers le nôtre Windows Server. Nous avons configuré un faux domaine sur le serveur Windows et nous nous sommes assurés qu'il existe un utilisateur avec le même UPN que l'administrateur Big-IP dans le domaine réel. Nous avons configuré le mot de passe de cet utilisateur sur "1" dans le faux domaine.

Nous avons alors essayé les scénarios suivants :

• Connexion régulière (trafic non détourné) - nous avons réussi à nous connecter avec le mot de passe d'origine de l'utilisateur, comme prévu. Lorsque vous essayez le mot de passe "1", la connexion a échoué.
• Connexion avec le trafic détourné vers notre faux DC - la connexion avec le mot de passe d'origine de l'administrateur a échoué, mais la connexion avec le mot de passe "1" a fonctionné.

Prévention et atténuation

Étapes d'atténuation pour les professionnels de la sécurité

1. Mettez à niveau votre Big-IP vers une version fixe
2. Si une version fixe n'est pas disponible pour la version de Big-IP que vous utilisez, assurez-vous MFA est autorisé.
3. Mettez à jour votre Silverfort politique pour Big-IP en conséquence
4. Surveillez en permanence votre authentification Kerberos. Recherchez les ressources qui demandent uniquement AS_REQ. S'il n'y a pas de TGS_REQ, c'est un drapeau rouge.
5. Utilisez Silverfortl'outil open source de pour rechercher dans les journaux d'authentification les services qui ne demandent pas de tickets de service.
6. Consultez les recommandations des développeurs pour toutes les applications développées en interne qui implémentent Kerberos et les systèmes que vous avez vous-même configurés.

Pour les développeurs

Nous recommandons quelques étapes pour vous assurer que votre solution n'est pas susceptible d'être usurpée par le KDC :

1. Valider que l'implémentation de Kerberos nécessite un mot de passe ou un keytab : Pour valider le DC, vous devez utiliser une sorte de secret partagé. Si votre solution ne permet pas de configurer un fichier keytab ou un compte de service mot de passe, l'application est sûrement susceptible d'être usurpée par le KDC.
2. Exécutez Wireshark - utilisez Wireshark pour voir quelles demandes Kerberos sont envoyées lors de l'authentification. S'il n'y a pas de TGS_REQ, c'est un drapeau rouge.
3. Si vous souhaitez implémenter vous-même un protocole d'authentification, vous devez suivre scrupuleusement la spécification du protocole. Nous vous recommandons de prendre la voie la plus simple et d'utiliser une implémentation existante de ces protocoles.
4. Utilisez correctement les bibliothèques tierces - certaines bibliothèques tierces nécessitent une configuration spécifique pour éviter l'usurpation du KDC. Par exemple, une bibliothèque commune utilisée pour Kerberos appelée pam-krb3 doit avoir un keytab configuré pour fonctionner correctement. Voici le paragraphe pertinent de leur documentation (https://github.com/rra/pam-krb5/blob/master/README.md)

Quelle est la prochaine étape?

Je suis sûr que c'est la dernière vulnérabilité d'usurpation de KDC que nous rencontrerons jamais.

Contexte

Présentation du protocole Kerberos

Le protocole d'authentification Kerberos a été développé dans les années 1980 par Steve Miller et Clifford Neuman. Il permet l'authentification unique (SSO) dans un réseau géré et son Active Directory (AD) en a fait le principal protocole d'authentification pour les environnements d'entreprise sur site.
Le protocole se compose de trois échanges pour fournir une authentification mutuelle pour l'utilisateur et le serveur accédé. Lorsque l'utilisateur se connecte, il entre ses informations d'identification et l'échange du service d'authentification (AS) a lieu. L'utilisateur reçoit un ticket d'octroi de tickets (TGT), qui est ensuite utilisé pour obtenir des tickets pour des services spécifiques lors de l'échange du service d'octroi de tickets (TGS). Le ticket est ensuite utilisé lors de l'échange client/serveur pour terminer l'authentification :

1. Échange de service d'authentification (AS)

Au cours de l'échange AS, l'utilisateur s'authentifie auprès du centre de distribution de clés (KDC). En retour, l'utilisateur obtient le ticket et la clé nécessaires pour s'authentifier auprès des services du réseau sans ressaisir les informations d'identification. Lorsque l'utilisateur entre les informations d'identification pour la première fois, le client envoie un AS_REQ à la fonction de service d'authentification (AS) du KDC. L'AS_REQ est un message signé par la Master Key, fonction du mot de passe de l'utilisateur. Le service d'authentification, qui fait partie du KDC, vérifie l'AS_REQ en fonction de la clé principale, qui est également disponible pour le KDC. Après validation de l'AS_REQ, le KDC renvoie un AS_REP, qui contient une clé de session de connexion et un Ticket-Granting Ticket (TGT), qui est chiffré avec la clé du KDC. L'échange AS est décrit ci-dessous. Le TGT sera utilisé par le central TGS pour obtenir l'accès à des services spécifiques.

2. Échange de service d'octroi de billets (TGS)

Lorsque l'utilisateur tente d'accéder à un service dans le réseau, l'utilisateur envoie un TGS_REQ à la fonction Ticket Granting Server (TGS) du KDC. Ce message est chiffré avec la clé de session de connexion, qui est obtenue lors de l'échange AS. Le TGS_REQ est vérifié par le TGS, qui renvoie alors un TGS_REP. Le TGS_REP contient une clé de session de service et un ticket de service, qui est chiffré avec la clé principale du serveur qui héberge le service. La clé principale du serveur dans un système basé sur Unix est configurée dans un fichier appelé fichier keytab. La clé principale du serveur dans un serveur membre est dérivée du mot de passe du compte d'ordinateur. L'échange TGS est décrit ci-dessous.

3. Échange client/serveur

Le client dispose désormais de tout ce dont il a besoin pour s'authentifier auprès du service. Le client envoie un AP_REQ au service, qui est chiffré avec la clé de session de service. Le service déchiffre la clé de session de service pour valider l'AP_REQ. Ensuite, le serveur renvoie un message AP_REP et l'authentification est terminée. L'échange client-serveur est décrit ci-dessous :

Protocole anti-usurpation

Lorsque le protocole Kerberos est implémenté correctement, un attaquant tentant d'usurper l'identité du KDC ne peut pas contourner l'authentification. En effet, même si un attaquant réussit à créer un AS_REP valide en réponse à un AS_REQ piraté, l'attaquant ne sera jamais en mesure de concevoir un ticket de service valide. Comme le ticket de service est crypté avec la clé du serveur, une clé que l'attaquant ne possède pas, cela serait impossible.

Qu'est-ce que l'usurpation d'identité KDC ?

En 2000, Dug Song a rapporté un vulnérabilité qui affecte le protocole Kerberos (Chanson, Dug.2000. Vulnérabilité d'usurpation du KDC Kerberos. 28 Août.).

Il a découvert que certaines implémentations et configurations de clients Kerberos ne parvenaient pas à exécuter l'échange Client/Serveur, et permettaient l'authentification basée sur le succès des échanges précédents. Malheureusement, ce comportement n'est pas sécurisé et peut être exploité par un attaquant. Un attaquant capable de détourner la communication entre le client et le DC peut suivre les étapes suivantes :

1. Créez un faux KDC.
2. Obtenir un nom d'utilisateur autorisé à accéder au service qu'ils veulent attaquer.
3. Créez un utilisateur dans le faux KDC avec un mot de passe au choix de l'attaquant. Par exemple, appelons ce mot de passe "1".
4. Authentifiez-vous auprès du service avec le nom d'utilisateur obtenu et le mot de passe « 1 ».
5. Détourner la communication du client vers le DC et la détourner vers le faux KDC.
6. Lors de l'AS Exchange, renvoyez un AS_REP qui correspond au mot de passe "1", la fausse clé KDC et une fausse clé de session de connexion.
7. Pendant l'échange TGS, retournez n'importe quel TGS_REP.
8. Le client acceptera l'authentification sans effectuer d'échange d'application.

Les attaques d'usurpation de KDC supposent que l'attaquant est capable de détourner le trafic vers et depuis le KDC et de répondre au nom du KDC. Cela peut être fait en utilisant une variété de techniques. Par exemple, si l'attaquant se trouve dans le même segment de réseau physique que le client, il peut effectuer une attaque d'usurpation ARP comme indiqué dans Network Security Hacks (Lockhart 2007). Une autre approche possible consiste à prendre en charge un périphérique réseau tel qu'un commutateur ou un routeur et à contrôler la communication à partir de là.

Remerciements

La recherche et la découverte de cette vulnérabilité ont été un effort conjoint avec Thierry Van Steirteghem, qui travaillait chez Exclusive Networks au moment de la découverte.