Troisième vulnérabilité d'usurpation de KDC identifiée – Cette fois dans IBM QRadar [CVE-2019-4545]

*****Par Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach, Silverfort*****

L'usurpation d'identité KDC ne vieillit jamais. Nous avons révélé des vulnérabilités d'usurpation de KDC dans Cisco ASA ainsi que PAN-OS de Palo Alto Networks en mai 2020. Maintenant, nous pouvons partager qu'IBM QRadar est également vulnérable en raison de la façon dont Kerberos a été mis en place.
La vulnérabilité KDC Spoofing permet à un attaquant de contourner l'authentification Kerberos auprès de QRadar et, par conséquent, d'obtenir un accès administratif au système. Nous avons travaillé en étroite collaboration avec les ingénieurs d'IBM pour aider à résoudre ce problème, résultant de la récente publication bulletin de sécurité . Ce billet de blog décrit la vulnérabilité, explique comment éviter ces vulnérabilités en tant que développeur implémentant Kerberos et parle de l'atténuation pour les organisations utilisant QRadar et d'autres systèmes utilisant Kerberos.

Expliquer la vulnérabilité

IBM QRadar Security Information and Event Management (SIEM) aide les équipes de sécurité à détecter et hiérarchiser les menaces dans l'entreprise, et fournit des informations importantes qui permettent aux équipes de réagir rapidement pour réduire l'impact des incidents.
La vulnérabilité réside dans l'implémentation par IBM du protocole Kerberos. 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.
IBM utilise le protocole d'authentification Kerberos pour authentifier l'accès administratif. Par conséquent, le contournement de l'authentification Kerberos permet à un attaquant d'obtenir un accès administratif à IBM QRadar, d'afficher des informations sensibles et éventuellement de modifier les journaux, 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 QRadar avec n'importe quel mot de passe, même erroné.

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

Comment nous avons découvert la vulnérabilité dans QRadar

L'accès administrateur à QRadar doit être protégé par une authentification forte pour empêcher l'accès non autorisé et la falsification du système. L'authentification AD est une option populaire :
Lorsqu'un administrateur s'authentifie auprès de QRadar, il utilise un certain nombre de paramètres pour authentifier l'administrateur (voir ci-dessous un instantané du guide de mise en œuvre tiré de ici). Tout d'abord, QRadar demande un TGT à AD. Après avoir reçu le TGT, QRadar demande un ticket de service pour l'authentification LDAP au contrôleur de domaine. En cas de succès, QRadar utilise SASL pour s'authentifier avec LDAP auprès du DC. Il utilise le ticket de service pour prouver l'identité de l'utilisateur.

Usurper l'authentification Kerberos/SASL

Voici les étapes qu'un attaquant suivra pour usurper un DC afin de contourner ce type d'authentification. Supposons que nous ayons la possibilité de détourner la communication réseau entre QRadar 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 lançons une authentification auprès de QRadar et utilisons l'utilisateur et le mot de passe que nous avons choisis. QRadar 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 côté QRadar repose sur le mot de passe que nous avons choisi, QRadar ne doit pas rejeter l'authentification à ce stade. Maintenant que QRadar a reçu le ticket de service, il peut initier une demande LDAP au DC. Nous détournerons également le trafic LDAP. Nous avons deux options à ce stade :
1. LDAP est utilisé sans TLS. Dans ce cas, nous pouvons détourner le trafic LDAP. QRadar envoie une demande de liaison au DC avec un message Kerberos AP_REQ, qui contient le ticket de service dont nous disposons. Nous pouvons renvoyer un AP_REP basé sur la clé de session de service que nous avons choisie, et QRadar l'acceptera.
2. LDAPS a été configuré. Dans ce cas, nous ne pouvons pas renvoyer de réponse au nom du DC, car TLS est utilisé pour authentifier le DC, c'est-à-dire en supposant que le certificat a été configuré du côté QRadar.

Usurpation de l'authentification Kerberos/SASL/LDAPS pour QRadar

