Introduction

L'état d'esprit de l'adversaire est une qualité indispensable pour les opérateurs offensifs dans une équipe rouge. Chaque évaluation apporte ses propres limites et «trophées». Les opérateurs doivent s'aligner sur les limites de l'environnement telles que : les modèles de hiérarchisation sécurisés, les solutions de pointe de détection et de réponse aux terminaux, etc. les moyens les plus créatifs possibles pour contrôler les actifs et les environnements critiques.

Dans une évaluation récente, comme dans tout autre engagement de l'équipe rouge, cela a commencé par la phase de reconnaissance. Au cours de cette phase, nous rassemblons les actifs accessibles sur Internet qui sont associés à l'organisation du client. Après avoir collecté et analysé les données de reconnaissance, nous avons réalisé que la surface d'attaque était assez étroite, sans versions exploitables de logiciels Internet, et que l'ingénierie sociale était réservée en dernier recours. Certains actifs que nous avons trouvés ont été déterminés comme des portails VPN GlobalProtect. Après plusieurs tentatives de connexion et d'authentification, il a été déterminé que l'authentification au portail GlobalProtect était appliquée avec une authentification multifacteur. Comme c'était notre seul moyen de prendre pied dans l'environnement interne de l'organisation, nous avons décidé d'étudier plus avant les interfaces GlobalProtect.

Principes de base du VPN GlobalProtect

Le VPN GlobalProtect de Palo Alto est basé sur des demandes et des réponses HTTPS et des ensembles de données XML de configurations. Le VPN comporte deux composants principaux qui sont engagés par un utilisateur final : le portail et la passerelle . Le travail du portail est : premièrement, d'agir comme un serveur Web qui héberge le client de GlobalProtect pour Windows et MacOS. Deuxièmement, il fournit les configurations client officielles de Palo Alto et la liste des passerelles disponibles. Le but de la passerelle est de fournir le tunnel SSLVPN brut que nous connaissons et aimons, pour sécuriser la session de l'utilisateur final à l'entreprise.

Le flux client officiel de Palo Alto est :

1. Connectez-vous au portail
2. Obtenir une configuration et une liste de passerelles
3. La passerelle est sélectionnée automatiquement ou par la sélection manuelle de l'utilisateur
4. Connectez-vous à la passerelle
5. Fournir un rapport HIP (Host Information Profile)
6. Si tout se passe bien, connectez-vous au VPN et à la session sécurisée

TL; DR Il semble que l'application de la MFA soit cruciale à la fois dans le portail et dans la passerelle, car ce sont des composants indépendants .

Plonger dans le flux d'authentification

Lors de la première connexion avec le client officiel de GlobalProtect, nous voyons la première requête POST envoyée au portail par son URL qui pointe vers/global-protect/prelogin.esp

Les requêtes seront ajoutées avec les variables d'environnement du client telles que : "kerberos-support", "client-os", "os-version", "ipv6-support", etc.

Le serveur répondra alors avec un cookie "PHPSESSID" et un ensemble de données XML avec le statut de la demande, et en cas de succès, il joindra également les étiquettes de connexion pour le client, telles que : "Entrez le jeton MFA" ou "Entrez Mot de passe."

Une fois que l'utilisateur a entré ses informations d'identification, le client enverra la demande suivante à /global-protect/getconfig.esp, en envoyant les mêmes informations que la demande précédente avec les informations d'identification qui y sont attachées.

Si l'authentification réussit, le serveur enverra un ensemble de données XML qui comprend : la configuration du serveur, la version, les informations sur l'hôte du client à collecter et, le cas échéant, les vérifications personnalisées à effectuer. Les vérifications personnalisées sont des vérifications de conformité spéciales créées par les administrateurs VPN, telles que des clés de registre spéciales que la machine doit définir pour être conformes. La liste des passerelles et leurs configurations est également incluse dans la réponse.

La requête suivante vise la passerelle, et la même séquence d'authentification qu'au début du portail, mais cette fois vers le point de terminaison de la passerelle : /ssl-vpn/prelogin.esp.

