Le groupe APT chinois, Volt Typhoon se sert d’une vulnérabilité dans la plateforme SD-WAN de Versa pour cibler des FAI, des MSP et des entreprises IT notamment aux Etats-Unis.
Tout est propice pour s’introduire dans les réseaux et voler des identifiants. C’est d’autant plus fâcheux car l’origine du problème vient d’un éditeur de solutions SD-WAN et SASE en l’espèce Versa Networks. Des pirates chinois soutenus par l’Etat ont utilisé une faille zero day dans Versa Director, une plateforme de gestion de l’infrastructure SD-WAN. Cette offre est adoptée par des fournisseurs d’accès à Internet et de services managés. Le groupe, connu dans l’industrie de la sécurité sous le nom de Volt Typhoon, a déjà ciblé des entreprises d’infrastructures critiques américaines par le passé. « Depuis le 12 juin 2024 au moins, Black Lotus Labs a observé l’exploitation zero day des serveurs Versa Director, référencée CVE-2024-39717 », ont écrit dans un rapport les chercheurs de l’équipe Black Lotus Labs de Lumen Technologies. « Cette campagne d’exploitation est restée très ciblée, affectant plusieurs victimes dans les secteurs des FAI, des MSP et de l’IT aux États-Unis. »
Versa Networks, concepteur de Versa Director et d’autres produits SD-WAN et SASE, a corrigé la vulnérabilité CVE-2024-39717 cette semaine, mais le 26 juillet, le fournisseur a alerté ses clients pour qu’ils revoient leurs exigences en matière de pare-feu, et le 9 août, il les a informés que la faille était activement exploitée. « Même si la vulnérabilité est difficile à exploiter, sa criticité est considérée comme « élevée » et elle affecte tous les clients Versa SD-WAN utilisant Versa Director, qui n’ont pas mis en œuvre les directives de renforcement du système et du pare-feu », a écrit le fournisseur dans un avis publié lundi. L’entreprise a également ajouté que les directives de renforcement du système et du pare-feu étaient disponibles depuis 2015 et 2017 respectivement et qu’elles auraient empêché l’exploitation de cette faille. Selon Versa Networks, les systèmes concernés avaient un port de gestion exposé sur Internet qui a fourni aux acteurs de la menace un accès initial.
Un web shell déployé
La vulnérabilité accorde aux attaquants de télécharger des fichiers malveillants vers le serveur web Java Tomcat sous-jacent qui héberge le logiciel Versa Director, ce qui conduit à une escalade des privilèges. Volt Typhoon l’a utilisée pour récupérer un web shell, un script qui sert à accéder à un serveur web par une porte dérobée. Black Lotus Labs a baptisé le web shell de Volt Typhoon VersaMem, car il injecte du code malveillant dans la mémoire du processus du serveur Tomcat en exploitant l’API Java Instrumentation et la boîte à outils Javassist de manipulation du bytecode Java.
L’objectif du web shell est de voler les informations d’identification en clair des utilisateurs de Versa en s’accrochant à la méthode d’authentification intégrée « setUserPassword » de Versa. Il est également capable de charger dynamiquement des modules Java en mémoire et de recevoir des commandes en surveillant les paramètres spéciaux dans les requêtes web envoyées au serveur Tomcat. Les identifiants capturées par le web shell sont stockées localement dans un fichier temporaire et peuvent permettre aux attaquants d’accéder à d’autres infrastructures client en aval et de les compromettre.
Au moins 4 victimes US identifiées
Les attaquants ont obtenu un accès privilégié initial en se connectant à l’interface de gestion Versa exposée sur le port TCP 4566 à partir de routeurs SOHO compromis. Ce port est normalement utilisé pour l’appariement des nœuds Versa Director, il ne devrait donc pas y avoir de communication sur ce port en provenance d’adresses IP inconnues ou d’autres dispositifs. « Nous estimons que le court laps de temps du trafic TCP vers le port 4566 immédiatement suivi par des sessions modérées à importantes de trafic HTTPS sur le port 443 à partir d’une adresse IP qui n’est pas celle d’un nœud Versa (par exemple, un appareil SOHO) est une signature probable d’une exploitation réussie », ont écrit les chercheurs de Black Lotus Labs.
En utilisant la télémétrie globale de Lumen, les chercheurs ont réussi à identifier quatre victimes probables aux États-Unis et une en dehors des États-Unis. Les victimes appartenaient aux secteurs des fournisseurs de services Internet, des prestataires de services de gestion et des technologies de l’information. Les chercheurs ont également localisé une variante de VersaMem téléchargée sur le moteur d’analyse VirusTotal le 7 juin, soit cinq jours avant la première exploitation connue. Le fichier dénommé VersaTest.png avait été téléchargé à partir d’une adresse IP de Singapour et n’avait été détecté par aucun des moteurs de VirusTotal.
Détection et atténuation
Outre le déploiement des correctifs publiés et l’application du pare-feu et des directives de renforcement du système, les chercheurs conseillent aux utilisateurs d’effectuer une recherche récursive de fichiers portant l’extension .png dans le répertoire webroot de Versa, mais qui, en réalité, ne sont pas des fichiers PNG valides. L’exécution de la commande « file -b -mime-type » devrait indiquer « image/png » comme type de fichier. S’ils trouvent des signes de compromission potentielle, les utilisateurs doivent également auditer les comptes utilisateurs Versa, y compris les comptes clients en aval. Ils doivent aussi procéder à une rotation des informations d’identification et examiner tous les journaux disponibles. Lumen a publié une liste d’indicateurs de compromission et de règles de détection YARA sur GitHub. « Compte tenu de la gravité de la vulnérabilité, de la sophistication des acteurs de la menace, du rôle critique des serveurs Versa Director dans le réseau et des conséquences potentielles d’une compromission réussie, Black Lotus Labs considère cette campagne d’exploitation comme très importante », ont écrit les chercheurs.
En février, la National Security Agency (NSA), le Federal Bureau of Investigation (FBI) et la Cybersecuity and Infrastructure Security Agency (CISA) des États-Unis ont publié un avis commun sur Volt Typhoon, signalant que le groupe avait infiltré les réseaux informatiques d’entreprises des secteurs des communications, de l’énergie, des transports, de l’eau et de la gestion des eaux usées. « Le choix des cibles et le comportement de Volt Typhoon ne correspondent pas à des opérations traditionnelles de cyberespionnage ou de collecte de renseignements, et les agences américaines estiment avec une grande certitude que les acteurs de Volt Typhoon se prépositionnent sur les réseaux IT en vue de réaliser des mouvements latéraux vers les actifs informatiques afin de perturber les fonctions », ont averti les organismes. « Les agences américaines s’inquiètent de la possibilité pour ces acteurs d’utiliser leur accès au réseau pour provoquer des perturbations en cas de tensions géopolitiques et/ou de conflits militaires ».
Les cybercriminels soutenus par des Etats multiplient les techniques d’attaque qui ont fait leurs preuves dans l’exploitation des services de stockage cloud gratuits, avec un objectif de commande et de contrôle (C2).
Selon une étude de Symantec, un nombre croissant de groupes APT (Advanced Persistent Threat) exploitent les services de stockage dans le cloud proposés par Microsoft et Google pour en prendre le contrôle et exfiltrer des données. Si l’utilisation abusive de ces services gratuits par les cybercriminels n’est pas rare, de récentes preuves suggèrent que les groupes de cyberespionnage parrainés par des États sont de plus en plus nombreux à mener ce genre d’attaques. « Ces dernières semaines seulement, l’équipe de chasseurs de menaces de Symantec a identifié trois nouvelles opérations d’espionnage utilisant des services cloud et a trouvé des preuves de l’existence d’autres outils en cours de développement », ont déclaré les chercheurs de la division Symantec de Broadcom dans un billet de blog.
Leurs conclusions ont été présentées à la conférence sur la sécurité Black Hat USA organisée à Las Vegas L’utilisation abusive de services cloud gratuits présente des avantages évidents pour les attaquants, car non seulement ils offrent une solution rapide et peu coûteuse, mais surtout, ils permettent une communication plus furtive à l’intérieur des réseaux. En effet, la probabilité que les produits de sécurité ou les parefeux signalent comme suspectes les connexions à des services largement utilisés comme Microsoft OneDrive ou Google Drive, par rapport à une adresse IP en Chine, par exemple, est faible.
Des inconvénients pour l’attaquant, mais il y a des parades
Cette pratique présente aussi certains inconvénients importants. Tout d’abord, le compte cloud utilisé à des fins malveillantes sera suspendu dès que les chercheurs en sécurité l’auront identifié et signalé au fournisseur de services, ce qui risque de perturber l’opération. En comparaison, si des chercheurs découvrent un serveur de commande et de contrôle C2 privé, leur seule option est de partager son adresse IP afin qu’il puisse être bloqué par les produits et les équipes de sécurité. Mais l’opération prend du temps et toutes les victimes ne seront pas nécessairement protégées. Un compte cloud peut aussi fournir aux chercheurs une mine d’informations supplémentaires sur l’opération si le fournisseur de services coopère et partage les journaux d’activité du compte et tous les fichiers stockés à l’intérieur.
Cette divulgation peut compromettre la sécurité opérationnelle des attaquants, ce qui est un aspect important, en particulier pour les acteurs du cyberespionnage qui agissent pour le compte d’États-nations. Cependant, des solutions existent pour parer à ces inconvénients. Par exemple, les attaquants peuvent coder en dur dans leurs logiciels malveillants des canaux C2 de secours qui seront utilisés au cas où le canal principal, basé sur les services cloud, cesse soudainement de fonctionner. Ils peuvent aussi utiliser le chiffrement pour dissimuler leurs activités et les fichiers exfiltrés aux enquêteurs qui accèdent au compte du service cloud malveillant. Ces contre-mesures sont relativement courantes, ce qui rend l’utilisation abusive des services cloud par les APT beaucoup plus viable.
De nouveaux implants de malwares
Une menace capable de tirer parti des services Microsoft pour la commande et le contrôle C2 est apparue récemment sous forme de programme de porte dérobée appelé GoGra. Écrit dans le langage de programmation Go, ce programme a été déployé contre un média en Asie du Sud en novembre de l’année dernière. Selon l’équipe de Symantec, la porte dérobée pourrait être une évolution ou une réimplémentation d’une autre porte dérobée connue sous le nom de Graphon, écrite en .NET et attribuée à un groupe soutenu par un État-nation. Ce groupe, baptisé Harvester par Symantec, cible des entreprises d’Asie du Sud depuis 2021.
GoGra exploite l’API Microsoft Graph pour accéder au service de messagerie Outlook à l’aide de jetons d’accès OAuth pour un nom d’utilisateur appelé FNU LNU. La porte dérobée accède à la boîte aux lettres Outlook et lit les instructions des messages électroniques dont l’objet contient le mot « Input ». Cependant, le contenu des messages est chiffré avec AES-256 et le logiciel malveillant les déchiffre avec une clé codée en dur. « GoGra exécute des commandes via le flux d’entrée cmd.exe et prend en charge une commande supplémentaire nommée cd qui modifie le répertoire actif », ont expliqué les chercheurs de Symantec. « Après l’exécution d’une commande, il chiffre la sortie et l’envoie au même utilisateur avec l’objet Output ». Un deuxième implant de malware APT exploitant l’API Microsoft Graph, appelé Trojan.Grager, a été utilisé contre des entreprises de Taïwan, de Hong Kong et du Vietnam en avril. La porte dérobée a été distribuée via un programme d’installation trojanisé pour le gestionnaire d’archives 7-Zip, et elle utilise Microsoft OneDrive au lieu d’Outlook à des fins C2. La porte dérobée peut télécharger, téléverser et exécuter des fichiers et recueille des informations sur le système et la machine.
Des techniques similaires utilisées par de nombreux acteurs de la menace
Des liens présumés existent entre Grager et un groupe APT que l’équipe Mandiant de Google suit sous le nom de UNC5330, car le même programme d’installation de 7-Zip contenant des chevaux de Troie a également déposé une backdoor appelée Tonerjam, associée à ce groupe. Les chercheurs pensent que le groupe UNC5330 est un « acteur d’espionnage lié à la Chine ». Il ferait aussi partie des groupes qui ont exploité les appareils Ivanti Connect au début de l’année 2024. Une autre porte dérobée à plusieurs niveaux, appelée Onedrivetools ou Trojan.Ondritols, utilise aussi l’API Microsoft Graph pour télécharger une charge utile de deuxième niveau à partir de Microsoft OneDrive. Cette porte dérobée a été utilisée contre des entreprises de services IT aux États-Unis et en Europe.
Les chercheurs de Symantec ont également découvert en mai une menace appelée BirdyClient, utilisée contre une organisation ukrainienne qui utilise OneDrive comme serveur C2 via l’API Graph. Une autre nouvelle porte dérobée, baptisée MoonTag, qui semble toujours en cours de développement et téléchargée récemment sur VirusTotal, utilise l’API Microsoft Graph. Cette porte dérobée a probablement été créée par un acteur chinois et utilise des échantillons de code pour la communication avec l’API Graph précédemment partagés dans un groupe Google en langue chinoise. Certains groupes préfèrent Google Drive au service de stockage de fichiers de Microsoft. Par exemple, un outil d’exfiltration de données, jamais signalé jusque-là, a été utilisé contre une cible militaire en Asie du Sud-Est par un groupe de cyberespionnage connu sous le nom de Firefly. Cet outil, écrit en Python, recherchait sur l’ordinateur local des fichiers images au format jpg, puis les téléchargeait sur un compte Google Drive à l’aide d’un client Google Drive open source et d’un token codé en dur.
Par le passé, d’autres acteurs du cyberespionnage ont occasionnellement utilisé des services gratuits de stockage de fichiers dans le cloud à des fins de C2, notamment le groupe APT37 (Vedalia) affilié à la Corée du Nord en 2021, le groupe APT28 (Fancy Bear) affilié à la Russie en 2022 et le groupe APT15 (Nickel) affilié à la Chine en 2023. Cependant, selon les observations de Symantec, la quantité de menaces APT adoptant cette technique a nettement augmenté au cours de l’année écoulée. « Vu le nombre d’acteurs qui déploient aujourd’hui des attaques exploitant des services cloud, on peut penser que les acteurs de l’espionnage étudient clairement les menaces créées par d’autres groupes et cherchent à reproduire des techniques qui ont l’air de fonctionner », ont déclaré les chercheurs.
En analysant le patch d’une faille actuellement ciblée par es attaquants, les chercheurs ont découvert une autre vulnérabilité de type RCE dans Apache OFbiz. C’est la cinquième faille critique qui affecte cette année le framework ERP. La CISA invite les utilisateurs à mettre à jour le plus rapidement possible.
Des chercheurs de SonicWall signalent une vulnérabilité critique dans le système et framework ERP open source Apache OFBiz. La faille entraînant une exécution de code à distance sans authentification, a été corrigée peu après l’exploitation dans la nature d’une autre vulnérabilité corrigée en mai. Considérée comme critique, la vulnérabilité, référencée CVE-2024-38856, touche les versions d’Apache OFBiz jusqu’à la version 18.12.14. Elle a été corrigée dans la version 18.12.15 publiée le 3 août.
Un module très utilisé
Initialement baptisée Open for Business, Apache OFBiz offre des modules pour la gestion des processus d’entreprise comme la comptabilité, les ressources humaines, la gestion de la supply chain, la gestion des catalogues de produits, la gestion de la relation client (CRM), la fabrication, le commerce électronique, et bien plus encore. Ces modules reposent sur un framework de développement web basé sur Apache, qui peut également servir à créer des applications et des fonctions personnalisées supplémentaires.
On ne sait pas exactement combien d’entreprises exécutent Apache OFBiz, car beaucoup peuvent l’utiliser en interne, mais d’après les données publiques, de grandes entreprises comme IBM, HP, Accenture, United Airlines, Home Depot et Upwork font partie des utilisateurs connus. Certaines applications commerciales tierces, comme Jira d’Atlassian se servent aussi des modules OFBiz. Le projet est utilisé dans le monde entier et dans de nombreux secteurs, mais plus de 40 % des utilisateurs connus sont basés aux États-Unis.
L’analyse de la précédente faille à l’origine de la découverte
La faille découverte se trouve dans la fonctionnalité « override view » et permet à des attaquants non authentifiés d’accéder à des points d’extrémité sensibles et restreints en utilisant des requêtes spécialement conçues, rendant possible l’exécution de code à distance. En fait, c’est en analysant le correctif d’OFBiz pour une autre faille de traversée de répertoire corrigée dans la version 18.12.14 à la fin du mois de mai que les chercheurs de SonicWall ont découvert la vulnérabilité. Cette précédente faille, référencée CVE-2024-36104, peut aussi entraîner l’exécution de code à distance. Depuis sa divulgation, elle a fait l’objet d’une preuve de concept, mais à la fin du mois de juillet, le SANS Internet Storm Center a signalé des tentatives d’exploitation de cette faille dans la nature.
Il convient de noter qu’une autre faille de contournement de l’authentification (CVE-2023-51467) découverte par les chercheurs de SonicWall dans OFBiz en décembre 2023 a également été exploitée plus tard dans la nature. Il semble qu’OFBiz intéresse les attaquants et que les applications construites avec le framework exposées à Internet courent un risque immédiat. À noter aussi que la faille CVE-2024-38856 est la cinquième vulnérabilité de sécurité classée comme critique ou importante trouvée et corrigée dans OFBiz cette année. Les entreprises qui utilisent ce framework ERP devraient mettre à jour vers la dernière version dès que possible et s’assurer qu’OFBiz est couvert par leurs produits de surveillance des vulnérabilités. SonicWall a félicité les développeurs d’OFBiz pour leur réponse rapide, car ils ont renvoyé un correctif fonctionnel pour analyse en moins de 24 heures. La CISA prend l’affaire au sérieux en poussant les entreprises à appliquer rapidement le correctif.
Malgré la mise en place d’un correctif pour la vulnérabilité présente dans la fonction GlobalProtect des firewall de Palo Alto Networks, les tentatives de compromission pour accéder aux réseaux d’entreprise ont augmenté.
Depuis la publication, la semaine dernière, d’un PoC, un nombre croissant d’attaquants tentent de se servir d’une faille critique dans les pare-feux de Palo Alto Networks. Initialement signalée le 12 avril, la faille a été qualifiée de zero day après la découverte de son exploitation par un groupe APT. Selon les statistiques de la Shadowserver Foundation, le 18 avril, environ 22 500 équipements potentiellement vulnérables étaient encore accessibles depuis Internet. Même si ce chiffre est important si l’on considère que chacun de ces appareils peut servir de passerelle potentielle vers un réseau d’entreprise, il est bien inférieur aux 150 000 terminaux vulnérables estimés lors de l’annonce de la faille.
La vulnérabilité, référencée CVE-2024-3400, est située dans la fonction GlobalProtect du système d’exploitation PAN-OS et offre aux attaquants d’injecter des commandes exécutables sur le système sous-jacent avec des privilèges d’administrateur. PAN-OS fonctionne sur les dispositifs et appliances de pare-feu de dernière génération (Next-Generation Firewall, NGFW) de Palo Alto Networks et GlobalProtect est la fonction VPN SSL mise en œuvre pour l’accès distant sécurisé au réseau de l’entreprise.
Le groupe UTA0218 identifié comme coupable
C’est le 10 avril que les chercheurs de Volexity ont découvert la brèche en enquêtant sur un trafic suspect provenant du firewall Palo Alto Networks d’un client. Les chercheurs ont déterminé que cet équipement avait été compromis par un groupe connu sous le nom de UTA0218, par le biais d’une vulnérabilité jusqu’alors inconnue. Après avoir notifié la découverte à l’équipe de sécurité des produits de Palo Alto Networks, le fournisseur a mené sa propre enquête et le 12 avril, il a publié un avis avec des mesures d’atténuation, le temps pour l’entreprise de produire les correctifs appropriés. Ceux-ci ont été livrés entre le 14 et le 18 avril pour les différentes versions de l’OS.
Il convient de noter que l’une des mesures d’atténuation suggérées à l’origine par Palo Alto Networks consistait à désactiver la fonction de télémétrie de l’équipement, considérée comme nécessaire pour que l’exploit fonctionne. Cependant, l’équipe de sécurité de l’entreprise a par la suite identifié d’autres méthodes d’exploitation qui ne nécessitaient pas l’activation de la fonction de télémétrie de l’appareil, de sorte que ce conseil d’atténuation a été supprimé.
La faille exploitée depuis la fin du mois de mars
Après sa découverte initiale, Volexity a pu créer une signature de détection et a parcouru les données télémétriques de ses clients pour trouver des compromissions antérieures. Si les premiers signes d’exploitation identifiés par l’entreprise de sécurité datent du 26 mars, ces incidents ressemblaient davantage à des tentatives par le groupe APT de tester l’exploit sans déployer de charge utile malveillante, alors que le 10 avril, UTA0218 avait commencé à déployer une porte dérobée personnalisée écrite en Python et baptisée UPSTYLE.
« Après avoir réussi à exploiter les appareils, UTA0218 a téléchargé des outils supplémentaires à partir de serveurs distants qu’il contrôlait afin de faciliter l’accès aux réseaux internes des victimes », ont expliqué les chercheurs de Volexity dans leur rapport. « Ils se sont rapidement déplacés latéralement dans les réseaux des victimes, extrayant des informations d’identification sensibles et d’autres fichiers qui accordaient l’accès pendant et potentiellement après l’intrusion. L’habileté et la rapidité de l’attaquant laissent penser que ce groupe est très compétent, qu’il dispose d’un cahier des charges clair sur ce à quoi il doit accéder pour atteindre ses objectifs ».
Publication d’un prototype d’exploitation
Le 16 avril, des chercheurs de WatchTowr Labs ont réussi à reconstituer la vulnérabilité en procédant à une rétro-ingénierie du code de PAN-OS et ont publié un article technique ainsi qu’un exploit de preuve de concept sous la forme d’une requête HTTP avec la charge utile injectée dans la valeur du cookie. Le lendemain, GreyNoise, une société qui surveille le trafic malveillant sur Internet, a signalé un pic dans le nombre d’adresses IP tentant d’exploiter la CVE-2024-3400. Palo Alto Networks a également mis à jour son avis pour indiquer à ses clients qu’il était au courant qu’un nombre croissant d’attaques exploitait la vulnérabilité et que le code d’exploitation du PoC était désormais accessible au public. L’entreprise a aussi publié des commandes que les utilisateurs de PAN-OS peuvent exécuter sur leurs équipements afin de savoir s’il y a eu une tentative d’exploitation, tandis que l’unité de recherche sur les menaces de l’entreprise a publié des indicateurs de compromission dans un billet de blog analysant la porte dérobée UPSTYLE.
Il convient de préciser qu’il est difficile de vérifier la faille du firewall de Palo Alto accessible par Internet par un simple balayage passif. La présence d’une version vulnérable de PAN-OS indique que le correctif complet n’a pas été appliqué, mais cela ne signifie pas que l’appareil ne dispose pas des mesures d’atténuation alternatives que le fournisseur a suggéré de mettre en place et qu’il est donc protégé contre un exploit. « Une signature de prévention des menaces avec l’ID de menace 95187 (publiée le 11 avril 2024) détecte et bloque, avec une précision de 100 %, tous les modèles suspects connus et observés dans les ID de session », a déclaré l’entreprise dans un billet de blog vendredi. « Cette signature de prévention a été publiée par Palo Alto Networks dans la journée qui a suivi la confirmation de la vulnérabilité et nous constatons qu’environ 90 % des appareils sensibles sont déjà protégés ».
Selon une étude, un script pour déployer un malware d’un groupe de cybercriminels nommé TA547 a sans doute été créé par une IA générative. La cible était des organisations allemandes.
L’IA sert aussi bien dans la défense que dans l’attaque en matière de cybersécurité. Et sur ce dernier volet, les cybercriminels ont bien compris les bénéfices à tirer de cette technologie. Une récente attaque contre des organisations allemandes en serait la preuve. En effet, selon un rapport de Proofpoint sur cette campagne, l’infostealer appelé Rhadamanthys, distribué à l’aide d’un script PowerShell, a probablement été créé par une IA générative comme ChatGPT, Gemini ou CoPilot. Cela fait un certain temps que les chercheurs alertent sur la disponibilité généralisée de ces puissants outils qui mettent les attaques à portée de mains de cybercriminels moins aguerris, avec lesquels ils peuvent créer des leurres d’hameçonnage plus crédibles dans des langues qu’ils ne connaissent pas ou des codes malveillants sans être des programmeurs avertis.
Même si les attaquants sont suffisamment compétents pour écrire du code, ils peuvent toujours utiliser des assistants d’intelligence artificielle pour accélérer la tâche. C’est le cas de la dernière attaque d’un groupe connu sous le nom de TA547, qui agit comme un courtier d’accès initial pour d’autres cybercriminels, en vendant l’accès à des systèmes compromis. « Il est difficile de confirmer que le contenu malveillant, depuis les scripts de logiciels malveillants jusqu’aux leurres d’ingénierie sociale, a été créé à l’aide de LLM, mais certaines caractéristiques de ce contenu indiquent que les informations ont été générées par des machines plutôt que par des humains », ont déclaré les chercheurs de Proofpoint.
Changement de tactiques
Actif depuis 2017, l’acteur de la menace TA547 a utilisé de nombreux programmes trojan et de voleurs d’informations différents au fil des ans. En 2023, les campagnes d’emails malveillants du groupe distribuaient souvent des scripts JavaScript malveillants qui déployaient NetSupport RAT et occasionnellement StealC et Lumma Stealer. Pour cette nouvelle attaque, les chercheurs ont observé un changement de tactique. Au lieu d’utiliser des fichiers JavaScript malveillants inclus dans des archives ZIP, le gang a opté pour des fichiers LNK utilisés pour les raccourcis d’applications Windows.
Ces derniers peuvent contenir des scripts PowerShell pris en charge de manière native par Windows, ce qui en fait un puissant mécanisme de diffusion de charges utiles. La dernière campagne de courriels détectée par Proofpoint utilisait un leurre de facturation rédigé en allemand au faux en-tête du grand distributeur Metro. Des dizaines d’organisations de divers secteurs en Allemagne ont été ciblées. Les courriels frauduleux contenaient une archive ZIP protégée par mot de passe, avec le mot de passe fourni dans le message électronique. À l’intérieur, ils contenaient un fichier LNK qui invoquait le runtime PowerShell pour exécuter un script hébergé à distance.
Échapper aux moteurs de détection EDR
L’objectif de ce script secondaire était de décoder un fichier exécutable à l’aide de Base64 pour l’infostealer Rhadamanthys qui était stocké dans une variable, puis de le charger directement dans la mémoire et de l’exécuter sans l’écrire sur le disque. Ce type de technique de logiciel malveillant sans fichier (ou fileless) est couramment utilisé pour échapper aux moteurs de détection aux points de terminaison (Endpoint Detection and Response, EDR).
Exemple de Powershell soupçonné d’avoir été généré par une IA. (Crédit Photo : Proofpoint)
Parce que son objectif est de charger une charge utile de logiciel malveillant sur le système, le script PowerShell est appelé chargeur de logiciel malveillant (ou malware loader). Comme mentionné précédemment, TA547 préférait auparavant les chargeurs basés sur JavaScript et c’est également la première fois que le groupe utilise Rhadamanthys, même si ce n’est pas inhabituel puisque cet infostealer a gagné en popularité dans l’underground cybercriminel.
Implication de la GenAI et des LLM dans le script
« Le script PowerShell comprenait un signe dièse suivi de commentaires grammaticalement corrects et hyper-spécifiques au-dessus de chaque composant du script », ont déclaré les chercheurs de Proofpoint. « C’est le résultat typique d’un contenu de codage généré par un LLM, ce qui laisse penser que le groupe TA547 a utilisé un outil activé par un LLM pour écrire (ou réécrire) le PowerShell ou a copié le script à partir d’une autre source qui l’avait déjà utilisé ». Si les attaquants peuvent utiliser les LLM pour mieux comprendre les chaînes d’attaque de leurs concurrents afin d’améliorer, voire de créer les leurs, l’utilisation des LLM ne rend pas nécessairement la détection plus difficile.
Au contraire, elle pourrait la faciliter si certains signes de code généré par l’IA étaient ajoutés aux signatures de détection. « En fin de compte, une charge utile de malware connu a été chargée sur le système et les produits de sécurité efficaces pour les points de terminaison devraient être en mesure de le capturer », ont déclaré les chercheurs.
Le groupe APT Lazarus, affilié à la Corée du Nord a actualisé son rootkit FudModule pour intégrer la faille AppLocker. Elle lui octroie une élévation de privilèges dans le noyau Windows.
Le Patch Tuesday de février corrigeait une faille critique provoquant une élévation de privilèges dans le noyau Windows. Des chercheurs d’Avast ont constaté que cette vulnérabilité a été exploitée par un groupe APT du nom de Lazarus, affilié à la Corée du Nord au sein de son rootkit FudModule. Ce dernier « utilise désormais une technique de manipulation des entrées de la table de gestion pour tenter de suspendre les processus protégés PPL (Protected Process Light) associés à Microsoft Defender, CrowdStrike Falcon et HitmanPro, ce qui représente une avancée majeure dans leur technique d’attaque », précise les experts dans un rapport.
La vulnérabilité AppLocker remplace le BYOVD
Également connu sous le nom d’APT38, le groupe Lazarus est l’une des équipes de pirates informatiques du gouvernement nord-coréen, impliquée autant dans le cyberespionnage et le sabotage, que, parfois, dans des actions de cybercriminalité en vue collecter de l’argent pour le régime. Ses opérations remontent à plusieurs années, mais certains chercheurs pensent que Lazarus fédère probablement différents sous-groupes qui mènent leurs propres campagnes et développent des logiciels malveillants sur mesure pour leurs cibles. Le rootkit FudModule n’est pas un nouveau venu dans la panoplie d’outils de Lazarus et il a déjà été analysé par d’autres entreprises de cybersécurité en 2022.
FudModule est un rootkit de données uniquement qui existe dans l’espace utilisateur et exploite les privilèges de lecture/écriture du noyau par le biais de pilotes pour altérer les mécanismes de sécurité de Windows et réduire la capacité des produits de sécurité à détecter d’autres composants malveillants. Dans les versions précédentes, les attaquants obtenaient des privilèges en exploitant des vulnérabilités connues dans des pilotes tiers signés qu’ils déployaient sur le système avec le logiciel malveillant. Cette technique est connue sous le nom de BYOVD « Bring Your Own Vulnerable Driver » (Apporter son propre pilote vulnérable). Pour installer un pilote sous Windows, il faut disposer de privilèges d’administrateur, de sorte que les attaquants disposent déjà de privilèges élevés sur les systèmes.
Des techniques de rootkit améliorées
Le rootkit FudModule utilise son accès en lecture/écriture au noyau pour désactiver certaines fonctions importantes sur lesquelles s’appuient les produits de sécurité pour détecter les comportements suspects : les rappels de registre, servant à détecter les modifications du registre du système ; les rappels d’objet, utilisés pour exécuter du code personnalisé en réponse aux opérations de gestion de thread, de processus et de bureau ; et les rappels de processus, de thread et d’image du noyau, qui permettent aux produits de sécurité des points finaux d’effectuer des vérifications à chaque fois que de nouveaux processus sont créés ou que des DLL sont chargées. Le rootkit FudModule supprime tous ces types de rappels enregistrés par les produits de sécurité dans le noyau afin d’affaiblir leurs capacités de détection des logiciels malveillants. Cette dernière variante n’apporte que des modifications mineures aux rappels qu’elle supprime. Le rootkit supprime également les minifiltres du système de fichiers enregistrés par les programmes antivirus pour surveiller les opérations sur les fichiers. Une nouvelle fonctionnalité du rootkit consiste à désactiver les rappels de vérification d’image invoqués lorsqu’une nouvelle image de pilote est chargée dans la mémoire du noyau. Cette fonctionnalité est exploitée par certains programmes anti-malware pour détecter et bloquer les pilotes malveillants ou vulnérables.
Même si tout cela à l’air d’aider les attaquants avec leur technique BYOVD, il n’est pas très logique de désactiver ces rappels après avoir déjà chargé un pilote compromis pour déployer le rootkit. Ce serait alors trop tard, à moins que les attaquants ne prévoient de charger d’autres pilotes malveillants dans un but quelconque après que le rootkit a été déployé. On sait que, dans le passé, Lazarus a déjà utilisé certains pilotes personnalisés afin d’effectuer des attaques par effacement de disque. Une autre technique de rootkit mise en œuvre dans cette version vise à désactiver directement des produits de sécurité spécifiques, à savoir AhnLab V3 Endpoint Security, Windows Defender, CrowdStrike Falcon et HitmanPro. « Le groupe Lazarus reste l’un des acteurs les plus prolifiques et les plus anciens de la menace persistante avancée. Même si leurs tactiques et techniques sont désormais bien connues, ils parviennent encore parfois à nous surprendre avec un niveau inattendu de sophistication technique », ont déclaré les chercheurs d’Avast. « Le rootkit FudModule en est le dernier exemple et il représente l’un des outils les plus complexes que Lazarus possède dans son arsenal ».
Des défenses existent pour l’admin to kernel
Cependant, il existe une différence entre obtenir un accès administrateur et obtenir des privilèges du noyau (SYSTEM) sous Windows. Ces rôles fonctionnent à des niveaux d’intégrité différents et sont soumis à des limitations différentes, mais Microsoft ne considère pas officiellement l’accès administrateur au noyau comme une limite de sécurité, car il existe plusieurs façons d’exécuter le noyau à partir d’un compte administrateur – par exemple, le BYOVD, car les pilotes tiers mal écrits ne manquent pas. Tout compte administrateur peut installer un pilote et tout pilote est chargé dans le noyau. « Microsoft n’a pas renoncé à sécuriser la frontière entre l’administrateur et le noyau », ont encore expliqué les chercheurs d’Avast. « Bien au contraire, l’entreprise a fait beaucoup de progrès pour rendre cette frontière plus difficile à franchir. Les protections de défense en profondeur, comme l’application du Driver Signature Enforcement (DES) ou Hypervisor-Protected Code Integrity (HVCI), ont rendu l’exécution de code personnalisé dans le noyau de plus en plus difficile pour les attaquants.
Ils ont été obligés la plupart d’entre eux à recourir à des attaques par données uniquement (où ils atteignent leurs objectifs malveillants uniquement en lisant et en écrivant dans la mémoire du noyau). D’autres défenses, comme la mise en liste bloquée des pilotes, poussent les attaquants à exploiter des pilotes vulnérables moins connus, ce qui augmente la complexité des attaques. Même si ces défenses n’ont pas encore atteint le point où l’on peut officiellement qualifier la barrière admin-to-kernel de frontière de sécurité (les attaques BYOVD sont toujours possibles, donc l’appeler ainsi ne ferait qu’induire les utilisateurs en erreur et leur donner un faux sentiment de sécurité), elles représentent clairement des pas dans la bonne direction.
Un patch existe
La nouvelle vulnérabilité CVE-2024-21338 exploitée par Lazarus est située dans appid.sys, c’est-à-dire le moteur central d’AppLocker, la technologie de liste blanche d’applications intégrée à Windows, ce qui est assez ironique. Microsoft a attribué à cette vulnérabilité un score de 7,8 sur 10 sur l’échelle CVSS. Avast pense que ce score élevé est dû au fait que la faille pourrait aussi être exploitée à partir du compte de service local, qui a des privilèges encore plus réduits par rapport aux administrateurs.
« Même si la vulnérabilité ne répond que très partiellement aux critères de sécurité de Microsoft, nous pensons que l’application d’un correctif était le bon choix et nous tenons à remercier Microsoft d’avoir finalement résolu ce problème », ont déclaré les chercheurs d’Avast. « Le correctif perturbera sans aucun doute les opérations offensives de Lazarus, les obligeant à trouver un autre zero-day admin-to-kernel ou à revenir à des techniques BYOVD ».
La dernière mise à jour, qui corrigeait de précédentes failles dans les produits d’Ivanti, a introduit d’autres vulnérabilités. Les clients sont invités à appliquer un autre correctif.
Sale temps pour Ivanti et ses produits de sécurité. En effet, quelques jours après l’annonce par l’éditeur de la disponibilité de correctifs pour une faille découverte dans ses solutions Connect Secure et Policy Secure (son VPN SSL), une autre brèche a été découverte et les attaquants s’y intéressent de très prés. Il s’agit de la vulnérabilité CVE-2024-22024 entraînant une injection d’entité externe XML (External Entity Injection, XXE) dans le composant SAML de certaines versions de Connect Secure, Policy Secure et ZTA.
La faille a été découverte par des chercheurs de la société wtachTowr en analysant le correctif pour la vulnérabilité CVE-2024-21893. Celle-ci provoque une falsification de requêtes côté serveur ou Server-Side Request Forgery (SSRF) dans le composant SAML. Le 31 janvier, Ivanti avait révélé que cette faille zero day, découverte par l’entreprise alors qu’elle enquêtait sur deux autres vulnérabilités zero day annoncées le 10 janvier et exploitées par un groupe chinois de menaces persistantes avancées (APT), était exploitée dans des attaques ciblées. En réponse à ces attaques, Ivanti a d’abord publié une mesure d’atténuation basée sur XML applicable aux terminaux concernés le temps de préparer des mises à jour pour toutes les versions logicielles concernées.
Des mises à jour disponibles
Les mises à jour pour les quatre vulnérabilités connues – CVE-2023-46805 (contournement de l’authentification), CVE-2024-21887 (injection de commande), CVE-2024-21888 (élévation de privilèges) et CVE-2024-21893 (SSRF dans le composant SAML) – ont finalement été publiées le 31 janvier et le 1ᵉʳ février. Les mises à jour pour la récente faille CVE-2024-22024 (injection XXE) ont été publiées le 8 février. Selon Ivanti, ces mises à jour remplacent les précédentes. L’entreprise indique par ailleurs que les clients qui ont réinitialisé leurs terminaux lors de l’application des correctifs du 31 janvier et du 1ᵉʳ février n’ont pas besoin de le faire à nouveau après l’application des mises à jour du 8 février.
La réinitialisation d’usine était nécessaire pour supprimer tous les implants potentiels et les modifications apportées par les attaquants à l’aide des exploits précédents. « Nous conseillons vivement aux clients d’utiliser l’outil de vérification de l’intégrité externe d’Ivanti, publié précédemment, en combinaison avec les meilleures pratiques de surveillance de la sécurité », a recommandé l’entreprise dans un billet de blog. Les vulnérabilités d’injection XXE permettent aux attaquants d’injecter des entités XML dangereuses dans des applications web qui traitent des données XML. Les chercheurs de watchTowr précisent que la faille CVE-2024-22024 a été introduite par l’un des correctifs pour les vulnérabilités précédentes, ce qui explique pourquoi elle n’affecte que certaines versions récentes des produits. Selon Ivanti, les versions concernées sont les suivantes : Connect Secure 9.1R14.4, 9.1R17.2, 9.1R18.3, 22.4R2.2, 22.5R1.1, et 22.5R2.2 ; Ivanti Policy Secure 22.5R1.1 ; et ZTA 22.6R1.3.
Des tentatives d’exploitation de la vulnérabilité
À la suite du rapport de watchTowr et de l’avis d’Ivanti, un PoC a été développé et publié en ligne au cours du week-end. Depuis, plusieurs services et entreprises qui gèrent des pots de miel et surveillent le trafic Internet malveillant ont signalé des recherches de la vulnérabilité et des tentatives d’exploitation. « Le 9 février, soit peu de temps après la publication du PoC, nous avons repéré des tentatives d’exploitation de ‘/dana-na/auth/saml-sso.cgi’ », a déclaré la Shadowserver Foundation sur Twitter. « Il s’agit principalement de tests de rappel. 47 adresses IP ont été observées à ce jour ».
De son côté, Akamai dit avoir constaté des tentatives de scan et de charge utile pour cette faille en provenance de plus de 80 adresses IP et ciblant plus de 30 000 hôtes. La semaine dernière, dans une directive actualisée, la CISA a demandé à toutes les agences fédérales de déconnecter de leurs réseaux les produits Ivanti concernés avant le vendredi 2 février à minuit, et de procéder à des analyses forensiques supplémentaires et à des mesures de nettoyage au cas où leurs réseaux auraient déjà été compromis. Et vendredi dernier, l’agence a publié une directive supplémentaire demandant à toutes les agences d’appliquer les nouveaux correctifs Ivanti pour la faille CVE-2024-22024 avant le lundi 12 février.
La découverte d’une faille dans la solution de CI/CD Jenkins n’aura pas mis longtemps à être exploitée avec la publication de PoC sur GitHub. Les cybercriminels se sont empressés de scanner Internet à la recherche de serveurs Jenkins vulnérables.
Le temps presse pour corriger une faille découverte dans Jenkins, la solution de déploiement continu à l’intention des développeurs. En effet, à peine trouvée, la vulnérabilité fait l’objet de plusieurs exploits disponibles sur GitHub ouvrant ainsi la voie à une multiplication d’attaques. D’après les analyses effectuées par le service Shodan, plus de 75 000 serveurs Jenkins sont exposés à Internet. Ce service est couramment utilisé pour l’intégration continue et de la livraison continue (CI/CD), car il permet d’automatiser la construction, le test et le déploiement du code.
Compte tenu de ses nombreuses intégrations avec d’autres services et outils, Jenkins est très populaire dans toutes les entreprises de développement. Sa part de marché est estimée à environ 44%. Qualifiée de critique, la vulnérabilité, référencée CVE-2024-23897, résulte d’un problème de lecture arbitraire de fichier que les attaquants peuvent exploiter pour lire des fichiers binaires entiers ou partiels à partir du système de fichiers. Ils peuvent ainsi extraire des clés secrètes et les utiliser pour élever leurs privilèges au niveau administrateur et exécuter du code malveillant. Ce problème a été corrigé dans les versions 2.442 et LTS 2.426.3 de Jenkins, en même temps que plusieurs autres failles de gravité élevée et moyenne.
Des lignes de commandes exposent des secrets
La faille provient de l’utilisation par Jenkins de la bibliothèque args4j pour analyser les arguments de commande (command line argument parsing), et les options lors du traitement des commandes envoyées via l’interface de ligne de commande (CLI) de Jenkins. L’analyseur remplace le caractère @ suivi d’un chemin d’accès à un fichier dans un argument de commande par le contenu du fichier, exposant ainsi potentiellement des secrets. Selon les chercheurs de SonarSource, qui ont découvert et signalé la vulnérabilité, les attaquants non authentifiés peuvent l’exploiter s’ils obtiennent l’autorisation de lecture sur le serveur. Ce qui est possible dans plusieurs configurations : si le serveur a une autorisation en mode legacy activée, si il est configuré avec « Allow anonymous read access » coché dans le mode d’autorisation « logged-in users can do anything », ou si la fonction signup est activée et permet à n’importe qui de créer un compte sur le serveur.
Même si aucune de ces conditions n’est remplie, les utilisateurs non authentifiés peuvent toujours lire les premières lignes des fichiers au lieu de leur contenu intégral. « Un attaquant pourrait tirer parti de cette situation en trouvant une commande qui prend un nombre arbitraire d’arguments et les affiche à l’utilisateur », expliquent les chercheurs dans un billet de blog. « Étant donné que les arguments sont tirés du contenu du fichier, un pirate pourrait faire fuiter le contenu du fichier de cette manière. Selon nos recherches, la commande connect-to-node est un bon candidat : elle reçoit une liste de chaînes comme argument et tente de se connecter à chacune d’entre elles. En cas d’échec, un message d’erreur est généré avec le nom du nœud connecté qui a échoué ». Parmi les fichiers du serveur susceptibles d’intéresser un pirate, on peut citer les clés SSH, le fichier /etc/passwd, le fichier /etc/shadow, les secrets et les informations d’identification du projet, le code source et les artefacts de construction, etc. L’équipe de sécurité de Jenkins documente plusieurs chemins d’attaque pour obtenir l’exécution de code à distance et d’autres vols de secrets avec cette vulnérabilité. Il s’agit notamment de l’utilisation abusive de la fonctionnalité « Resource Root URL », de la falsification des cookies « Remember me », de l’insertion d’attaques XSS (Cross-Site Scripting) dans les journaux de build, de la falsification des jetons de protection contre la falsification des requêtes intersites, du décryptage des secrets binaires et du téléchargement d’un dump mémoire Java.
Atténuer la vulnérabilité du serveur CI/CD Jenkins
Le correctif consiste à désactiver l’analyseur de commandes qui expose le contenu des fichiers. Cela peut poser des problèmes pour certains déploiements, auquel cas un mécanisme est disponible pour l’annuler. Cependant, son utilisation est fortement déconseillée sur les instances Jenkins accessibles sur le réseau par des non-administrateurs.
Un autre moyen d’atténuer la menace consiste à désactiver complètement l’accès à l’interface CLI de Jenkins jusqu’à ce que les correctifs puissent être appliqués. Des chercheurs en sécurité ont averti vendredi dernier que plusieurs exploits de preuve de concept pour cette vulnérabilité avaient déjà été publiés sur GitHub et d’autres ont déjà signalé des exploitations de la faille dans la nature.
Pendant un an et demi, un groupe chinois a exploité une vulnérabilité de type zero day dans vCenter sans être détecté. La faille a été corrigée en octobre par VMware.
Dans le terme APT, le p pour persistance prend tout son sens dans une affaire dévoilée par Mandiant. La filiale de Google Cloud a mené des travaux sur le groupe UNC3886 et ses techniques d’attaques. Ils ont notamment découvert que le groupe s’était servi d’une faille zero day dans vCenter de VMware pendant un an et demi. La CVE-2023-34048 a été corrigée en octobre 2023 par le spécialiste de la virtualisation.
Une première alerte en juin 2023
L’histoire de cette affaire débute en juin 2023 où Mandiant a documenté la manière dont le groupe chinois qu’il suit sous le nom de UNC3886 a exploité une vulnérabilité zero day de contournement d’authentification dans VMware Tools (CVE-2023-20867) pour déployer des portes dérobées à l’intérieur de machines virtuelles invitées à partir d’hôtes ESXi compromis. Le flux d’attaque décrit par Mandiant a commencé par l’accès des pirates aux serveurs vCenter, puis l’utilisation de techniques connues pour extraire les informations d’identification en clair du compte vpxuser pour tous les hôtes ESXi attachés au serveur.
C’est ainsi qu’ils ont pu accéder à ces hôtes et exploiter la faille CVE-2023-20867 pour déployer des malwares. Cependant, le mot de passe du compte vpxuser, un compte créé automatiquement sur les hôtes ESXi quand ils sont associés à un serveur vCenter, est chiffré par défaut. Sur un système vCenter entièrement corrigé, le craquage des mots de passe nécessite un accès root. Or, c’est en exploitant la vulnérabilité CVE-2023-34048, corrigée en octobre 2023, que les attaquants ont réussi à obtenir un accès root aux serveurs vCenter.
Attention aux ports réseau
Les analystes judiciaires de Mandiant ont trouvé un point commun sur les systèmes vCenter compromis où les journaux de plantage situés dans /var/log/vMonCoredumper.log montrent que le service vmdird s’arrête quelques minutes avant que les attaquants ne déploient leurs malware. Après avoir partagé cette observation avec l’équipe de sécurité des produits VMware, ainsi que des vidages du noyau de mémoire du processus vmdird bloqué, ils en ont conclu que les blocages étaient étroitement liés au comportement observé lors de l’exploitation de la faille référencée CVE-2023-34048.
Cette faille dite d’écriture hors limites ou « out-of-bounds write » dans l’implémentation du protocole DCERPC conduit à un plantage et à l’exécution de code arbitraire. Elle peut être exploitée à distance via le réseau. « VMware recommande fortement un contrôle strict de l’accès au périmètre réseau pour tous les composants et interfaces de gestion dans vSphere et les composants connexes, comme les composants de stockage et de réseau, dans le cadre d’une posture de sécurité globale efficace », a déclaré VMware dans un document FAQ associé à la vulnérabilité, en précisant que « les ports réseau spécifiques concernés par cette vulnérabilité sont 2012/tcp, 2014/tcp et 2020/tcp ».
Des signes datant de fin 2021 et début 2022
Mandiant dit avoir observé des signes de ces plantages dans les journaux des environnements compromis depuis fin 2021 et début 2022, mais que les vidages de noyau vmdird n’étaient pas présents sur ces systèmes. Un vidage de mémoire complet ou memory core dump est généré automatiquement quand un processus se bloque et la configuration par défaut de VMware consiste à conserver ces vidages de mémoire sur le système pendant une durée indéterminée. Le fait qu’ils aient été supprimés sur de nombreux systèmes suggère que les attaquants les ont volontairement supprimés pour brouiller les pistes.
Les entreprises devraient déjà avoir appliqué les correctifs pour la faille CVE-2023-34048. Cependant, la révélation que des pirates ont exploité cette faille pendant un an et demi sans être inquiété est préoccupante et devrait inciter à des investigations supplémentaires dans les environnements, en particulier pour les indicateurs de compromission et les portes dérobées UNC3886 documentés par Mandiant.
VMware a mis à jour sa plateforme d’automatisation d’infrastructure multi-cloud, Aria Automation. La faille découverte est jugée comme critique avec une sévérité de 9,9.
Anciennement connu sous le nom vRealize Automation, Aria Automation comprend une vulnérabilité critique à corriger rapidement, souligne VMware dans un bulletin de sécurité. La plateforme d’automatisation des infrastructures multi-cloud peut servir à des cybercriminels à accéder à distance au réseau d’une entreprise et à ses workflow. L’offre Cloud Foundation est également concernée si les produits ont été déployés à l’aide d’Aria Suite Lifecycle Manager
La faille référencée CVE-2023-34063 et affectée d’un score de 9,9 sur 10 sur l’échelle de gravité CVSS, résulte d’un problème de « contrôle d’accès manquant ». La vulnérabilité a été signalée en privé à l’entreprise et à l’heure actuelle, VMware n’a pas connaissance d’une exploitation active de la brèche.
Mettre à jour Aria Automation avant de corriger la vulnérabilité
Toutes les versions prises en charge d’Aria Automation sont concernées. Cela inclut les versions 8.11.x, 8.12.x, 8.13.x et 8.14.x. Même si l’entreprise a publié des correctifs individuels pour chacune de ces versions, elle recommande fortement aux utilisateurs de mettre à jour la version 8.16 publiée récemment. Les utilisateurs des déploiements de VMware Cloud Foundation 4.x et 5.x affectés doivent utiliser VMware Aria Suite Lifecycle Manager pour mettre à jour VMware Aria Automation vers la version corrigée.
« Pour appliquer le correctif, le système doit fonctionner avec la dernière version de la version majeure », a expliqué le fournisseur dans un document FAQ dédié à la vulnérabilité. « Par exemple, si le système utilise Aria Automation 8.12.1, il faut d’abord passer à la version 8.12.2 avant d’appliquer le correctif. Après application du correctif, la seule possibilité de mise à niveau est de passer à la version 8.16 ou à une version plus récente », indique encore la FAQ.
Aucune action nécessaire pour Aria Automation Cloud
Aria Automation Cloud n’est pas concerné, car des mesures d’atténuation ont déjà été appliquées au niveau du serveur par VMware qui gère le service. vCenter, ESXi et Aria Orchestrator ne sont pas non plus touchés, mais le fournisseur indique qu’à partir de la version 8.16, l’accès à Automation Orchestrator est désormais régi par des rôles de service Orchestrator distincts. L’entreprise prévient également que si les utilisateurs choisissent de passer à des versions intermédiaires, par exemple de 8.12.x à 8.13.x au lieu de passer à la version 8.16, la vulnérabilité sera réintroduite et une nouvelle série de correctifs sera nécessaire. « D’autres mesures d’atténuation et de compensation peuvent s’appliquer, en fonction du niveau de sécurité, des stratégies de défense en profondeur et de la configuration des pare-feux périmétriques et applicatifs de l’entreprise », a encore déclaré VMware. « Chaque entreprise doit évaluer par elle-même si elle doit s’appuyer sur ces protections et comment configurer efficacement ces mesures pour son environnement ».