Les chercheurs en sécurité Silverfort ont identifié une grave vulnérabilité qui peut permettre aux pirates de prendre le contrôle de Cisco Adaptive Security Appliance (ASA). Toutes les versions ASA sont concernées. Après avoir révélé la vulnérabilité à Cisco, Cisco a corrigé toutes les versions prises en charge d'ASA et publié un avis dessus. La vulnérabilité (CVE-2020-3125) s'est vue attribuer un score de risque CVSS de 8.1 sur 10, ce qui est considéré comme "élevé". En effet, la vulnérabilité peut permettre à un attaquant de contourner le Kerberos authentification à Cisco ASA. Silverfort les chercheurs crédités pour avoir découvert la vulnérabilité sont : Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach.

Cisco a corrigé cette vulnérabilité dans toutes les versions d'ASA. Nous recommandons fortement aux entreprises de mettre à niveau vers les dernières versions ASA pour se protéger contre un exploit.

Cet article décrit la vulnérabilité d'usurpation du KDC et montre comment elle peut être utilisée pour contourner l'authentification auprès de Cisco ASA. Il expliquera comment éviter ces vulnérabilités en tant que développeur implémentant Kerberos ainsi que les entreprises qui ont déjà implémenté ces solutions dans leurs réseaux.

Expliquer la vulnérabilité

La vulnérabilité réside dans l'implémentation Kerberos de Cisco. 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.

Cisco utilise le protocole d'authentification Kerberos dans de nombreuses interfaces ASA - par exemple, VPN, ouverture de sessions de pare-feu et accès administratif, soit via la console de gestion Web, soit via SSH. Par conséquent, le contournement de l'authentification Kerberos permet à un attaquant de prendre le contrôle de l'appliance Cisco, de contourner sa sécurité et d'accéder à d'autres réseaux.

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

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 a signalé une 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. 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à.

Comment nous avons découvert la vulnérabilité de Cisco ASA

Nous cherchions un moyen d'ajouter Authentification multi-facteurs (MFA) aux administrateurs accédant à Cisco ASA et Anyconnect VPN. Après avoir configuré Cisco pour utiliser Kerberos comme protocole d'authentification, nous avons examiné les journaux d'authentification dans Silverfortla console. Silverfort offre une visibilité complète sur toutes les activités d'authentification dans le réseau. SilverfortLes journaux de ont montré que Cisco ASA demandait un TGT sans demander de ticket de service.

Nous sommes retournés au guide de configuration Cisco. 2007. PIX/ASA : Authentification Kerberos et groupes de serveurs d'autorisation LDAP pour les utilisateurs de clients VPN via un exemple de configuration ASDM/CLI. 30 juillet. ; et examiné les paramètres requis pour configurer l'authentification Kerberos :

Comme vu ci-dessus, il n'y a pas de place pour entrer le mot de passe ou la configuration keytab pour l'authentification Kerberos. Le mot de passe ou le keytab sont requis pour une implémentation correcte car ils créent le "secret" utilisé par Kerberos pour s'authentifier de manière sécurisée auprès du KDC. Sans le « secret », l'authentification ne peut pas être sécurisée par chiffrement.

Nous sommes allés de l'avant et avons essayé la même chose pour d'autres interfaces Cisco et avons constaté que la même vulnérabilité existait lors de l'ouverture de sessions de pare-feu, de l'authentification administrative et même lors de l'utilisation de SSH pour accéder à la machine virtuelle. Voir ci-dessous la colonne Kerberos dans le tableau résumant la prise en charge de Cisco pour différents protocoles d'authentification.

Exploitation

Ensuite, nous voulions voir si cette vulnérabilité pouvait être exploitée. Pour cela, nous avons détourné le trafic Kerberos destiné au DC et l'avons détourné vers notre serveur. Au lieu de développer notre propre logique KDC, nous avons simplement installé les services de domaine AD sur notre serveur malveillant, promouvant notre serveur en tant que contrôleur de domaine. Bien sûr, n'étant pas administrateur du domaine d'origine, nous avons créé un nouveau faux domaine.

Puisque nous connaissons le nom d'utilisateur de l'administrateur Cisco dans le premier domaine (Bob dans cet exemple), nous avons créé un utilisateur nommé Bob dans notre faux domaine. Nous avons configuré le mot de passe de cet utilisateur dans notre faux domaine sur "1".

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 Cisco ASA vers une version fixe et apportez les modifications de configuration requises détaillées dans le Avis de Cisco
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. Les clients Silverfort tirent parti de la capacité d'authentification renforcée avec Palo Alto Networks doivent mettre à jour leur Silverfort Politique 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 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 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)