La phase de pré-connexion est la même qu'avec le portail, en envoyant les variables d'environnement du client au serveur. Le serveur répond par un statut, les libellés du formulaire d'authentification et installe un cookie « PHPSESSID ».

Après avoir reçu un ID de session et s'être authentifié, la demande suivante est ce qui différencie l'authentification du portail et de la passerelle. La demande est envoyée à /ssl-vpn/login.esp, avec les informations d'identification de l'utilisateur en annexe, et en réponse, le serveur envoie plusieurs arguments sans titre qui ressemblent à : MTU, domaine DNS, le « authcookie » qui sera utilisé dans la prochaine demande, et d'autres variables de configuration.

Le client analyse ensuite correctement l'ensemble de données XML et ajoute ces variables, y compris le "authcookie", à sa prochaine requête à /ssl-vpn/getconfig.esp. Le serveur répond avec un état de réponse et plus de variables de configuration, mais cette fois, elles sont toutes intitulées et plus de variables sont envoyées, telles que les chiffrements à utiliser, les protocoles de la passerelle, l'IP de tunnel préféré à utiliser, etc.

La phase finale est une requête GET à /ssl-tunnel-connect.sslvpn, avec le nom d'utilisateur et "authcookie" ajoutés. Ceci lance la session VPN avec une réponse du serveur de " START_TUNNEL".

Une erreur de configuration loin de contourner MFA

Comme nous l'avons vu dans le chapitre précédent, la séquence VPN repose sur deux composants indépendants qui nécessitent deux flux d'authentification distincts.
Comme celles-ci sont indépendantes, chacune des séquences d'authentification pourra être engagée manuellement. Cela signifie que si nous connaissons déjà les informations de la passerelle, il n'est pas nécessaire de passer par le portail pour obtenir une liste des passerelles, nous ne pouvons nous authentifier qu'une seule fois, avec des informations d'identification valides, et toujours pouvoir obtenir une connexion VPN.

Dans cette évaluation récente, nous avons constaté qu'un jeton MFA est demandé par le portail uniquement , tandis que la passerelle demande des informations d'identification de domaine. Le service informatique et les développeurs de Palo Alto GlobalProtect comptaient sur leur utilisation client interne uniquement, sans aucune adaptation externe à l'esprit. Bien que ne pas appliquer MFA à la passerelle soit sûr lors de l'utilisation du client officiel, ce n'est pas sûr lors de l'utilisation d'autres clients open source ou auto-construits. C'est la partie où il est également important de mentionner que cela est uniquement dû à une mauvaise configuration, plutôt qu'à une vulnérabilité de la solution VPN de Palo Alto.

Heureusement, les gars d' InfraDead ont déjà fait leurs recherches sur GlobalProtect pendant qu'ils développaient le client VPN open source OpenConnect qui prend en charge plusieurs fournisseurs et technologies VPN, dont Palo Alto GlobalProtect . Dans leur documentation, ils précisent :

