La semaine dernière, VMware a publié des correctifs pour quatre vulnérabilités découvertes dans son produit vRealize Log Insight qui, si elles étaient combinées, pourraient permettre à des attaquants de prendre le contrôle de la plate-forme de collecte et d'analyse des journaux. Cette semaine, une chaîne d'exploitation de preuve de concept a été publiée par des chercheurs en sécurité, ainsi que des explications détaillées pour chaque vulnérabilité, laissant présager de prochaines attaques dans la nature. « Gagner l'accès à l'hôte Log Insight offre quelques possibilités intéressantes à un attaquant, en fonction du type d'applications qui y sont intégrées », ont déclaré dans leur analyse des failles, les chercheurs de Horizon3.ai, une entreprise spécialisée dans les tests de pénétration. « Souvent, les journaux ingérés peuvent contenir des données sensibles provenant d'autres services et peuvent permettre à une attaque de rassembler des jetons de session, des clés API et des informations personnelles identifiables (Personal Identifying Information PII). Ces clés et ces sessions peuvent permettre à un attaquant de pivoter vers d'autres systèmes et de compromettre davantage l'environnement », ont-ils ajouté.

Une attaque puissante, en combinant les vulnérabilités

Le cas est intéressant, car il met en évidence une réalité commune de la sécurité logicielle moderne, où une vulnérabilité seule ne peut pas conduire à une compromission importante, mais la combinaison de plusieurs peut débloquer une attaque puissante. Dans son avis, VMware décrit la première vulnérabilité, référencée CVE-2022-31704, comme un contrôle d'accès défectueux, sans donner de détails supplémentaires sur sa localisation. Cependant, le script de contournement manuel, publié par l'entreprise en même temps que les mises à jour du produit, donne quelques indices. Le script ajoute simplement une règle de pare-feu qui bloque l'accès aux ports TCP 16520 à 16580. D'après l'enquête d'Horizon3 et les notes de la documentation de vRealize Log Insight, ces ports sont utilisés pour la communication à l'aide du framework Apache Thrift RPC (Remote Procedure Call), le RPC étant un protocole de communication inter-processus, par lequel un processus peut demander à un autre processus d'exécuter une certaine procédure. « Cette information indique que la vulnérabilité se trouve probablement dans un serveur RPC », ont déclaré les chercheurs dans leur compte rendu. « Ensuite, en se connectant au système en cours d'exécution et on a pu constater que le port TCP 16520 était créé par une application Java », ont ajouté les chercheurs. Ces derniers ont réussi à retrouver le composant responsable du démarrage d'un serveur Thrift RPC qui expose plusieurs appels de procédure à distance. Ils ont ensuite construit un client Thrift RPC simple pour effectuer l'un de ces appels et ils ont constaté que les appels étaient passés et exécutés sans authentification, d'où la rupture du contrôle d'accès. Mais cette vulnérabilité seule, bien que donnant accès à des RPC potentiellement puissants, n'est pas suffisante pour exécuter du code malveillant.

Une seconde vulnérabilité de traversée de répertoire

La deuxième vulnérabilité, référencée CVE-2022-31706, est décrite comme une faille de traversée de répertoire, Directory Traversal ou Path Traversal. La traversée de répertoire permet à un attaquant ou à un processus malveillant de naviguer vers un chemin du système de fichiers auquel il n'est pas censé accéder. En examinant les RPC exposés par Thrift RPC, les chercheurs en ont trouvé le RPC remotePakDownloadCommand qui télécharge un fichier avec l'extension .pak (probablement un paquet) et le place dans le répertoire /tmp/. Un autre RPC appelé pakUpgradeCommand peut ensuite être utilisé pour invoquer un script Python qui décompresse ce fichier. Ces deux commandes étant utilisées pour effectuer des mises à niveau du système, les chercheurs ont réalisé que la faille de traversée de répertoire se trouvait sans doute quelque part dans le traitement des fichiers pak.

Il s'avère que les fichiers pak sont des archives au format TAR et que leur traitement avant extraction implique la validation de signatures, des contrôles d'intégrité, des contrôles de manifeste et plusieurs autres étapes. « Si l’on arrive à construire un fichier tar qui passe tous ces contrôles, on peut atteindre la ligne 493 et extractFiles analysera notre tar malveillant, ce qui nous permettra d'écrire un fichier avec le contenu de notre choix à n'importe quel endroit du système de fichiers », ont déclaré les chercheurs. « Certes, nous avons passé un certain temps à construire manuellement un fichier tar qui passerait tous ces contrôles avant de réaliser que nous pouvions simplement utiliser un fichier de mise à niveau légitime avec une petite modification pour accueillir notre charge utile ».

vRealize Log Insight forcé de télécharger un fichier pak malveillant

À ce stade, les chercheurs disposaient des informations nécessaires pour forcer le produit vRealize Log Insight à télécharger un fichier pak malveillant sans authentification, puis à placer une charge utile malveillante n'importe où sur le système. À l'exception d'un problème : l'invocation de la commande remotePakDownloadCommand nécessite un jeton de nœud pour fonctionner, une valeur unique générée par instance de Log Insight. Même si ce jeton n’est pas directement accessible à un utilisateur non authentifié, il peut être divulgué en invoquant d'autres RPC tels que getConfig et getHealthStatus. Il s'agit probablement du problème de divulgation d'informations que VMware mentionne dans son avis CVE-2022-31711. Grâce à cela, les chercheurs d'Horizon3 ont pu construire un exploit de preuve de concept qui place une nouvelle entrée dans crontab - le mécanisme de planification des tâches sur les systèmes basés sur Linux - qui, lorsqu'elle est exécutée, ouvre un shell inverse avec des privilèges d'utilisateur root pour les attaquants. 

La quatrième vulnérabilité, référencée CVE-2022-31710, est, selon l'avis de VMware, une faille de désérialisation qui peut être exploitée pour faire planter le système et provoquer un déni de service. Cette vulnérabilité n'est pas nécessaire pour la chaîne d'exploitation qui aboutit à l'exécution de code à distance. Log Insight est utilisé pour collecter et analyser les journaux des réseaux locaux, il n'est donc pas habituel de trouver de tels systèmes exposés à Internet. Les recherches Shodan dans l'espace IP public n'ont révélé que 45 instances. Cependant, si un attaquant accède au réseau local, ce qui peut se faire de plusieurs façons, et que le serveur Log Insight n'est pas protégé par un pare-feu, il peut être compromis et potentiellement utilisé pour un mouvement latéral en raison des données sensibles qu'il peut contenir. Les chercheurs d'Horizon3 ont publié des indicateurs de compromission qui permettent aux entreprises de vérifier leurs déploiements pour des signes d'exploitation. VMware a publié un script de contournement qui bloque le trafic vers les numéros de port associés au serveur RPC Thrift, et la version 8.10.2 de vRealize Log Insight corrige également les failles.