Palo Alto Networks a publié un avis concernant une vulnérabilité d'usurpation de KDC dans PAN-OS qui a été découverte et divulguée de manière responsable à Palo Alto Networks par Silverfort les chercheurs Yoav Iellin, Yaron Kassner ainsi que le Rotem Zach. La vulnérabilité a affecté toutes les versions prises en charge de PAN-OS et toutes les interfaces qui utilisaient un Kerberos authentification profil. Après avoir divulgué la vulnérabilité, Palo Alto Networks a corrigé toutes les versions prises en charge de PAN-OS et a publié un consultatif à ce sujet. La vulnérabilité peut permettre à un attaquant de contourner le Kerberos l'authentification à PAN-OS et accéder aux interfaces administratives de PAN-OS, ainsi que l'authentification aux sessions de pare-feu via le portail captif.

Cette vulnérabilité est similaire à une Vulnérabilité d'usurpation de KDC découverte par nos chercheurs dans Cisco ASA. Il semble que l'implémentation du protocole d'authentification Kerberos ne se fasse pas toujours correctement, laissant les systèmes vulnérables aux exploits.

Palo Alto Networks a corrigé cette vulnérabilité dans toutes les versions de PAN-OS. Nous vous recommandons vivement de déployer ce correctif pour vous protéger contre un exploit.

Cet article décrit la vulnérabilité d'usurpation du KDC dans PAN-OS et montre comment il peut être utilisé pour contourner l'authentification sans connaître le mot de passe. Il explique comment éviter ces vulnérabilités en tant que développeur implémentant Kerberos ainsi que les entreprises utilisant l'authentification Kerberos sur leurs systèmes.

Expliquer la vulnérabilité

La vulnérabilité réside dans l'implémentation Kerberos de Palo Alto Networks. Kerberos est le protocole d'authentification le plus courant pour l'authentification sur site. Il est largement disponible 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.

Palo Alto Networks utilise le protocole d'authentification Kerberos dans de nombreuses interfaces PAN-OS - par exemple, VPN SSL, portail captif ou connexion administrateur. Par conséquent, le contournement de l'authentification Kerberos permet à un attaquant d'administrer Palo Alto Networks Strata, de contourner sa sécurité et d'accéder à des réseaux supplémentaires.

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 PAN-OS avec n'importe quel mot de passe, même erroné.

Découvrir la vulnérabilité dans PAN-OS

Nous avons découvert la vulnérabilité lorsque nous avons essayé d'ajouter Silverfortde MFA aux interfaces qui s'appuient sur le protocole Kerberos, y compris le VPN SSL, le portail captif et la connexion administrateur. Pour cela, nous avons configuré Kerberos comme méthode d'authentification et configuré une politique MFA correspondante sur le Silverfort côté. Vous trouverez une explication détaillée sur le protocole Kerberos et l'usurpation du KDC à la fin de cet article.
Comme vu ci-dessous, la capture de réseau inclut un AS-REQ et un AS-REP mais aucun TGS-REQ :

L'authentification a réussi même si le TGS-REQ est requis par le protocole et manquait dans le processus d'authentification. Puisque nous avons déjà découvert un vulnérabilité similaire avec Cisco ASA, nous avons voulu vérifier cela.

Nous sommes retournés et avons vérifié le guide de Palo Alto Networks pour configurer l'authentification Kerberos - ci-dessous est une capture d'écran du guide à ce moment-là :

Nous avons réalisé que nous n'étions pas obligés de configurer un keytab ou un mot de passe de service à aucun moment du processus de configuration. PAN-OS fournit une option pour configurer un keytab, mais c'était facultatif. Cependant, même si le keytab était configuré, nous avons vu qu'il n'était pas utilisé pour le processus d'authentification auxdites interfaces. Sans keytab ou mot de passe, PAN-OS ne dispose pas des informations d'identification requises pour valider l'authenticité du KDC. Cela signifie que PAN-OS est sensible à l'usurpation du KDC.

Tenter d'exploiter la vulnérabilité

Maintenant que nous savions que PAN-OS était vulnérable, nous avons simulé une attaque en redirigeant le trafic entre PAN-OS et le KDC, en l'occurrence le contrôleur de domaine, sur le port 88 (le port Kerberos), vers notre propre serveur Windows. 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 nom d'utilisateur principal (UPN) que l'administrateur PAN-OS dans le domaine réel. Pour cet exemple, nous l'appellerons « Bob ». Nous avons configuré le mot de passe de cet utilisateur sur "1" dans le faux domaine.

Nous avons alors essayé les situations suivantes :

• Connexion régulière (trafic non détourné) - nous avons réussi à nous connecter avec le mot de passe original de Bob, 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 Bob 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. Tout d'abord, mettez à niveau votre PAN-OS vers une version fixe et apportez les modifications de configuration requises détaillées dans le Conseil de Palo Alto Networks.
2. 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.
3. Utilisez Silverfortl'outil open source de pour rechercher dans les journaux d'authentification les services qui ne demandent pas de tickets de service.
4. 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 configurés par vous-même.
5. Silverfort les clients tirent parti de la capacité d'authentification renforcée avec Palo Alto Networks doivent mettre à jour leur Silverfort MFA d'une politique TGT à une politique de ticket de service après la mise à niveau de leur PAN-OS.

En tant que développeur

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 Kerboros 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 les RFC du protocole. Nous vous recommandons de prendre la voie la plus simple et d'utiliser une implémentation existante de ces protocoles.
4. Utilisez 3^rd bibliothèques de fête correctement - environ 3^rd les 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-krb5 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)

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 les utilisateurs se connectent, ils entrent leurs 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, qui a ensuite cofondé Duo security, a signalé une technique utilisé pour contourner le protocole Kerberos dans certaines situations :

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. Obtenez un nom d'utilisateur autorisé à accéder au service que vous souhaitez attaquer.
3. Créez un utilisateur dans le faux KDC avec un mot de passe au choix de l'attaquant. Pour la démonstration, 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 d'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à.