menacées . Pour aggraver les choses, Citrix ADC est installé à l'interface entre le réseau externe et interne d'une organisation. Ainsi, après avoir exploité la vulnérabilité, l'attaquant accède immédiatement au réseau interne de l'entreprise et a la capacité de développer des attaques sur le segment du réseau privé. Dans l'article d'aujourd'hui, l'auteur de l'étude analysera plus en détail la vulnérabilité, les détails de sa détection et de son exploitation. Aller!
Qu'est-ce que Citrix ADC
Citrix ADC est une solution logicielle de distribution d'applications et d'équilibrage de charge spécialement conçue pour accélérer les performances des applications traditionnelles, cloud et Web, quel que soit l'endroit où elles sont hébergées. Ces contrôleurs sont les plus largement utilisés dans les industries des technologies de l'information et des télécommunications. Selon les prévisions, d'ici 2023, la demande d'ADC augmentera de la part des sociétés financières et d'assurance.
Quelle est la gravité
Lors de la surveillance des menaces actuelles (renseignements sur les menaces), il a été constaté qu'au moins 80 000 entreprises de 158 pays sont potentiellement vulnérables. Au moment où la vulnérabilité a été découverte, le TOP-5 par le nombre de ces organisations comprenait les États-Unis d'Amérique (le leader absolu - plus de 38% de toutes les organisations vulnérables sont situées aux États-Unis), l'Allemagne, la Grande-Bretagne, les Pays-Bas et l'Australie.
La Russie se classait au 26e rang pour le nombre total d'entreprises potentiellement vulnérables dans divers secteurs d'activité - plus de 300 organisations au total. Le Kazakhstan et la Biélorussie se sont classés respectivement 44e et 45e en termes de nombre d'entreprises vulnérables.
En février 2020, les principaux pays en termes de nombre d'organisations potentiellement vulnérables étaient le Brésil (43% du nombre d'entreprises dans lesquelles la vulnérabilité a été initialement identifiée), la Chine (39%), la Russie (35%), la France (34%), Italie (33%) et Espagne (25%). Les meilleures dynamiques d'élimination des vulnérabilités ont été montrées aux États-Unis, au Royaume-Uni et en Australie: dans ces pays, 21% des entreprises ont été enregistrées qui continuaient à utiliser des appareils vulnérables et ne prenaient aucune mesure de protection.
Découverte et fonctionnement
Au tout début de mes recherches, j'ai trouvé qu'en utilisant Path Traversal, un utilisateur non autorisé a la possibilité d'accéder à des fichiers statiques qui ne sont pas accessibles sans autorisation (/vpn/../vpns/style.css). Cela a été trouvé lors d'une analyse Black Box du Citrix ADC.
Le comportement décrit ci-dessus m'a intéressé, j'ai donc décidé de trouver l'image Citrix ADC et de l'exécuter localement (merci à mon collègue Yuri Aleinov pour son aide).
Tout d'abord, nous avons analysé la configuration du serveur Web Apache (/etc/httpd.conf), qui est responsable de l'interface Web de cette application. Comme nous pouvons le voir sur l'image ci-dessous, les chemins relevant du modèle " /vpns/portal/scripts/.*\.pl$ " sont traités par la fonction ModPerl :: Registry. Il s'avère qu'il est possible d'exécuter des scripts perl à partir du dossier/ netscaler / portal / scripts / sans autorisation.
Après cela, j'ai commencé à analyser les scripts que nous pouvons appeler en allant dans /vpn/../vpns/portal/scripts/ [scriptName] .pl .
Presque tous les scripts appellent la fonction csd du module NetScaler :: Portal :: UserPrefs ( /netscaler/portal/modules/NetScaler/Portal/UserPrefs.pm ). La fonction fonctionne avec les en-têtes HTTP NSC_USER et NSC_NONCE. Aucune action intéressante n'est effectuée avec le deuxième en-tête, mais la valeur de l'en-tête NSC_USER est utilisée comme nom de fichier. Si le fichier (dont le nom a été passé comme valeur de l'en-tête NSC_USER) n'existe pas, alors ce fichier est créé avec une structure spécifique, et s'il existe déjà, la variable $ doc est analysée et basée sur elle .... Il s'avère que si nous utilisons la traversée de chemin dans le nom de fichier, nous pouvons créer un fichier avec l'extension ".xml" dans n'importe quel répertoire du système de fichiers où nous avons des autorisations d'écriture. Pour vérifier cela, envoyez la ligne "../../../../tmp/myTestFile" comme valeur de l'en-tête "NSC_USER" et vérifiez si le fichier existe dans le répertoire "/ tmp /". A ce stade, nous avons la possibilité de créer un fichier avec l'extension ".xml", mais il n'y a aucun moyen de contrôler le contenu du fichier. Faisons attention au script "newbm.pl", qui se trouve également dans le répertoire qui nous intéresse. Ce script prend les paramètres POST et écrit dans un fichier (dont le nom est spécifié dans l'en-tête NSC_USER) les valeurs de paramètres tels que "url", "title" et "desc".
Désormais, il est possible non seulement de créer des fichiers xml dans des endroits arbitraires, mais aussi de contrôler partiellement leur contenu.
Pour continuer le chemin vers RCE, revenons à la configuration du serveur Web et notons qu'un autre chemin (/ vpns / portal /) est géré par la fonction perl NetScaler :: Portal :: Handler ( / netscaler / portal / modules / NetScaler / Portal / Handler.pm )
La fonction handler récupère la partie du chemin après le dernier caractère "/" comme nom de fichier, la recherche dans le dossier "/ netscaler / portal / templates /" et essaie de rendre ce fichier en utilisant la bibliothèque "Template Toolkit". Ainsi, si nous pouvons charger notre fichier dans le dossier avec des modèles, nous pouvons également appeler son rendu.
L'exploitation ultérieure est compliquée par le fait que la bibliothèque Template Toolkit fonctionne dans un mode tel qu'il est impossible d'exécuter du code perl en utilisant des méthodes standard. Par exemple, la directive " [% PERL%] " ne peut pas être utilisée .
Sur la base de ces limitations, j'ai décidé de rechercher des vulnérabilités dans les plugins de bibliothèque standard. Considérez un plugin comme "Datafile" ( /usr/local/lib/perl5/site_perl/5.14.2/mach/Template/Plugin/Datafile.pm ). Le fichier est plutôt petit, on fait donc tout de suite attention à l'appel à la fonction standard "open" avec deux arguments. Cette utilisation est dangereuse et pourrait conduire à un RCE.
Nous essayons d'exploiter la vulnérabilité localement et en guise de contrôle nous créons un fichier "testRCE" dans le dossier "/ tmp /".
Pour le moment, nous avons la possibilité de créer des fichiers à des endroits arbitraires du système, de contrôler partiellement leur contenu et leur vulnérabilité dans la bibliothèque Template Toolkit. Nous utilisons tout cela pour obtenir l'exécution de commandes arbitraires d'un utilisateur non autorisé.
Créez un fichier dans le dossier avec des templates dont le rendu conduira à l'exécution du code et à la création d'un interpréteur de ligne de commande web.
Ensuite, nous rendons ce fichier.
Nous nous tournons vers le script (web shell) que nous avons créé précédemment et exécutons une commande OS arbitraire.
Comment se protéger
Citrix a publié des conseils pour remédier à cette vulnérabilité. En outre, le fabricant recommande aux utilisateurs de mettre immédiatement à jour toutes les versions de logiciels vulnérables vers les versions recommandées.
Les entreprises peuvent utiliser des pare-feu au niveau des applications pour bloquer une attaque potentielle. Par exemple, PT Application Firewall détecte cette attaque hors de la boîte: le système doit être mis dans le blocage des demandes dangereuses de protection en temps réel. Compte tenu de la durée de vie totale de la vulnérabilité identifiée (elle est pertinente depuis la sortie de la première version vulnérable du logiciel, c'est-à-dire depuis 2014), il est également important d'identifier rétrospectivement une éventuelle exploitation de cette vulnérabilité (et, par conséquent, une compromission de l'infrastructure).
Les utilisateurs de PT Network Attack Discovery, à partir du 18 décembre 2019, peuvent profiter de règles spéciales qui détectent les tentatives d'exploitation de cette vulnérabilité en ligne.
Auteur : Mikhail Klyuchnikov (@ __mn1__ ), Positive Technologies
Chronologie
- 5 décembre 2019 Rapporté à Citrix
- 19 décembre, 2019 Étapes d'atténuation publiées par Citrix