Le groupe de cybercriminels Salt Typhoon déploie deux variantes non documentées de la porte dérobée SparrowDoor avec des capacités améliorées de modularité et d’exécution de commandes parallèles.
Salt Typhoon, le célèbre groupe APT soutenu par la Chine, semble avoir mis à jour son arsenal avec des portes dérobées améliorées, alors même que les États-Unis augmentent la pression sur l’espionnage chinois. Selon Eset Research, qui suit le groupe malveillant en tant que FamousSparrow, celui-ci a déployé deux versions de sa porte dérobée SparrowDoor avec plus de modularité et une exécution parallèle des commandes. Ces deux versions de la backdoor « constituent un progrès notable par rapport aux versions précédentes, notamment en termes de qualité du code et d’architecture », explique Eset dans un billet de blog. « L’une d’entre elles ressemble à la porte dérobée que les chercheurs de Trend Micro ont appelée CrowDoor et qu’ils ont attribuée au groupe APT Earth Estries en novembre 2024. GhostSparrow – alias Salt Typhoon (Microsoft), Earth Estries (Trend Micro), Ghost Emperor (Kaspersky Labs) et UNC2286 (Mandiant) – a intensifié ses activités de cyberespionnage en pénétrant dans les réseaux de télécommunications américains et en accédant aux données de plus d’un million de personnes.
L’une des principales caractéristiques des deux variantes inédites signalées par Eset est leur capacité à exécuter des commandes en parallèle. Cela signifie que les dernières variantes peuvent exécuter des tâches en parallèle afin d’améliorer l’efficacité, d’échapper à la détection et de maintenir la persistance. « Le changement le plus important est la parallélisation des commandes qui prennent du temps, telles que les E/S de fichiers et le shell interactif », explique Eset. « Cela permet à la porte dérobée de continuer à traiter des commandes pendant que ces tâches sont exécutées. L’exécution simultanée d’opérations critiques mais chronophages vers d’autres commandes rend la détection et l’interruption plus difficiles, car les tâches telles que l’exfiltration de données ou la modification du système se poursuivent sans interruption, même si l’on tente d’analyser ou d’interrompre la porte dérobée. En outre, le caractère modulaire introduit dans la porte dérobée lui confère une capacité à mettre à jour dynamiquement les configurations, de passer d’un serveur C&C à un autre et d’exécuter des charges utiles personnalisées sans redéploiement, selon Eset
Des variantes inédites utilisées contre des entreprises américaines et mexicaines
Les chercheurs d’Eset ont déclaré avoir repéré les variantes de SparrowDoor lors d’une enquête sur un incident de sécurité survenu en juillet 2024 au sein d’un groupe de commerce financier opérant aux États-Unis. « En aidant l’entité concernée à remédier à la compromission, nous avons fait une découverte inattendue dans le réseau de la victime », ont déclaré les chercheurs. « Cette campagne est également la première fois que FamousSparrow a utilisé ShadowPad, une porte dérobée vendue dans le privé, connue pour n’être fournie qu’à des acteurs de menaces alignés sur la Chine. La campagne s’est étendue à l’intrusion dans un institut de recherche au Mexique, deux jours avant la compromission aux États-Unis. Lorsque les chercheurs ont introduit les techniques et les IoC dans un système de suivi, ils ont révélé d’autres activités, dont une attaque contre un institut gouvernemental au Honduras.
Contrairement à Microsoft qui affirme que Salt Typhoon recouvre la même chose que FamousSparrow et GhostEmperor, Eset n’a pas fait ce choix. « Il y a quelques chevauchements entre les deux, mais de nombreuses divergences », souligne l’entreprise. « D’après nos données et notre analyse des rapports publics, FamousSparrow semble constituer un groupe distinct ayant des liens éloignés avec les autres groupes mentionnés dans ce rapport […] À l’heure où nous écrivons ces lignes, Microsoft, qui a créé le groupe Salt Typhoon, n’a pas publié d’indicateurs techniques ni de détails sur les TTP utilisées par l’acteur de la menace, et n’a pas non plus fourni d’explication à cette attribution. Pour éviter de brouiller davantage les pistes, nous continuerons à suivre le groupe d’activités que nous considérons comme directement lié à SparrowDoor sous le nom de FamousSparrow jusqu’à ce que nous disposions des informations nécessaires pour évaluer de manière fiable ces demandes d’attribution. »
Une vulnérabilité débouchant sur des problèmes de contrôle d’accès inappropriés dans VMware Tools pour Windows a été corrigée par Broadcom. Avec à la clé un risque d’escalade de privilèges sur les machines virtuelles concernées.
Broadcom a averti ses clients de l’existence d’une faille de sécurité de type contournement d’authentification affectant VMware Tools pour Windows. Identifiée sous le nom de CVE-2025-22230, cette vulnérabilité tire parti d’un contrôle d’accès inapproprié et pourrait entraîner une escalade de privilèges sur le système affecté. « Une vulnérabilité de contournement d’authentification dans VMware Tools pour Windows a été signalée à l’éditeur », a déclaré Broadcom dans un avis de sécurité. « Des mises à jour sont disponibles pour remédier à cette faille dans les produits VMware concernés. »
L’outil concerné est une suite d’utilitaires conçus pour améliorer les performances et les fonctionnalités des machines virtuelles basées sur Windows et exécutées sur les hyperviseurs du spécialiste de la virtualisation (ESXi ou Workstation). La faille s’est vue attribuer un score CVSS de 7,8 sur 10 et est considérée d’importance élevée car elle peut être exploitée dans le cadre d’attaques peu complexes sans aucune interaction avec l’utilisateur. « Un acteur malveillant disposant de privilèges non administratifs sur une VM invitée peut avoir la possibilité d’effectuer certaines opérations à privilèges élevés au sein de cette VM », a déclaré Broadcom dans un bulletin de sécurité.
Les versions Linux et macOS de VMware Tools épargnées
Bien que le fournisseur n’ait pas mentionné les privilèges exacts pouvant être obtenus à la suite d’un exploit réussi, les risques courants associés à un privilège de niveau admin/root sur les machines virtuelles vulnérables comprennent l’évasion de VM pour attaquer l’hôte, le déplacement latéral vers d’autres machines virtuelles, ainsi que la création et le contrôle de machines virtuelles malveillantes. Ce trou de sécurité a été signalé à VMware par Sergey Bliznyuk de Positive Technologies. L’avis de Broadcom indique que la brèche n’a pas de solution de contournement et que les clients doivent appliquer les correctifs déployés mardi dernier pour se prémunir contre son exploitation. Les produits concernés comprennent toutes les versions 11.x et 12.x des outils VMware pour Windows, et sont corrigés dans la version 12.5.1. Les outils VMware pour Linux et macOS ne sont pas concernés et les clients n’ont rien à faire.
Au début du mois, VMware avait déjà comblé trois vulnérabilités critiques affectant ses produits ESXi, Workstation et Fusion, qui étaient activement exploitées dans la nature par des attaquants. Ses solutions constituent une cible attrayante pour les acteurs de la menace en raison de leur utilisation intensive dans les SI des entreprises, le cloud et les centres de données. L’exploitation de ces produits peut donner la possibilité aux attaquants d’obtenir des accès à privilèges, de perturber les services critiques et de faciliter les mouvements latéraux dans les environnements virtualisés.
Des chercheurs en sécurité d’Oligo ont découvert une vulnérabilité critique affectant les grands modèles de langage LLama de Meta. Elle ouvre la voie à l’exécution de code arbitraire distant en envoyant des données malveillantes désérialisées.
La sécurité de l’IA devient un sujet préoccupant avec des techniques en pleine évolution. Preuve en est la faille critique trouvée dans le LLM Llama de Meta pouvant entraîner des attaques RCE (remote code execution). Elles peuvent engendrer sur du vol et de la compromission de données, voire aller jusqu’à de la prise de contrôle de LLM. Répertorié en tant que CVE-2024-50050, ce trou de sécurité lié découle de l’utilisation inappropriée de la bibliothèque open source orientée message (pyzmq) dans les frameworks d’IA.
« L’équipe de recherche d’Oligo a découvert une vulnérabilité critique dans meta-llama, un framework open source de Meta pour construire et déployer des applications GenAI », ont déclaré les chercheurs en sécurité d’Oligo dans un billet de blog. « La faille, CVE-2024-50050, permet aux attaquants d’exécuter un code arbitraire sur le serveur d’inférence llama-stack depuis le réseau. » Selon les chercheurs du fournisseur en solutions de sécurité, un certain nombre de frameworks d’IA open source exploitent une bibliothèque open source orientée message (pyzmq) d’une « manière peu sûre », permettant l’exécution de code à distance. Le problème vient du fait que Llama Stack utilise pickle, un module Python pour la sérialisation et la désérialisation d’objets Python, dans son implémentation « inference API », une fonctionnalité que Llama propose aux entreprises pour intégrer leurs propres modèles ML dans le pipeline applicatif.
Une faille signalée et corrigée par Meta
Pickle est intrinsèquement capable d’exécuter des codes arbitraires lors de la désérialisation de données non fiables (crafts) envoyées par des attaquants, en particulier avec la mise en œuvre exposée de pyzmq (une liaison Python pour ZeroMQ). « Dans les scénarios où le socket ZeroMQ est exposé sur le réseau, les attaquants pourraient exploiter cette vulnérabilité en envoyant des objets malveillants élaborés au socket », ont déclaré les chercheurs, ajoutant que l’unpickling de ces objets [conversion de fichier binaire en objets Python, ndlr] pourrait donner aux attaquants la capacité de réaliser une exécution de code arbitraire (RCE) sur la machine hôte. Suite à cette découverte, l’équipe de sécurité de Meta a rapidement patché Llama Stack, en changeant le format de sérialisation pour la communication socket de pickle à JSON.
Oligo Research a signalé la vulnérabilité à Meta le 29 septembre 2024, qui l’a ensuite reconnue et publié un correctif sur GitHub le 10 octobre 2024, avec une version corrigée 0.0.41 poussée sur l’index de package Python (PyPi). Le 24 octobre dernier, Meta l’a ensuite identifiée en tant que CVE-2024-50050 avec un score CVSS de 6,3 (gravité moyenne). De son côté Snyk, spécialisé dans la sécurité du développement logiciel, a reconnu une plus grande dangerosité de ce trou de sécurité en lui attribuant un score CVSS critique de 9,3 pour la version 4.0 de Llama Stack et même de 9,8 pour la v3.1.
Meta n’a pas répondu à CSO aux demandes de précision su la gravité de la faille jusqu’à la publication de cet article. La vulnérabilité est actuellement en attente d’analyse par la National Vulnerability Database (NVD), un référentiel complet de vulnérabilités divulguées publiquement, géré par le NIST.
Un chercheur a découvert une faille API dans ChatGPT donnant la capacité à des attaquants d’employer son crawler pour lancer des attaques DDoS contre des sites web. Prévenus, ni OpenAI ni Microsoft n’ont pour l’heure réagi.
ChatGPT, propriété d’OpenAI, présenterait une vulnérabilité où des acteurs malveillants seraient capables de lancer des attaques par déni de service distribué (DDoS) sur des cibles qui ne se doutent de rien. Selon une découverte faite par le chercheur en sécurité allemand Benjamin Flesch, le crawler de l’assistant IA utilise pour collecter des données sur l’internet afin de l’améliorer peut être piégé pour lancer des attaques en déni de service sur des sites web. « Le crawler ChatGPT peut être déclenché pour attaquer un site web victime par le biais d’une requête HTTP à l’API ChatGPT non reliée », a déclaré le chercheur dans un repo Github dans lequel et décrit son PoC. « Ce défaut dans le logiciel OpenAI provoquera une attaque DDoS sur le site web victime, en utilisant plusieurs plages d’adresses IP Microsoft Azure sur lesquelles le robot de ChatGPT est en cours d’exécution ». M. Flesch précise que la découverte a été faite en janvier 2025 et qu’elle a depuis été portée à la connaissance d’OpenAI et de Microsoft, qui n’ont pas encore reconnu l’existence de la vulnérabilité.
Il a souligné que l’API ChatGPT présentait une faille importante lors du traitement des requêtes HTTP POST. L’API exige une liste d’URL, mais ne vérifie pas s’il y a des liens hypertextes en double et n’impose pas de limite à leur nombre, ce qui autorise potentiellement des milliers de liens hypertextes dans une seule requête HTTP. « Il est communément admis que les liens hypertextes vers un même site web peuvent être écrits de différentes manières », a déclaré M. Flesch. « En raison de mauvaises pratiques de programmation, OpenAI ne vérifie pas si un lien hypertexte vers la même ressource apparaît plusieurs fois dans la liste. » L’API traite individuellement chaque hyperlien dans une requête POST, en utilisant les serveurs Microsoft Azure, ce qui entraîne de nombreuses tentatives de connexion simultanées au site cible. Le volume important de connexions provenant des serveurs OpenAI qui en résulte peut potentiellement submerger le site web ciblé.
La même API déjà ouverte aux attaques par injection de prompt
Selon une autre divulgation faite par Benjamin Flesch, la même API est également vulnérable aux attaques par injection de prompt. Le problème vient du fait que l’API accepte des paramètres « urls » contenant des commandes textuelles pour leur LLM. Il peut être exploité afin que le crawler réponde via l’API à des questions au lieu de récupérer des sites web comme prévu.
« En raison du grand nombre d’invites qui peuvent être soumises via le paramètre urls, ce défaut logiciel pourrait servir à ralentir les serveurs d’OpenAI », a ajouté le chercheur. Bien que la reconnaissance et l’énumération des failles soient encore attendues, il a placé la gravité de la faille permettant le DDoS à 8,6 sur 10 sur l’échelle CVSS, en raison de sa nature basée sur le réseau, de sa faible complexité, de l’absence d’exigence de privilèges ou d’interaction avec l’utilisateur, et de l’impact élevé sur la disponibilité des services. Les demandes envoyées à OpenAI pour obtenir un accusé de réception et d’autres détails sur la faille n’ont reçu aucune réponse jusqu’à la publication de cet article.
Le cybercriminel IntelBroker a mis en vente des codes sources volés de produits HPE, des clés d’accès privées et publiques, ainsi que des informations personnelles de clients. Le fournisseur a lancé une enquête.
IntelBroker a encore frappé. Cette fois, le tristement célèbre chef de file de BreachForums, qui a une longue liste de victimes de premier plan, dont Europol, Cisco et GE, a affirmé avoir pénétré dans le géant informatique Hewlett Packard Enterprise (HPE). Le pirate présumé d’origine serbe propose de vendre sur BreachForums des données sensibles prétendument volées au fournisseur, notamment des codes sources de produits et des informations personnelles identifiables de clients. « Aujourd’hui, je vends la violation de données de HPE », a déclaré IntelBroker dans un message publié sur BreachForums. « Nous nous connectons à certains de leurs services depuis environ deux jours.
Dans son message sur BreachForums, IntelBroker a proposé de vendre une grande quantité de données sensibles de HPE, notamment des codes sources, des données d’utilisateur et des clés d’accès. Les données compromises sont les suivantes : « Code source : dépôts GitHub privés, Build Docker, SAP Hybrid, certificat (clés privées et publiques) », a écrit IntelBroker. « Accès : Accès API, WePay, Github, Github (auto-hébergé) et plus encore ! » En outre, cette archive contiendrait les codes sources de Zerto (contrôle de l’intégrité des backups) et iLO (outil de gestion) de HPE, ainsi que les informations personnelles de livraison des anciens utilisateurs de la société.
Un pirate particulièrement actif
Le média Hackread, qui affirme avoir vu l’échantillon de données partagé par le pirate, a indiqué qu’il semblait « faire référence à un environnement de développement ou de système impliquant à la fois des logiciels libres et des systèmes de gestion propriétaires ». « Plusieurs conclusions de l’analyse initiale de Hackread ont révélé que les affirmations du pirate se vérifiaient pour l’essentiel. IntelBroker aurait déclaré qu’il s’agissait d’un piratage direct et qu’il n’y avait pas eu de compromission par un tiers.
Le cybercriminel, qui figure régulièrement sur BreachForums, a fait des vagues en 2024 avec une série d’attaques très médiatisées. Ce pirate a ciblé un large éventail d’entreprises dans le passé, telles que General Electric, Europol, Lulu Hypermarket, et Zscaler, avec des violations antérieures incluant des acteurs majeurs tels que Home Depot, Facebook Marketplace, et Space-Eyes. En juin 2024, IntelBroker a intensifié ses activités en divulguant ou en vendant des données provenant d’entreprises telles que T-Mobile, AMD et Apple. Récemment, en octobre, IntelBroker a proposé de vendre un énorme corpus de données de violations de Cisco que les experts ont relié aux fuites de juin, étant donné l’utilisation intensive des services de Cisco par T-Mobile et AMD, mais le lien n’a jamais été confirmé. HPE n’a pas répondu aux questions posées par courriel au sujet de l’attaque. Bien qu’IntelBroker ait déjà exagéré les brèches d’Apple et d’Europol, l’acteur malveillant n’est pas connu pour avoir fait une déclaration de brèche entièrement fausse dans le passé.
Les identifants compromis neutralisés
Le fournisseur a déclaré être au courant des allégations de violation et mener une enquête. « HPE a pris connaissance le 16 janvier d’allégations faites par un groupe appelé IntelBroker selon lesquelles il était en possession d’informations appartenant à HPE. La société a immédiatement activé ses protocoles de cyber-réponse, neutralisé les informations d’identification correspondantes et lancé une enquête pour évaluer la validité des allégations », a déclaré à SecurityWeek Adam Bauer, porte-parole de HPE.
L’agence de cybersécurité américaine a alerté que des pirates exploitent activement deux vulnérabilités dans la suite de communication et de collaboration MiCollab de Mitel. Une vigilance particulière concernant la CVE-2024-41713 classée critique est de mise.
Dans un dernier bulletin mardi dernier, l’agence de cybersécurité américaine (CISA) a ajouté à son catalogue de vulnérabilités exploitées connues (KEV) trois failles dont deux concernent la suite d’outils de communication et de collaboration MiCollab de Mitel. De type path traversal, ces trous de sécurité ont servi. « Ces types de vulnérabilités sont des vecteurs d’attaque fréquents pour les cyberattaquants et posent des risques importants pour les agences fédérales », a déclaré la CISA. Les attaques path transversal (ou directory traversal) visent à accéder aux fichiers et aux répertoires qui sont stockés en dehors du dossier racine d’un site web. Les versions 9.8 SP1 FP2 (9.8.1.201) et antérieures de MiCollab sont concernées, et les upgrades 9.8 SP2 (9.8.2.12) ou postérieurs corrigent ces failles.
La première vulnérabilité, répertoriée sous la référence CVE-2024-41713, est critique (CVSS 9.8/10) et affecte le composant NuPoint Unified Messaging de MiCollab qui donne la possibilité à un attaquant non authentifié d’exploiter un manque de validation d’entrée suffisante pour obtenir un accès non autorisé et visualiser, corrompre ou supprimer les données des utilisateurs et les configurations système. « Si la vulnérabilité est exploitée avec succès, un attaquant peut obtenir un accès non authentifié aux informations de provisionnement, y compris des informations non sensibles sur l’utilisateur et le réseau, et effectuer des actions administratives non autorisées sur le serveur MiCollab », prévient Mitel. La seconde faille (CVE-2024-55550), classée comme modérément sévère (CVSS 4.4/10), peut déboucher sur la lecture de fichier local au sein du système en raison d’une vérification insuffisante des entrées. « Une exploitation réussie pourrait permettre à un attaquant authentifié disposant des privilèges d’administration d’accéder à des ressources limitées au niveau d’accès administrateur, et la divulgation est limitée à des informations système non sensibles », a expliqué Mitel. Cette faille ne permet pas cependant de modifier des fichiers ou aboutir à de l’escalade des privilèges.
Des correctifs publiés depuis octobre 2024
Bien que les détails techniques d’exploit n’aient pas été divulgués dans la mise à jour de la CISA, il est important de noter que ces vulnérabilités pourraient être enchaînées pour permettre à des attaquants distants de lire des fichiers système sensibles. En octobre dernier, Mitel avait publié des correctifs pour les versions affectées ainsi que des versions corrigées vers lesquelles les utilisateurs peuvent se mettre à jour. L’exploitation active montre que nombre d’utilisateurs n’ont pas encore procédé à la mise à jour de leurs applications et qu’il est nécessaire de le faire dès que possible. La CISA a recommandé aux agences de l’administration civile fédérale de corriger les systèmes concernés conformément à la directive BOD 22-01, qui exige qu’elles corrigent les failles dans un délai de 15 jours si elles sont activement exploitées.
On se demande bien pourquoi ce délai ne court pas après la publication d’un correctif par un fournisseur… Qui a dit qu’il fallait mieux prévenir que guérir ?
Spécialisé dans la détection de failles de sécurité, le scanner open source Nuclei est victime d’une vulnérabilité ouvrant la voie à l’exécution de code distant. Des attaquants peuvent alors contourner le processus de vérification de la signature des modèles de cet outil pour injecter des codes malveillants dans les systèmes hôtes.
Nuclei, un outil open source très populaire utilisé pour analyser les vulnérabilités et les faiblesses des sites web, des applications cloud et des réseaux, présente une faille de haute sévérité qui pourrait potentiellement permettre aux attaquants d’exécuter des codes malveillants sur des systèmes locaux. Le trou de sécurité, répertorié en tant que CVE-2024-43405, a reçu un score CVSS de 7,4 sur 10 et affecte toutes les versions de Nuclei postérieures à la version 3.0.0. Les attaquants peuvent utiliser des modèles malveillants conçus avec des codes arbitraires donnant potentiellement accès à des données sensibles de l’hôte, selon les chercheurs de la société de sécurité cloud Wiz, qui a été crédité de la découverte de cette faille. Le PoC de contournement détaillé a été publié.
Selon une description de ProjectDiscovery, le développeur et mainteneur de Nuclei, cette faille a été détectée dans le processus de vérification de la signature des modèles, en particulier dans le paquet signer. « Une vulnérabilité a été identifiée dans le système de vérification de la signature des modèles de Nuclei qui pourrait permettre à un attaquant de contourner la vérification de la signature et éventuellement d’exécuter un code malveillant via un modèle de code personnalisé », a expliqué ProjectDiscovery. Un correctif a été apporté dans la version 3.3.2 de Nuclei.
Processus de vérification des signatures et analyse YAML divergent
Nuclei a recueilli plus de 21 000 étoiles sur GitHub et a été téléchargé plus de 2,1 millions de fois. L’outil utilise des « modèles », sous forme de fichiers YAML, qui définissent des vérifications ou des tests spécifiques pour le processus d’analyse des vulnérabilités. Il est essentiel de garantir l’authenticité de ces modèles pour éviter que certains altérés ou malveillants induisent en erreur ou compromettent le processus d’analyse. Nuclei a mis en place un processus de vérification des signatures basé sur Go regex pour garantir l’authenticité.
La vulnérabilité provient d’une divergence entre la façon dont le processus de vérification des signatures et l’analyseur YAML traitent les caractères de nouvelle ligne, a expliqué ProjectDiscovery. Alors que la logique de vérification de Go considère que r fait partie de la même ligne, l’analyseur YAML le traite comme un saut de ligne, laissant ainsi la possibilité aux attaquants d’insérer des codes malveillants. Ceci, combiné au fait que Nuclei traite mal les lignes de signature multiples digest: peut potentiellement conduire un attaquant à injecter du contenu malveillant dans un modèle tout en gardant la signature valide pour la partie inoffensive du modèle.
Les utilisateurs des versions CLI et SDK concernés
Selon les experts, les utilisateurs de Nuclei, aussi bien en CLI qu’en SDK, sont concernés et doivent appliquer des correctifs. La version CLI comprend ceux qui exécutent des modèles de code personnalisés à partir de sources non vérifiées telles que des tiers et des dépôts non vérifiés. Ceux passant par le kit de développement logiciel sont concernés lorsque les développeurs qui intègrent Nuclei dans leurs plateformes autorisent l’exécution de modèles de code personnalisés par les utilisateurs finaux. Outre la mise à niveau vers la version corrigée disponible depuis le 4 septembre 2024, une mesure de contournement consiste à s’abstenir d’utiliser des modèles personnalisés d’après ProjectDiscovery.
Un rootkit élaboré baptisé Pumakit cible les systèmes Linux et utilise des techniques furtives avancées à des fins d’élévation de privilèges et pour échapper à toute détection.
Un dernier rootkit LKM (loadable kernel module) a été repéré dans la nature, compromettant les systèmes Linux grâce à des fonctions avancées de furtivité et d’élévation des privilèges. Pumakit, a été baptisé ainsi par les chercheurs d’Elastic Security qui l’ont découvert lors d’une chasse aux menaces de routine sur VirusTotal. Il est déployé dans le cadre d’une architecture de logiciels malveillants en plusieurs étapes qui se compose d’un dropper, de deux exécutables résidant en mémoire, d’un module de rootkit LKM et d’un rootkit d’objets partagés (SO) en zone utilisateur. Le composant rootkit, désigné par les auteurs du malware sous le nom de Puma, utilise un traceur de fonctions Linux interne (ftrace) doté de 18 appels syscall différents et de plusieurs fonctions au niveau du noyau afin de manipuler les comportements du système central, ont déclaré les chercheurs.
Les rootkits sont des programmes malveillants ou des collections d’outils spécialisés pouvant s’établir durablement dans des systèmes compromis et sont souvent utilisés par les groupes de menaces persistantes avancées (APT), ciblant les entreprises dans des secteurs critiques. Les chercheurs d’Elastic Security ont pu retracer le déploiement jusqu’au 4 septembre 2024, date à laquelle le binaire suspect associé (cron) a été téléchargé.
Un déploiement en plusieurs étapes
Pumakit, qui tire son nom du module Puma du noyau et du rootkit Kitsune, utilise un processus d’infection en plusieurs étapes qui commence par un binaire « cron » altéré. Celui-ci camoufle le logiciel malveillant en processus système légitime, ce qui lui permet de se fondre dans le système. Le dropper crée deux exécutables en mémoire : /memfd:tgt, un binaire cron inoffensif, et /memfd:wpn, un chargeur de rootkit. Ce dernier évalue l’environnement, exécute des charges utiles supplémentaires et prépare le système au déploiement du rootkit.
Un script temporaire, script.sh, est exécuté à partir de /tmp pour finaliser le déploiement du module de rootkit du noyau Puma. Celui-ci intègre Kitsune SO pour faciliter les interactions avec les utilisateurs, ce qui garantit un processus d’infection transparent et furtif. Les principales caractéristiques de ce module noyau comprennent : élévation des privilèges, masquage des fichiers et des répertoires, évitement de la détection par les outils du système, mise en œuvre de techniques anti-débogage, et possibilité de communiquer avec des serveurs de commande et de contrôle (C2), ont ajouté les chercheurs.
Des capacités d’évasion avancées
Le rootkit s’active en fonction de certaines conditions, tel que l’état du démarrage sécurisé et d’autres facteurs nécessaires avant de se charger. Il cible les noyaux Linux antérieurs à la version 5.7, car les versions plus récentes ne prennent plus en charge la fonction kallsyms_lookup_name(), sur laquelle le rootkit s’appuie. À l’aide de cette fonction, le rootkit Puma manipule le comportement du système. En utilisant des méthodes « non conventionnelles », il parvient via ftrace, ce qui lui permet d’augmenter les privilèges, exécuter des commandes et dissimuler des processus, ont ajouté les chercheurs. Le rootkit modifie également les informations d’identification avec prepare_creds et commit_creds, ce qui offre à l’utilisateur root d’accéder à des processus spécifiques.
En coordination avec le rootkit Kitsune, Puma étend son contrôle en masquant les fichiers, les processus et les connexions réseau. Kitsune intercepte les appels système tels que ls, ps et top pour éviter d’être détecté et gère la communication avec le serveur de commande et de contrôle, en transmettant des données système et en recevant des commandes. Elastic Security a développé une signature Yara pour détecter Pumakit, y compris le dropper (cron), le chargeur de rootkit (/memfd:wpn), le rootkit LKM et les fichiers d’objets partagés Kitsune.
Une vulnérabilité critique dans Service Provider Console de Veeam (VSPC) entraîne l’exécution de code distant et son correctif est à appliquer dès que possible. Une seconde faille débouchant sur de la suppression non autorisée de fichiers dans les serveurs VSPC a aussi été comblée.
Veeam a prévenu de l’existence de deux vulnérabilités, dont l’une est une RCE critique, affectant sa plateforme de gestion basée sur le web pour les fournisseurs de services managés, Service Provider Console (VSPC). Mardi, le fournisseur de solutions de back-up as a service et de restauration, qui assure la disponibilité des systèmes informatiques pour des marques de premier plan telles que Cisco, Lenovo et la NASA, a publié un avis indiquant que l’exploitation des bogues n’est possible que dans certaines circonstances. Bien qu’une mise à jour contenant les correctifs nécessaires ait été fournie, aucune mesure d’atténuation n’est actuellement disponible pour les instances défectueuses.
La première corrigée dans cette mise à jour, identifiée comme CVE-2024-42448, est critique et ouvre la voie à de l’exécution de code à distance (RCE) qui pourrait entraîner l’exécution du code arbitraire sur des machines serveurs VSPC non corrigées. « Depuis la machine de l’agent de gestion VSPC, à condition que l’agent de gestion soit autorisé sur le serveur, il est possible de réaliser une exécution de code à distance (RCE) sur la machine du serveur VSPC », a déclaré Veeam. La vulnérabilité, qui aurait été découverte lors des tests internes de Veeam, a reçu une note critique avec un score CVSS de 9.9/10. Une recherche rapide sur la populaire plateforme de recherche de fuites LeakIX, au moment de la publication de cet article, a révélé plus d’un million (1 186 722) d’instances VSPC potentiellement affectées sur Internet, dont environ la moitié rien qu’aux États-Unis et en Allemagne. La vulnérabilité affecte les versions 8.1.0.21377 et antérieures de VSPC (8 et & builds), et a été corrigée dans la mise à jour 8.1.0.21999. « Les versions de produits plus supportées ne sont pas testées, mais sont probablement affectées et doivent être considérées comme vulnérables », a écrit l’entreprise.
Une seconde faille importante à patcher
En plus de ce trou de sécurité critique RCE, Veeam a aussi alerté de l’existence d’autre faille de sécurité importante, répertoriée en tant que CVE-2024-42449, donnant la possibilité à des attaquants d’effectuer une suppression non autorisée des fichiers du serveur VSPC. « Depuis la machine de l’agent de gestion VSPC, à condition que celui-ci soit autorisé sur le serveur, il est possible d’exfiltrer un hachage NTLM du compte de service du serveur VSPC et de supprimer des fichiers sur la machine du serveur VSPC », a déclaré Veeam. La faille, qui a reçu un score CVSS de 7.1/10, a été corrigée dans la même mise à jour et, comme le bogue RCE, n’affecterait pas d’autres produits Veeam tels que Backup and Replication (VBR), Agent for Microsoft Windows et ONE. Une autre faille RCE critique affectant VBR, répertoriée comme CVE-2024-40711, avait été divulguée plus tôt en septembre et a ensuite été signalée comme étant exploitée dans l’une des infections zero day des opérateurs de ransomware Akira (découvert en mars 2023) et Fog.
Les dernières recommandations de Microsoft dans le cadre de son initiative pour un avenir sûr comprennent l’obligation d’utiliser l’authentification multifacteur, l’isolation des terminaux et la sécurité des secrets.
Lors de sa conférence Ignite de mardi, Microsoft a fait le point sur l’état d’avancement de son initiative pour un avenir sûr (Secure Future Initiative ou SFI), lancée il y a un an, qui comprenait des mesures importantes telles que l’application de l’authentification multifacteur (MFA) par défaut pour les instances, l’isolation de près de 100 000 terminaux professionnels dans le cadre de politiques d’accès conditionnel et le blocage des secrets GitHub pour réduire leur exposition aux menaces. Le rapport d’étape, structuré autour des six piliers d’ingénierie habituels de Microsoft utilisés pour évaluer ses avancées, présente des perspectives plus prometteuses par rapport à une précédente mise à jour de septembre qui portait sur la rotation des informations d’identification, les contrôles d’accès JIT/JEA et la surveillance des menaces.
« En mai 2024, le CEO de Microsoft, Satya Nadella, a fait de la sécurité la priorité absolue de l’entreprise », a déclaré Microsoft dans son document. « Depuis lors, nous avons consacré l’équivalent de 34 000 ingénieurs à l’avancement des objectifs énoncés dans la SFI, ce qui en fait le plus grand projet d’ingénierie de cybersécurité de l’histoire. » Microsoft a également souligné les efforts déployés pour intégrer la sécurité dans sa culture, en menant à bien plusieurs initiatives en matière d’apprentissage et de gouvernance, notamment des formations obligatoires à la sécurité du personnel par l’intermédiaire de la Microsoft Security Academy, et en s’engageant à respecter l’engagement CISA « secure by design » (« sécurité dès la conception »).
Microsoft s’engage à protéger les identités, les secrets et les systèmes
Microsoft a souligné son engagement en faveur de la sécurité en intégrant une série de cadres « sécurisés dès la conception » dans ses processus. L’entreprise a défini quatre piliers d’ingénierie SFI clés pour soutenir cet effort : la protection des identités et des secrets, l’isolation des systèmes de production pour protéger les instances, la protection des réseaux et la sécurisation des systèmes d’ingénierie. À cette fin, le fournisseur, qui dispose d’outils d’identité tels que Azure AD, Entra, Defender et Authenticator, a mis en place le MFA par défaut pour tous ces nouvelles instances hôtes. En outre, il met en œuvre une MFA résistante à l’hameçonnage dans ses environnements de productivité. « Pour aider à sécuriser les clients, l’authentification multifacteur (MFA) est désormais activée par défaut pour les hôtes et sera appliquée pour le portail Azure, le centre d’administration Entra, celui d’Intune et celui de Microsoft 365 », indique l’éditeur. Azure Managed Identity for service-to-service (S2S) a également été mis en œuvre à grande échelle pour les applications Entra ID et les ressources Azure, afin de protéger les secrets tels que les mots de passe, les clés d’accès au stockage et les jetons SAS de stockage contre les fuites.
Afin d’atténuer les risques liés aux terminaux, Microsoft a indiqué avoir déployé 98 000 PC verrouillés prêts pour la production (fonctionnant uniquement avec des fonctionnalités sécurisées et limitées), et avoir transféré 28 000 « utilisateurs à haut risque » vers une solution de virtualisation de poste de travail (VDI) personnalisée et verrouillée. « Pour aider les clients à se protéger, nous avons introduit un modèle d’accès conditionnel Entra, actuellement en avant-première publique, qui exige la conformité des terminaux », a déclaré Microsoft. Dans le cadre du pilier « protéger les systèmes d’ingénierie », qui fait référence aux pratiques visant à réduire le risque de secrets et d’informations d’identification dans son code, l’entreprise a déployé GitHub Advanced Security pour bloquer l’exposition de nouveaux secrets dans les référentiels GitHub et Azure DevOps Git.
Une attention accrue à la gestion des menaces
Pour lutter contre les fuites de secrets, Microsoft s’efforce de « supprimer les secrets du code et d’autres méthodes de stockage et de transmission non sécurisées ». Il a mis en œuvre « des normes de protocoles d’authentification forte qui ne reposent pas sur des mécanismes faibles tels que les informations d’identification en clair et qui détectent, bloquent et suppriment activement les secrets et les informations d’identification exposés. » Concernant la protection des réseaux, Azure Virtual Network Encryption est disponible dans toutes les régions et la prise en charge des extensions de sécurité du système de noms de domaine est disponible en avant-première publique. En outre, pour favoriser « l’isolation et la segmentation » de la gestion et des services, plus de 99,3 % des actifs physiques ont été inventoriés et des listes de contrôle d’accès (ACL) obligatoires leur ont été appliquées, afin d’isoler leur gestion, explique Microsoft.
La société a attribué une poignée d’autres améliorations aux autres piliers de la SFI : surveiller et détecter les menaces, et accélérer la réponse et la remédiation. Pour faciliter l’amélioration de la surveillance des systèmes en vue de la détection des menaces, Microsoft a déclaré qu’il avait étendu les capacités de journalisation dans le cloud, qui comprennent des journaux détaillés de plus de 30 types de données et une conservation standard des logs pendant 180 jours. Ces fonctionnalités sont disponibles par défaut pour les clients de 365, sans coût supplémentaire, a ajouté Microsoft. En outre, l’entreprise a déclaré avoir mis en place une gestion centralisée et une période de conservation de deux ans pour les journaux d’audit de sécurité de l’infrastructure d’identité. Dans le cadre des initiatives de gestion des menaces, l’entreprise a déclaré avoir corrigé 90 % des vulnérabilités dans le délai imparti pour atténuer les effets des vulnérabilités les plus graves de l’informatique cloud. Elle a également déclaré avoir publié près de 800 vulnérabilités et expositions communes (CVE) dans le cadre d’un effort de communication transparent. « Microsoft continue de progresser dans la réalisation de ses objectifs en matière de SFI », a déclaré Vasu Jakkal, vice-président chargé de la sécurité chez Microsoft. « Dans ce rapport, nous soulignons les investissements que nous réalisons dans l’ensemble de l’entreprise pour identifier, hiérarchiser et traiter les risques de cybersécurité dans toute l’entreprise.