Utiliser le VPN — Explorer les techniques de post-exploitation de VPN
Synthèse
Dans ce billet de blog, les chercheurs d'Akamai mettent en évidence la menace négligée de la post-exploitation des VPN ; c'est-à-dire que nous abordons les techniques qui peuvent être utilisées par les acteurs malveillants après avoir compromis un serveur VPN pour intensifier leur intrusion.
Nos résultats incluent plusieurs vulnérabilités qui ont affecté les VPN Ivanti Connect Secure et FortiGate.
En plus des vulnérabilités, nous détaillons un ensemble de techniques non réparables qui peuvent affecter les produits Ivanti Connect Secure et FortiGate, et potentiellement d'autres serveurs VPN.
Nos recherches montrent que, dans de nombreux cas, un serveur VPN compromis pourrait permettre aux attaquants de prendre facilement le contrôle d'autres ressources critiques du réseau.
Ce billet de blog vise à sensibiliser à ces risques, et présente les meilleures pratiques devant être suivies par les défenseurs pour minimiser les risques des techniques de post-exploitation de VPN.
Introduction
Nous avons tous entendu cette histoire : une vulnérabilité critique est découverte sur un serveur VPN, puis exploitée dans la vie réelle. Les administrateurs se précipitent pour appliquer les correctifs. La panique se propage sur les réseaux sociaux.
L'année écoulée a été assez rude concernant la sécurité des VPN ; c'était comme si un mois sur deux, une vulnérabilité critique était corrigée ou découverte après une exploitation dans la vie réelle par des acteurs malveillants. Bien que ce type d'activité ait connu une augmentation significative en 2023, le phénomène n'est pas nouveau. Les attaquants cherchent depuis longtemps à exploiter les serveurs VPN parce qu'ils sont accessibles depuis Internet, exposent une importante surface d'attaque et manquent souvent de sécurité et de surveillance.
Historiquement, les serveurs VPN ont principalement été exploités à des fins malveillantes pour atteindre un seul objectif : l'accès initial. Les attaquants compromettaient le serveur VPN exposé à Internet et l'utilisaient comme tête de pont dans le réseau interne, ce qui leur permettait de mener leurs intrusions.
Bien que cette approche soit très efficace, nous nous sommes posé la question suivante : le contrôle sur un serveur VPN doit-il être considéré uniquement comme une passerelle vers le réseau ?
Ou offre-t-il d'autres possibilités ?
Le billet de blog suivant explore les techniques de post-exploitation de VPN qui peuvent être utilisées par un attaquant qui a déjà compromis un serveur VPN par d'autres moyens (OWASP, informations d'identification volées, etc.) pour atteindre des objectifs supplémentaires.
Utiliser le VPN
La principale approche utilisée par les acteurs malveillants pour exécuter des techniques de post-exploitation est de cibler le système d'exploitation du terminal. Après l'exécution de code à distance (RCE), un attaquant peut déposer un implant personnalisé sur le système d'exploitation du terminal. À partir de là, l'acteur malveillant peut contrôler tous les aspects du VPN ; par exemple, il peut accrocher des fonctions pour divulguer des informations sensibles, tenter d'échapper à la détection en manipulant les journaux ou modifier la configuration du système pour maintenir sa persistance sur le terminal.
Bien que cette approche comporte de nombreux avantages, elle présente un inconvénient majeur : son coût. Étant donné que les terminaux fonctionnent généralement sur un système d'exploitation renforcé personnalisé, la quantité d'efforts requis pour développer et maintenir un implant personnalisé pour un VPN peut être considérable. Cela signifie que les techniques de post-exploitation de VPN n'étaient généralement utilisées que par les services de cyberattaque de haut niveau des États-nations.
Explorer une approche différente
Nous avons décidé d'explorer une approche différente, une forme « plus facile » de post-exploitation de VPN. Au lieu de nous appuyer sur un implant personnalisé fonctionnant sur le système d'exploitation, nous avons décidé d'exploiter des fonctionnalités existantes du terminal. Nous nous sommes posé la question suivante : que peut accomplir un attaquant en utilisant uniquement l'interface de gestion d'un VPN ?
Cette approche, que nous avons appelée « Utiliser le VPN », présente au moins deux avantages.
Ce type d'accès peut être plus facile à obtenir qu'une RCE complète : l'accès à l'interface de gestion peut être obtenu par une vulnérabilité de contournement de l'authentification, des informations d'identification faibles ou de l'hameçonnage.
Cette approche peut être plus rentable, car nous évitons l'effort de développement d'une charge utile personnalisée.
En tant que sujets de test, nous avons choisi de cibler deux des principaux serveurs VPN sur le marché : Ivanti Connect Secure et FortiGate. Nous avons découvert 2 CVE, et un ensemble de techniques non fixes qui peuvent être utilisées par les attaquants qui contrôlent le serveur VPN pour prendre le contrôle d'autres ressources critiques dans le réseau, ce qui peut potentiellement transformer un compromis VPN en un compromis réseau complet.
Bien que nos résultats se concentrent sur FortiGate et Ivanti, nous pensons que les variations des techniques que nous avons découvertes sont susceptibles d'être pertinentes pour d'autres serveurs VPN et les terminaux en bordure de l'Internet.
Utilisation abusive des serveurs d'authentification distants
Certaines des ressources les plus intéressantes gérées par un serveur VPN sont des informations d'identification externes. Bien que les serveurs VPN prennent en charge l'utilisation d'utilisateurs locaux pour l'authentification, un serveur d'authentification externe est utilisé dans de nombreux cas.
Au lieu de conserver un ensemble distinct d'informations d'identification par utilisateur, les administrateurs peuvent choisir d'utiliser un fournisseur d'identité existant pour authentifier leurs utilisateurs. L'utilisateur envoie ses identifiants « normaux » au serveur VPN, qui sont validés via le serveur d'authentification distant (figure 1).
Figure 1 : Utilisation d'un serveur d'authentification distant pour authentifier les utilisateurs
Plusieurs types de serveurs d'authentification peuvent être utilisés à cette fin ; les deux principales options sont LDAP et RADIUS.
Nous avons identifié quelques techniques qui peuvent permettre aux attaquants de tirer parti de ce comportement pour compromettre ces informations d'identification externes, ce qui leur permet potentiellement d'accéder à des ressources supplémentaires dans le réseau.
Intercepter les informations d'identification LDAP
Une option de serveur d'authentification très populaire pour les VPN est LDAP, le plus souvent un contrôleur de domaine Active Directory (AD). Avec cette configuration, les utilisateurs peuvent accéder au VPN via leurs identifiants de domaine, ce qui en fait une option très pratique.
Lors de la configuration d'un serveur d'authentification LDAP, les informations d'identification d'un compte de service AD sont fournies pour permettre au VPN d'interroger les informations utilisateur. Un exemple de cette configuration dans FortiGate est illustré à la figure 2.
Figure 2 : Configuration du serveur d'authentification LDAP dans l'interface graphique FortiGate
Lorsqu'un utilisateur tente de s'authentifier auprès de FortiGate ou Ivanti à l'aide d'informations d'identification LDAP, le VPN les vérifie en contactant le serveur LDAP. La mise en œuvre exacte varie légèrement entre les deux, examinons donc les deux.
Authentification LDAP Fortigate
Pour valider les informations d'identification, FortiGate tente de les utiliser pour s'authentifier auprès du serveur distant. Ce processus est effectué à l'aide d'une authentification simple, ce qui signifie que FortiGate envoie le mot de passe au serveur en texte clair (figure 3).
Figure 3 : La liaison LDAP simple expose le mot de passe utilisateur en texte clair
Deux ensembles d'informations d'identification sont transmis au cours de ce processus : les informations d'identification du compte de service LDAP configuré sur FortiGate et les informations d'identification fournies par l'utilisateur qui s'authentifie. Les deux sont envoyés en texte clair.
Alors que la configuration par défaut est LDAP, FortiGate prend également en charge LDAPS et TLS, ce qui devrait empêcher la communication en texte clair.
Authentification LDAP Ivanti
L'implémentation d'Ivanti pour l'authentification LDAP est légèrement différente et prend en charge deux types de serveurs d'authentification LDAP : LDAP normal et Active Directory (figure 4).
Figure 4 : Options de serveur d'authentification Ivanti, y compris les serveurs LDAP et Active Directory
Serveur d'authentification LDAP
Avec un serveur d'authentification LDAP, le processus est assez similaire au processus de FortiGate ; c'est-à-dire que lorsque LDAP brut est utilisé, une simple liaison est effectuée, et les informations d'identification du compte de service AD et de l'utilisateur sont transmises en texte clair (figure 5).
Figure 5 : Ivanti transmettant les informations d'identification LDAP en texte clair
Toutefois, lors de la configuration d'un serveur d'authentification LDAP, le paramètre par défaut est TLS, et LDAPS est également pris en charge. Par conséquent, les instances Ivanti sont moins susceptibles d'utiliser LDAP en texte clair.
Serveur d'authentification AD
Le deuxième type de serveur d'authentification LDAP pouvant être configuré est un serveur AD. Avec cette option, l'authentification est effectuée à l'aide de Kerberos, ce qui signifie qu'aucun mot de passe n'est transmis (figure 6).
Figure 6 : Authentification LDAP sécurisée à l'aide de Kerberos
Capture des informations d'identification LDAP en texte clair
Pour FortiGate et Ivanti, lorsque le protocole LDAP en texte clair est utilisé pour authentifier un utilisateur, toutes les informations d'identification envoyées au VPN peuvent potentiellement être compromises. Cette compromission peut être effectuée par un attaquant qui se trouve entre le VPN et le serveur LDAP, ou par un attaquant qui contrôle le serveur VPN.
Comment capturer les informations d'identification sans laisser un implant sur le terminal ? Heureusement pour nous, FortiGate et Ivanti incluent tous deux une fonctionnalité de capture de paquets intégrée. En l'utilisant pour récupérer des paquets LDAP, un attaquant peut intercepter toutes les informations d'identification qui passent par le VPN (figure 7).
Figure 7 : Utilisation de la fonction de capture de paquets de FortiGate ou Ivanti pour capturer les communications LDAP
Dans les cas où un protocole sécurisé est utilisé, aucune information d'identification en texte clair n'est envoyée à partir du serveur. Malgré cela, un attaquant ayant le contrôle sur le VPN peut encore les récupérer simplement. En contrôlant le VPN, rien ne nous empêche de modifier la configuration et de la rétrograder en LDAP en texte clair.
Pour les serveurs LDAP normaux, nous pouvons tout simplement modifier la configuration en LDAP en texte clair. Pour rétrograder le serveur AD d'Ivanti, nous pouvons utiliser les détails de connexion AD pour configurer un nouveau serveur LDAP normal au lieu de celui existant. Dans les deux cas, ce changement doit être transparent pour les utilisateurs et obligera le VPN à envoyer les mots de passe en texte clair.
En résumé : Si l'authentification LDAP est utilisée, quelle que soit la configuration, un attaquant qui compromet le VPN pourra facilement obtenir des informations d'identification et basculer dans le domaine.
Enregistrement d'un serveur d'authentification indésirable
Comme nous l'avons mentionné, lors de l'authentification d'un utilisateur distant, le VPN contactera le serveur d'authentification approprié pour valider les informations d'identification fournies. Nous avons identifié une méthode qui exploite ce flux d'authentification pour compromettre toute information d'authentification fournie par un utilisateur vers le VPN.
Cette technique fonctionne en enregistrant un serveur d'authentification indésirable qui sera utilisé par le VPN lors de l'authentification des utilisateurs. Pour vous aider à comprendre comment cela peut être mis en œuvre, nous allons d'abord décrire quelques détails du processus d'authentification sur les deux VPN.
Groupes d'utilisateurs Fortigate
Les utilisateurs Fortigate peuvent se voir accorder différentes autorisations et avoir différentes stratégies appliquées. Au lieu de gérer chaque utilisateur individuellement, les utilisateurs peuvent être inclus dans des groupes d'utilisateurs, c'est-à-dire des ensembles d'utilisateurs auxquels des stratégies et des autorisations peuvent être appliquées.
Lors de la configuration d'un tel groupe, nous pouvons inclure des utilisateurs de groupes distants, c'est-à-dire des groupes présents sur un serveur d'authentification distant. Par exemple, nous pouvons inclure des utilisateurs d'un groupe AD spécifique (figure 8).
Figure 8 : Configuration d'un groupe d'utilisateurs Fortigate
Nous avons observé un comportement intéressant qui se produit lors de l'utilisation de groupes distants. Supposons que nous configurons un groupe d'utilisateurs qui comprend deux entités : un utilisateur FortiGate local et un groupe distant présent sur un serveur LDAP.
En ce qui concerne l'authentification, nous nous attendons au comportement suivant :
Lorsque le membre local du groupe s'authentifie auprès de FortiGate, ses informations d'identification sont vérifiées à l'aide de la base de données utilisateurs locale de FortiGate.
Lorsqu'un membre du groupe distant s'authentifie auprès de FortiGate, ses informations d'identification sont vérifiées à l'aide du serveur LDAP du groupe distant.
Il s'avère, cependant, que ce n'est pas vraiment le cas. Après avoir ajouté un groupe distant à un groupe d'utilisateurs, lorsqu'un membre du groupe d'utilisateurs s'authentifie, FortiGate tentera de valider ses informations d'identification à l'aide de la base de données utilisateur locale et du serveur d'authentification distant. De plus, si nous ajoutons plus d'un serveur distant à un groupe d'utilisateurs, FortiGate tentera d'authentifier les utilisateurs à l'aide de tous les serveurs d'authentification configurés.
Essentiellement, FortiGate ne fait pas correspondre un utilisateur spécifique à sa méthode d'authentification appropriée, il les essaie simplement tous. En cas de succès, l'utilisateur est authentifié.
Domaines d'authentification Ivanti
Ivanti implémente une fonctionnalité similaire aux groupes d'utilisateurs appelés domaines d'authentification. Contrairement aux groupes d'utilisateurs de FortiGate, chaque domaine d'authentification Ivanti est limité à un seul serveur d'authentification. Pour gérer les utilisateurs de différents serveurs, des domaines distincts doivent être utilisés.
Malgré cette restriction (et commodément pour nous), Ivanti nous permet de configurer un « serveur d'authentification supplémentaire » (figure 9). Cette option permet d'activer certaines configurations SSO.
Figure 9 : Configuration d'un serveur d'authentification supplémentaire pour un domaine utilisateur Ivanti
Lorsqu'un serveur d'authentification supplémentaire est configuré, Ivanti tente de valider les informations d'identification en utilisant les deux serveurs. L'authentification réussira uniquement si les deux serveurs l'approuvent.
Création d'un serveur d'authentification indésirable pour récupérer les informations d'identification
Un attaquant peut exploiter ces comportements pour récupérer les informations d'identification de tout utilisateur qui s'authentifie auprès de FortiGate ou Ivanti, en utilisant n'importe quel type de serveur d'authentification distant. En ajoutant un serveur d'authentification indésirable à un groupe d'utilisateurs ou à un domaine, nous pouvons provoquer la fuite des informations d'identification du serveur VPN vers un serveur contrôlé par un attaquant (figure 10).
Figure 10 : Ajout d'un serveur d'authentification indésirable pour compromettre les informations d'identification du client
Ces informations d'identification peuvent concerner les clients se connectant au VPN ou les administrateurs se connectant à l'interface de gestion. Toute authentification gérée à l'aide d'un groupe d'utilisateurs ou d'un domaine pourrait être piratée à l'aide de cette méthode.
Pour implémenter cela sur FortiGate, nous avons créé un groupe distant qui utilise notre serveur indésirable, puis l'avons ajouté à notre groupe d'utilisateurs cible. Avec Ivanti, nous avons simplement ajouté notre serveur indésirable comme serveur d'authentification supplémentaire pour notre domaine cible.
Désormais, chaque fois qu'un membre du groupe/domaine d'utilisateurs cible s'authentifie, le VPN tente de valider ses informations d'identification à l'aide de notre serveur (figure 11).
Figure 11 : Ajout d'un serveur d'authentification RADIUS indésirable à un groupe d'utilisateurs
Pour récupérer les informations d'identification, nous utiliserons un serveur d'authentification RADIUS. L'authentification RADIUS est pratique dans ce scénario pour deux raisons :
Les informations d'identification sont envoyées au serveur lors de la demande initiale sans vérification préalable de l'existence de l'utilisateur sur le serveur.
Les informations d'identification sont envoyées au serveur chiffrées avec une clé déterminée par l'attaquant, ce qui lui permet de récupérer les informations d'identification en texte clair (figure 12).
Figure 12 : Mot de passe chiffré dans un message d'authentification RADIUS
Le script suivant (basé sur la RFC 2865) peut décrypter les mots de passe RADIUS :
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
Une dernière remarque : comme nous l'avons mentionné, quand Ivanti utilise un serveur d'authentification supplémentaire, les deux serveurs doivent approuver l'utilisateur pour que l'authentification réussisse. Si notre serveur n'approuve pas les informations d'identification fournies, les utilisateurs ne pourront pas s'authentifier auprès d'Ivanti. Pour éviter cela, nous devons nous assurer que notre serveur RADIUS approuve toutes les informations d'identification qui lui sont fournies, ce qui peut facilement être configuré.
Extraction des secrets du fichier de configuration
Notre découverte la plus préoccupante concerne les fichiers de configuration VPN.
Parmi les différents paramètres intéressants que nous pouvons localiser dans les fichiers de configuration, l'un d'eux se distingue : les « secrets ». Les VPN stockent de nombreux secrets dans leur configuration : mots de passe des utilisateurs locaux, clés SSH, certificats et, plus intéressant encore, informations d'identification des comptes de service tiers.
Ces fichiers sensibles peuvent être obtenus par un attaquant de deux façons principales :
Après avoir pris le contrôle d'un VPN, un attaquant peut exporter la configuration du terminal via l'interface de gestion.
Un attaquant peut localiser un fichier de configuration précédemment exporté qui a été enregistré dans un emplacement public, tel qu'un dossier partagé.
Pour les protéger, les secrets sont stockés dans le fichier de configuration sous une forme chiffrée. La figure 13 montre un exemple de secret chiffré dans un fichier de configuration FortiGate.
Figure 13 : Un mot de passe chiffré dans un fichier de configuration FortiGate
Maintenant, déchiffrons quelques secrets !
Déchiffrage des secrets à partir d'un fichier de configuration FortiGate
On pourrait penser que les secrets sont hachés et ne peuvent donc pas être récupérés, mais c'est impossible. Prenez les mots de passe d'intégration, par exemple : comme le mot de passe en texte clair est requis pour se connecter au service tiers, il doit être stocké à l'aide d'un chiffrement réversible.
Cela a été prouvé dans un billet de blog de Bart Dopheide qui a étudié le processus de chiffrement de mot de passe FortiGate. Fortigate utilise AES pour chiffrer tous les secrets dans la configuration. Quelle clé est utilisée pour effectuer ce chiffrement ? Dopheide a découvert qu'une clé codée en dur unique était utilisée sur tous les appareils FortiGate. Cette clé n'a pas pu être modifiée. Le billet de blog original ne la partage pas, mais une recherche rapide sur Google vous y mènera directement.
Fortinet a assigné le CVE 2019-6693 à ce problème, et a implémenté un correctif en permettant aux utilisateurs de remplacer la clé codée en dur par une clé personnalisée.
Même après ce correctif, le problème est toujours très présent aujourd'hui. Comme la clé n'a pas été changée, les appareils FortiGate utilisent toujours la même clé par défaut. Cela signifie que si un attaquant obtenait un fichier de configuration d'un terminal FortiGate avec la configuration par défaut, il serait en mesure de décrypter tous les secrets stockés sur le terminal. Ce code implémente le processus de déchiffrage.
Bien, mais que se passe-t-il si l'administrateur FortiGate appliquait la meilleure pratique et utilisait une clé personnalisée au lieu de la clé par défaut ? Nous avons découvert que si nous contrôlons le VPN, nous pouvons encore facilement obtenir les secrets.
Le paramètre de chiffrement des données privées permet de contrôler la clé de chiffrement personnalisée. Ce qui est surprenant, c'est que les administrateurs peuvent simplement désactiver cette fonctionnalité. Ceci ne nécessite aucune connaissance de la clé actuellement configurée et rétablit le chiffrement de tous les secrets sur la clé originale codée en dur.
Rétablissement du chiffrement
Pour rétablir le chiffrement, nous pouvons utiliser les commandes suivantes de l'interface de ligne de commande FortiGate :
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
À ce stade, nous pouvons télécharger le fichier de configuration et déchiffrer les secrets en utilisant la clé par défaut connue (exactement comme nous l'avons montré précédemment).
De nombreux secrets intéressants peuvent être compromis en utilisant cette méthode. Fortigate prend en charge les intégrations avec diverses applications via la fonctionnalité « connecteur externe ». Ces connecteurs servent à diverses fins, mais la plupart d'entre eux partagent un aspect important : ils nécessitent des informations d'identification pour l'application (figure 14).
Figure 14 : Options de connecteur externe Fortigate
Cela signifie que FortiGate peut contenir des informations d'identification pour des services critiques tels que les fournisseurs de cloud, SAP, Kubernetes, ESXi, etc.
Dans certains cas, les informations d'identification nécessitent des privilèges élevés pour l'application correspondante. Par exemple, l'intégration « Poll Active Directory Server » nécessite les informations d'identification d'un compte disposant d'un accès administratif à un contrôleur de domaine, transformant potentiellement immédiatement une violation de FortiGate en une compromission complète du domaine.
Déchiffrer les secrets d'un fichier de configuration Ivanti
La situation est comparable à celle d'Ivanti. Elle est même peut-être pire.
Ivanti stocke également des secrets en utilisant un chiffrement réversible. Si nous extrayons le code du terminal et nous penchons dessus, nous trouverons rapidement la valeur secrète utilisée comme clé de chiffrement, qui est (encore une fois) une chaîne statique (figure 15).
Figure 15 : Clé de chiffrement statique Ivanti
Nous avons expurgé la clé complète, mais en examinant le début de celle-ci, nous pouvons supposer qu'elle n'a probablement pas changé depuis au moins 2015, date à laquelle Juniper possédait encore Connect Secure.
Ivanti semble avoir fait un plus grand effort pour protéger les secrets stockés, en implémentant un algorithme de chiffrement plus complexe que FortiGate. Malgré cela, ce processus est évidemment toujours réversible. Cela signifie que les secrets de toutes les instances Ivanti sont chiffrés à l'aide d'une clé statique qui ne peut pas être modifiée. Les attaquants pourraient utiliser ces connaissances pour décrypter n'importe quel fichier de configuration Ivanti.
Laisser Ivanti décrypter les mots de passe pour nous
Notre approche initiale consistait à effectuer une rétro-ingénierie du processus de chiffrement pour créer un déchiffreur. C'est une possibilité, mais< après de longues heures de recherche de code décompilé, nous avons décidé d'adopter une approche différente comme démonstration de faisabilité. Nous laissons Ivanti faire le plus gros du travail à notre place.
L'idée principale est d'utiliser une instance Ivanti dédiée appartenant à un attaquant, de la « nourrir » du mot de passe chiffré et de la laisser le déchiffrer pour nous (figure 16).
Figure 16 : Processus de déchiffrement d'un mot de passe Ivanti dans l'environnement de laboratoire d'un attaquant
Ce déchiffrement peut être effectué via les étapes suivantes :
Obtenir un mot de passe chiffré à partir d'un fichier de configuration Ivanti
Dans un environnement de laboratoire, configurer une instance Ivanti et un serveur LDAP (par exemple, un serveur Windows exécutant Active Directory)
Sur l'instance LAB Ivanti, configurer notre serveur LDAP comme serveur d'authentification qui utilise l'authentification simple
Exporter la configuration LAB Ivanti dans un fichier
Remplacer le mot de passe LDAP chiffré existant dans le fichier de configuration par le mot de passe chiffré que nous tentons de déchiffrer
Réimporter le fichier de configuration modifié dans l'instance Ivanti
Désormais, lorsque nous déclenchons une tentative d'authentification sur le serveur LDAP, Ivanti déchiffre le mot de passe de la configuration et l'envoie en texte clair au serveur LDAP. En capturant les paquets, nous pouvons obtenir le mot de passe déchiffré (figure 17).
Figure 17 : Ivanti décrypte notre mot de passe fourni et fait fuiter le résultat sur LDAP
Nous utilisons l'authentification du serveur LDAP comme « interface » avec le processus de déchiffrage, mais il est important de noter que nous ne sommes pas limités aux mots de passe LDAP. Nos tests ont montré que cette technique fonctionne pour tous les secrets stockés dans le fichier de configuration, y compris (mais sans s'y limiter) les mots de passe AD, les clés RADIUS pré-partagées et les clés API.
Mots de passe de serveur MDM en texte clair
Ivanti prend en charge quelques serveurs de gestion des terminaux mobiles (MDM) populaires comme méthodes d'authentification (figure 18).
Figure 18 : Configuration du serveur Ivanti MDM
Comme les autres serveurs d'authentification, cette intégration nécessite des informations d'identification pour le serveur MDM. Si nous inspectons la configuration du serveur MDM, nous rencontrons deux champs intéressants : « password-encrypted » (mot de passe - chiffré) et « password-cleartext » (mot de passe - texte clair). Et, malgré ce que les noms peuvent suggérer, les deux champs sont stockés en texte clair (figure 19). ♂️
Figure 19 : Configuration Ivanti MDM contenant des mots de passe en texte clair
Techniques de post-exploitation VPN dans la vie réelle
Il est probable que certaines des techniques que nous avons mises en lumière dans cet article soient déjà utilisées dans la vie réelle. Dans le rapport « Cutting Edge », qui couvrait une série de campagnes d'exploitation contre les terminaux Ivanti, les chercheurs de Mandiant ont annoncé que les attaquants étaient en mesure de compromettre le compte de service LDAP configuré sur le terminal Ivanti (figure 20).
Figure 20 : Le rapport de Mandiant mentionnant un compte LDAP compromis
Bien que le rapport Mandiant n'entre pas dans les détails sur la façon dont les attaquants ont pu atteindre cet objectif, nous croyons qu'il est assez probable que les attaquants aient pu obtenir les informations d'identification en utilisant l'une des méthodes que nous avons détaillées dans cet article ; autrement dit, soit en les extrayant du fichier de configuration, soit en reniflant le trafic réseau.
Ces types de techniques sont simples à mettre en œuvre, et nous pensons que les attaquants de tous niveaux de sophistication pourront les utiliser.
Recommandations lors de l'utilisation d'un serveur VPN
Nous recommandons quatre principes à suivre lors de l'utilisation d'un serveur VPN pour minimiser les risques liés aux techniques que nous venons de mettre en évidence :
Utiliser un accès réseau Zero Trust
Limiter les autorisations de compte de service
Utiliser des identités dédiées pour l'authentification VPN
Surveiller les modifications de configuration
1. Utiliser un accès réseau Zero Trust
L'un des principaux problèmes avec les VPN traditionnels réside dans leur approche « tout ou rien » pour accorder l'accès au réseau ; les utilisateurs sont soit « in » (et ont un accès complet au réseau), soit « out » (et ne disposent d'aucun accès).
Ces deux options posent problème. D'une part, nous devons fournir aux utilisateurs un accès à distance aux applications internes. D'autre part, nous ne voulons pas qu'un attaquant obtienne un accès complet au réseau s'il compromet un serveur VPN.
L'accès réseau Zero Trust (ZTNA) offre une solution. En définissant des stratégies d'accès réseau par entité, nous pouvons permettre aux utilisateurs d'effectuer des opérations à distance approuvées, tout en réduisant l'impact d'une violation potentielle.
Akamai Enterprise Application Access est une solution ZTNA qui offre un accès précis, basé sur l'identité et le contexte, aux applications privées. Elle utilise des stratégies basées sur l'identité et des données en temps réel telles que l'emplacement de l'utilisateur, l'heure et la sécurité des terminaux pour garantir que les utilisateurs n'ont accès qu'aux applications dont ils ont besoin. Cette solution élimine également l'accès au niveau du réseau. Elle fonctionne de manière parfaitement fluide avec Akamai MFA pour renforcer l'authentification utilisateur.
2. Limiter les autorisations de compte de service
Comme nous l'avons illustré dans cet article, il est simple de récupérer les mots de passe en texte clair des comptes de service stockés sur des serveurs VPN. Il n'existe pas de véritable moyen d'éviter cela, car les VPN nécessitent l'utilisation des mots de passe en texte clair dans certains cas.
Pour réduire l'impact d'une éventuelle compromission de VPN, nous recommandons l'utilisation de comptes de service avec un ensemble limité d'autorisations, de préférence en lecture seule. Les défenseurs doivent essayer de comprendre comment un attaquant pourrait exploiter les informations d'identification stockées sur le VPN, et s'assurer qu'une compromission du VPN ne conduira pas à une compromission d'autres ressources critiques.
Certaines intégrations nécessitent un compte de service avec des autorisations fortes pour leur fonctionnement. Si possible, elles doivent être évités.
3. Utiliser des identités dédiées pour l'authentification VPN
Nous savons maintenant qu'il est simple pour un attaquant ayant le contrôle du VPN de compromettre les informations d'identification des utilisateurs du VPN qui s'authentifient. Bien qu'il puisse être tentant d'utiliser des services d'authentification existants, tels qu'AD, pour authentifier les utilisateurs sur le VPN, nous vous recommandons d'éviter de le faire. Les attaquants qui contrôlent le VPN pourraient obtenir des informations d'identification et les utiliser pour basculer vers des ressources internes, transformant le VPN en un point de défaillance unique.
Nous vous recommandons plutôt d'utiliser une méthode distincte et dédiée pour l'authentification des utilisateurs sur le VPN. Par exemple, effectuez une authentification basée sur des certificats à l'aide de certificats émis spécifiquement à cette fin.
4. Surveiller les modifications de configuration
Les techniques que nous avons mises en évidence se refléteront toutes dans la configuration du terminal d'une manière ou d'une autre. Comme la configuration des terminaux réseau n'a pas tendance à changer fréquemment, ces changements peuvent fournir une opportunité de détection significative.
Pour identifier les modifications de configuration, nous vous recommandons d'extraire périodiquement la configuration du terminal et de la comparer avec une « image maître ». La plupart des terminaux incluent également des capacités de journalisation interne pour les événements système et de sécurité. Nous vous recommandons de collecter et d'analyser tous les journaux disponibles et de les utiliser pour identifier les modifications suspectes apportées à la configuration du terminal.
Ces quatre principes se résument tous à ceci : ne faites pas aveuglément confiance à votre VPN.
Synthèse
Les attaquants ciblent votre VPN. C'est un fait. Les défenseurs doivent supposer que ce n'est qu'une question de temps avant qu'un acteur malveillant n'ait accès à leur VPN, et ils doivent agir en conséquence dès maintenant. Ils doivent s'assurer qu'un VPN compromis ne peut pas conduire à la compromission du réseau tout entier.
Calendrier de divulgation
Ivanti
26/03/2024 : rapport initial au fournisseur
04/05/2024 : Ivanti accuse réception du rapport et confirme qu'il travaille sur un correctif
03/06/2024 : avis initial à Ivanti que nous prévoyons de publier la recherche le 7 août
27/06/2024 : Ivanti affirme travailler sur un correctif mais ne peut confirmer que les problèmes seront corrigés avant la date de publication
08/07/2024 : Ivanti attribue le CVE-2024-37374 et le CVE-2024-37375 au problème de clé codée en dur et aux mots de passe en texte clair MDM, mais n'a pas encore publié de correctif
15/07/2024 : avis supplémentaire à Ivanti concernant le calendrier de sortie prévu
07/08/2024 : publication de la recherche
Fortinet
22/03/2024 : rapport initial au fournisseur
17/04/2024 : réponse initiale de Fortinet, concluant qu'aucun des problèmes décrits ne nécessite un correctif
21/04/2024 : avis initial à Fortinet que nous prévoyons de publier la recherche le 7 août
30/04/2024 : Fortinet nous informe avoir l'intention de corriger le contournement de clé de chiffrement personnalisé que nous avons décrit
15/07/2024 : avis supplémentaire à Fortinet concernant le calendrier de sortie prévu
23/07/2024 : Fortinet déclare n'être probablement pas en mesure de publier le correctif avant la date de publication
02/08/2024 : Fortinet nous informe avoir décidé, après réflexion, de ne pas corriger le contournement de clé de chiffrement personnalisée car il « ne franchit pas une limite de sécurité »
07/08/2024 : publication de la recherche