« Les VPN GlobalProtect contiennent en fait deux interfaces serveur différentes : les portails et les passerelles. La plupart des VPN ont un serveur de portail et un ou plusieurs serveurs de passerelle ; le serveur hébergeant l'interface du portail héberge souvent également une interface de passerelle , mais pas toujours. L'interface du portail envoie principalement des paramètres de sécurité/verrouillage imposés de manière centralisée pour que le logiciel client officiel suive. La seule information envoyée par le portail qui est clairement utile à un client VPN comme OpenConnect (qui essaie de donner le contrôle total à l'utilisateur final) est la liste des passerelles .

Certains VPN GlobalProtect sont configurés de telle manière que le client doit s'authentifier auprès du portail avant de pouvoir accéder à la passerelle, tandis qu'avec d'autres VPN, aucune interaction avec le portail n'est nécessaire . Afin de reproduire le comportement des clients officiels, OpenConnect tente d'abord de se connecter à l'interface du portail du serveur spécifié.

Si --usergroup=gatewayest spécifié (ou, de manière équivalente, /gatewayest ajouté à l'URL du serveur, par exemple https://vpn.company.com/gateway), alors OpenConnect tentera d'ignorer l'interface du portail et de se connecter immédiatement à l'interface de la passerelle . Ceci est utile si le portail VPN GlobalProtect est mal configuré, par exemple en ne proposant pas le serveur de passerelle souhaité dans la liste qu'il fournit.

Cette fonctionnalité OpenConnect était magique à trouver car elle nous a permis d'économiser du temps de recherche et de codage coûteux.

Pas besoin de portails ici…

Étant donné que le portail et la passerelle s'exécutaient sur la même interface, il n'était pas nécessaire de rechercher d'autres passerelles (telles que d'autres ports sur le même serveur ou d'autres ressources externes).

Nous avons utilisé le client OpenConnect pour contourner le portail et nous connecter d'abord à la passerelle :
openconnect --protocol=gp --user=user_name https://vpn.company.com/gateway

Le /gatewaypoint de terminaison n'existe probablement pas sur le serveur, bien qu'il soit supprimé pendant que le client s'exécute et ne sert que d'indicateur afin qu'il commence à communiquer le /ssl-vpn/point de terminaison plutôt que /global-protect/ceux-ci.

Le client VPN nous demande les informations d'identification du domaine :

Succès! Nous sommes connectés avec succès au réseau interne !

Dans cette évaluation, bien qu'il ait été possible de se connecter et de communiquer avec les contrôleurs de domaine de l'organisation, nous ne pouvions pas communiquer avec de nombreux services et machines de domaine comme nous le pouvions depuis le client officiel. Après avoir étudié les différents comportements entre les différents systèmes d'exploitation et clients, nous avons réalisé qu'un rapport HIP valide devait être soumis. Les développeurs d'OpenConnect, ici aussi, ont eu le génie d'automatiser un script shell qui crée un faux rapport HIP. Nous avons copié celui de notre machine Windows (En entrant dans le volet des paramètres du client officiel, dans l'onglet Dépannage, cliquez sur le bouton « Collecter les journaux ». Cela créera un fichier GlobalProtectLogs.zipdans le répertoire utilisateur. Dans le dossier compressé, le rapport HIP pourrait être trouvé comme pan_gp_hrpt.xml”)
à notre ../openconnect/trojans/hipreport.sh.

Essayer de soumettre notre faux rapport : et essayer d'atteindre le service segmenté :
openconnect --protocol=gp --user=username --csd-wrapper=trojans/hipreport.sh https://vpn.company.com/gateway

Nous avons réussi à contourner à la fois la MFA et la ségrégation des machines !

De là, la connexion à Active Directory et une exploitation plus poussée de l'environnement interne de l'organisation étaient possibles.

Solution rapide

L'atténuation de cette mauvaise configuration est assez facile :

1. L'authentification multifacteur doit être appliquée à la fois sur le portail ET sur la ou les passerelles
2. Surveiller les connexions SSLVPN directes à la passerelle
3. Séparez le portail et la ou les passerelles vers différentes interfaces et ports
4. Si possible, n'autoriser que l'authentification SAML

En tant qu'opérateurs Red Team, nous visons toujours à donner à nos clients une valeur ajoutée. Chaque évaluation a ses propres obstacles, mais être extrêmement vigilant lorsque tout semble sécurisé est très utile. Au début, il semblait qu'il n'y avait pas d'actif externe à attaquer et la MFA était appliquée sur toutes les interfaces exposées à Internet, y compris le VPN GlobalProtect. Cependant, plonger plus profondément dans l'interface a révélé qu'il est dangereux de s'appuyer sur une interaction utilisateur « en temps de paix » .

Bien que le client de GlobalProtect soit sûr et ne puisse pas être modifié pour être utilisé différemment, d'autres programmes VPN peuvent l'être. Le portail et les passerelles sont des composants indépendants, ce qui signifie que nous pouvons authentifier chaque composant individuellement, tandis que le fait de ne pas appliquer la MFA sur la passerelle pourrait conduire un attaquant à s'implanter dans l'environnement interne de l'entreprise.

Écrit dans le cadre de la série « CyberTalks » de CYE, pour partager les connaissances personnelles acquises grâce à notre expérience du monde réel.