Avant d'abandonner l'option 2, nous avons remarqué le comportement étrange suivant. Si nous configurons une adresse IP comme URL du serveur, l'authentification fonctionne toujours. Théoriquement, l'authentification avec une adresse IP ne devrait pas fonctionner, car Kerberos n'autorise pas l'authentification aux adresses IP à moins qu'un SPN ait été explicitement configuré.
Lors de l'envoi de TGS_REQ, QRadar demande un ticket à ldap/. Étant donné que le contrôleur de domaine n'a pas de nom principal de service (SPN) portant ce nom, il renvoie une erreur KRB_ERR_S_PRINCIPAL_UNKOWN. Selon le protocole Kerberos, QRadar est censé refuser l'authentification à ce stade. Cependant, une capture réseau révèle qu'une demande LDAP est ouverte même après l'erreur et immédiatement réinitialisée par QRadar. Ensuite, l'utilisateur peut se connecter. Nous concluons que QRadar considère l'authentification comme réussie avant même la fin de l'échange d'application Kerberos. Cela peut être facilement exploité. En tant qu'attaquants, nous pouvons envoyer un KRB_ERR_S_PRINCIPAL_UNKOWN juste après avoir usurpé l'AS_REP, et nous pouvons forcer QRadar à accepter une authentification avec un mot de passe de notre choix. L'attaque est illustrée ci-dessous.

Un bogue supplémentaire dans QRadar l'amène à demander l'authentification à AD pour un utilisateur qui n'existe pas nécessairement. QRadar dispose d'un utilisateur administrateur local intégré. Il s'avère que lors d'une tentative d'authentification avec l'utilisateur admin, QRadar essaie d'abord de s'authentifier auprès du DC avec Kerberos. Ce nom d'utilisateur n'a pas à exister dans AD. Cela facilite l'attaque, car le nom d'utilisateur est connu à l'avance de l'attaquant.

De plus, ce bogue pourrait être considéré comme une vulnérabilité en soi. Indépendamment de KDC Spoofing, si un attaquant peut obtenir des privilèges pour créer des utilisateurs dans AD, par exemple, en prenant le contrôle d'un compte d'assistance, l'attaquant peut créer un utilisateur appelé admin dans AD. L'attaquant peut ensuite utiliser cet utilisateur pour s'authentifier auprès de QRadar.

Exploitation

Maintenant que nous savions que QRadar était vulnérable, nous avons simulé une attaque en redirigeant le trafic entre QRadar et le KDC (dans ce cas, un 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 UPN que l'administrateur QRadar 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 situations suivantes :
– Connexion régulière (trafic non détourné) – nous avons réussi à nous connecter avec le mot de passe d'origine de l'administrateur, 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é.

Atténuation d'IBM

L'approche d'IBM pour atténuer cette vulnérabilité est simple et sécurisée. Étant donné que la même fonctionnalité d'authentification à QRadar peut être obtenue avec LDAPS, l'atténuation recommandée consiste simplement à passer de Kerberos à l'authentification LDAPS. Après cela, vous devez installer le correctif par IBM. Le correctif vérifiera que l'authentification est bien définie sur LDAPS et échouera si vous n'êtes pas encore passé à l'authentification LDAPS. Cela permet de s'assurer que votre système est sécurisé après le correctif.

Si vous avez utilisé Silverfort pour sécuriser l'authentification à votre QRadar, vous devrez également mettre à jour le Silverfort stratégie pour QRadar pour protéger l'authentification LDAPS plutôt que la demande Kerberos TGT.

Prévention et atténuation

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

1. Basculer l'authentificationdans votre QRadar de Kerberos à LDAPS
2. Mettez à niveau votre QRadar vers une version fixe
3. Mettez à jour votre Silverfort politique pour QRadar 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. Utiliser 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 configurés vous-même.

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. Validez 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 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?
Nous avons découvert une autre vulnérabilité d'usurpation de KDC et espérons en parler bientôt, mais pas avant que le fournisseur ne publie un correctif. Jusque-là, restez à l'écoute.

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. 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'échange AS, 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, renvoyez tout 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à.