Afin de corriger la vulnérabilité du service Windows Server Update Service (WSUS) que Microsoft n’a pas réussi à corriger complètement au début du mois, les entreprises sont invitées à appliquer des correctifs hors bande à plusieurs versions de Windows Server.
Jeudi dernier, Microsoft a publié une série de correctifs hors bande pour corriger « de manière exhaustive » une vulnérabilité critique dans le service de mise à jour Windows Server Update Service (WSUS), les premiers correctifs publiés le 14 octobre s’étant révélés insuffisants. Les pirates ont exploité cette vulnérabilité après la publication la semaine dernière d’une analyse détaillée de la vulnérabilité et d’un exploit de preuve de concept. Identifiée par la référence CVE-2025-59287, cette faille résulte d’une désérialisation non sécurisée de l’objet AuthorizationCookie dans les environnements WSUS. Une exploitation réussie permet l’exécution de code à distance avec des privilèges System.
WSUS est couramment utilisé dans les environnements d’entreprise pour fournir des mises à jour Microsoft aux systèmes Windows de manière contrôlée. Le service n’est pas activé par défaut sur les serveurs Windows, mais peut être mis en route en activant le rôle serveur WSUS. Dans sa mise à jour Patch Tuesday du 14 octobre, Microsoft avait bien inclus un correctif pour la vulnérabilité CVE-2025-59287. Sauf que, apparemment, le correctif initial était incomplet, obligeant l’éditeur à délivrer une autre série de mises à jour pour Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2022 (édition 23H2, installation Server Core) et Windows Server 2025. Selon le dernier avis du fournisseur, les entreprises doivent déployer ces mises à jour dès que possible. Les solutions de contournement consistent à désactiver le rôle de serveur WSUS ou à bloquer le trafic entrant vers les ports 8530 et 8531, mais ces deux actions rendront le service inopérant jusqu’au déploiement des correctifs.
Des attaques observées dans la nature
L’avis de Microsoft ne mentionne pas d’exploitation dans la nature, mais des chercheurs de l’entreprise de cybersécurité Huntress et du Centre national de cybersécurité du gouvernement néerlandais (Dutch National Cyber Security Center, NCSC) ont séparément signalé des preuves d’attaques. Celles-ci sont intervenues après l’analyse détaillée et la preuve de concept de l’exploitation de la faille publiée mercredi dernier par des chercheurs de l’entreprise de cybersécurité HawkTrace. « À partir du 23 octobre 2025 à 23 h 34 UTC, Huntress a observé des acteurs malveillants ciblant des instances WSUS exposées publiquement sur leurs ports par défaut (8530/TCP et 8531/TCP) », a écrit l’entreprise dans un article de blog vendredi. « Les attaquants ont exploité les points de terminaison WSUS exposés pour envoyer des requêtes spécialement conçues (plusieurs appels POST aux services web WSUS) qui ont déclenché une désérialisation RCE contre le service de mise à jour. »
La mise en œuvre de d’exploit a entraîné la génération d’instances d’invite de commande et d’instances PowerShell par le processus de travail WSUS. Une charge utile codée en base64 a été téléchargée et exécutée dans PowerShell afin de découvrir les serveurs du réseau et de collecter des informations sur les utilisateurs, lesquelles ont ensuite été renvoyées à une URL contrôlée à distance par l’attaquant. Le rapport Huntress comprend des indicateurs détaillés de compromission, des artefacts médico-légaux et des règles de détection au format ouvert Sigma SIEM.
Ivanti confirme que la vulnérabilité d’injection de commande affectant Cloud Service Appliance, qui avait été corrigée par la dernière mise à jour 4.6, est en cours d’exploitation dans les entreprises.
Le fournisseur de solutions de gestion IT Ivanti a confirmé qu’une faille très grave, corrigée la semaine passée dans une ancienne version de Cloud Service Appliance (CSA), a été exploitée lors de cyberattaques. La vulnérabilité a été corrigée dans le cadre de la mise à jour de sécurité de septembre du fournisseur, qui comprenait également des correctifs pour des failles critiques et de haute sévérité dans d’autres produits. « Suite à la…
Il vous reste 92% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Akamai rapporte que près de 700 000 attaques et 27 000 de ses clients ont été scannés pour la vulnérabilité.
Selon l’alerte lancée par des chercheurs d’Akamai, une vulnérabilité corrigée ce mois-ci dans VMware Aria Operations for Networks, anciennement vRealize Network Insight, est maintenant exploitée en masse. Classée comme critique, la faille permet l’exécution de code à distance par injection de commande. « Les dernières données d’Akamai indiquent une analyse active des sites vulnérables à la faille référencée CVE-2023-20887, bien au-delà de ce qui avait été initialement signalé », ont déclaré des chercheurs d’Akamai par courriel. « Jusqu’à présent, nous avons comptabilité 695 072 attaques totales par 508 adresses IP uniques », ont-ils ajouté. Akamai a également observé que plus de 27 000 sites de ses clients étaient scannés.
D’autres failles dans VMware Aria Operations
VMware a publié le 7 juin des correctifs pour la vulnérabilité CVE-2023-20887, ainsi que des correctifs pour deux autres failles dans Aria Operations for Networks, dont l’une est également critique et peut conduire à l’exécution de code à distance. Alors que la vulnérabilité CVE-2023-20887 est une faille d’injection de commande, la seconde vulnérabilité, portant la référence CVE-2023-20888, résulte d’un problème de désérialisation. Dans les langages de programmation, la sérialisation est le processus de transformation des données en un flux d’octets pour la transmission à une autre application et la désérialisation est l’inverse de ce processus. Comme les routines de désérialisation impliquent l’analyse et l’interprétation de données contrôlées par l’utilisateur, elles sont à l’origine de nombreuses vulnérabilités. Les attaquants peuvent exploiter les vulnérabilités CVE-2023-20887 et CVE-2023-20888 s’ils disposent d’un accès réseau à l’application vulnérable. Cependant, cette dernière exige aussi que l’attaquant dispose des identifiants du « membre » pour effectuer l’attaque, ce qui complique son exploitation. La troisième vulnérabilité, référencée CVE-2023-20889, est une vulnérabilité d’injection de commande qui peut conduire à la divulgation d’informations sensibles. Elle est affectée du score 8.8 (élevé) sur l’échelle de gravité CVSS.
VMware conseille à ses clients de déployer les correctifs disponibles pour leur version respective dès que possible. Le fournisseur a mis à jour son avis le 13 juin pour avertir que le code d’exploitation pour la faille CVE-2023-20887 avait été publié, puis le 20 juin pour avertir qu’une exploitation active de cette faille avait lieu dans la nature. Selon Akamai et les données télémétriques du service de surveillance des attaques GreyNoise, le nombre d’attaques a augmenté depuis. L’agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA) a ajouté la vulnérabilité référencée CVE-2023-20887 à son catalogue de vulnérabilités activement exploitées Actively Exploited Vulnerabilities, ainsi que les failles d’iOS exploitées dans le cadre de l’opération Triangulation et une faille d’injection de commande dans les dispositifs de stockage en réseau de Zyxel. Une faille de contournement de l’authentification dans VMware Tools (CVE-2023-20867) a également été ajoutée au catalogue après avoir été exploitée en tant que zero-day par un acteur chinois de cyberespionnage pour exécuter des commandes à l’intérieur de machines virtuelles invitées à partir d’un hôte compromis.
Plusieurs failles corrigées dans vCenter
La semaine dernière, VMware a par ailleurs publié des correctifs pour cinq vulnérabilités identifiées dans son produit vCenter Server qui permet aux administrateurs de gérer l’infrastructure virtuelle : CVE-2023-20892, CVE-2023-20893, CVE-2023-20894, CVE-2023-20895 et CVE-2023-20896. Classées avec un niveau de gravité de 8.1 (élevé) sur l’échelle CVSS, les quatre premières failles peuvent conduire à l’exécution de code arbitraire, à la corruption de la mémoire et au contournement de l’authentification. Quant à la cinquième faille, affectée du score de gravité de 5,9, son exploitation peut entraîner un déni de service. Même si aucun rapport n’indique que ces vulnérabilités ont été exploitées dans la nature, les attaquants ont ciblé des failles dans les produits VMware. Les utilisateurs de l’éditeur sont invités à déployer les correctifs disponibles dès que possible.
Les attaquants pourraient élever leurs privilèges sur les systèmes équipés des clients Cisco vulnérables et non corrigés, et en prendre éventuellement le contrôle total.
La semaine dernière, un exploit, facile à mettre en œuvre, a été rendu public pour une vulnérabilité corrigée affectant les applications Cisco AnyConnect Secure Mobility Client et Secure Client pour Windows, largement utilisées. Les attaquants pourraient tirer parti de cet exploit pour élever leurs privilèges sur le système d’une victime et en prendre le contrôle total. Connue sous le nom d’AnyConnect Secure Mobility Client avant la version 5.0, l’application Secure Client pour Windows s’intègre à plusieurs plateformes et technologies de sécurité et de gestion des points terminaux de l’équipementier, notamment la plateforme AnyConnect VPN et Zero-Trust Network Access (ZTNA), très prisée par les entreprises. Cette popularité du logiciel en a déjà fait une cible pour les attaquants. En octobre 2022, Cisco a mis à jour ses avis concernant deux vulnérabilités d’escalade de privilèges, initialement corrigées dans le client AnyConnect en 2020, pour alerter les clients sur leur exploitation dans la nature. Au même moment, l’agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA) avait ajouté les failles CVE-2020-3433 et CVE-2020-3153 à son catalogue de vulnérabilités connues et exploitées, en demandant à toutes les agences gouvernementales de les corriger dans les plus brefs délais.
Les vulnérabilités d’escalade des privilèges locaux ne sont pas considérées comme très critiques car il faut que l’attaquant dispose déjà d’un certain accès pour exécuter du code sur le système d’exploitation. Cela ne signifie pas pour autant qu’elles ne sont pas sérieuses ou utiles, en particulier dans le cadre d’un mouvement latéral. Généralement, les employés qui utilisent le client AnyConnect sur leurs ordinateurs professionnels pour accéder au réseau de l’entreprise par VPN n’ont pas de privilèges d’administrateur sur leurs systèmes. Si les attaquants parviennent à inciter un utilisateur à exécuter un programme malveillant, ce code s’exécutera avec leurs privilèges limités. Cela peut suffire pour voler des données de base dans les applications de l’utilisateur, mais ne permet pas de mener des attaques plus sophistiquées comme le dumping d’identifiants locales stockées dans Windows, qui pourraient permettre à l’utilisateur d’accéder à d’autres systèmes. Or c’est là que les failles d’escalade des privilèges locaux peuvent devenir intéressantes.
L’exploit CVE-2023-20178
Répertoriée sous la référence CVE-2023-20178, la vulnérabilité d’escalade des privilèges corrigée par Cisco au début du mois se situe dans le mécanisme de mise à jour d’AnyConnect Secure Mobility Client et de Secure Client for Windows. Comme l’explique le chercheur Filip Dragovic, qui a trouvé et signalé la faille à Cisco, dans son exploit de preuve de concept posté sur GitHub, chaque fois qu’un utilisateur établit une connexion VPN, le logiciel client exécute un fichier appelé vpndownloader.exe. Ce processus crée un répertoire dans le dossier c:³windows³temp avec les autorisations par défaut et vérifie s’il contient des fichiers, provenant par exemple d’une mise à jour précédente. Si des fichiers sont trouvés, il les supprime, mais cette action est effectuée avec le compte NT AuthoritySYSTEM, c’est-à-dire le compte ayant le plus de privilèges sur les systèmes Windows. Les attaquants peuvent facilement exploiter cette action en utilisant des liens symboliques (raccourcis) vers d’autres fichiers qu’ils créent, ce qui entraîne un problème de suppression de fichier arbitraire, la suppression de fichier se transformant en exécution de fichier. Cette action est possible, en abusant d’une fonctionnalité peu connue du service Windows Installer.
En mars 2022, les chercheurs de la Zero Day Initiative de Trend Micro ont décrit cette technique en détail qu’ils ont attribuée à un chercheur nommé Abdelhamid Naceri. C’est ce même chercheur qui avait découvert et signalé une vulnérabilité différente dans le service Windows User Profile Service qui conduisait de la même manière à la suppression arbitraire de fichiers avec les privilèges SYSTEM. « Cet exploit est largement applicable dans les cas où une primitive supprime, déplace ou renomme un dossier vide arbitraire dans le contexte du SYSTEM ou d’un administrateur », avaient déclaré à l’époque les chercheurs de Trend Micro. Dans la mise à jour de son avis sur la vulnérabilité CVE-2023-20178, Cisco indique aux utilisateurs qu’un programme d’exploitation public est désormais disponible. L’entreprise conseille vivement aux clients de mettre à niveau AnyConnect Secure Mobility Client pour Windows vers la version 4.10MR7 (4.10.07061) ou une version ultérieure, et Secure Client pour Windows vers la version 5.0MR2 (5.0.02075) ou une version ultérieure.
Les quatre vulnérabilités trouvées par les chercheurs dans vRealize Log Insight étaient relativement peu menaçantes en soi, mais utilisées ensemble, elles peuvent conduire à une compromission importante.
La semaine dernière, VMware a publié des correctifs pour quatre vulnérabilités découvertes dans son produit vRealize Log Insight qui, si elles étaient combinées, pourraient permettre à des attaquants de prendre le contrôle de la plate-forme de collecte et d’analyse des journaux. Cette semaine, une chaîne d’exploitation de preuve de concept a été publiée par des chercheurs en sécurité, ainsi que des explications détaillées pour chaque vulnérabilité, laissant présager de prochaines attaques dans la nature. « Gagner l’accès à l’hôte Log Insight offre quelques possibilités intéressantes à un attaquant, en fonction du type d’applications qui y sont intégrées », ont déclaré dans leur analyse des failles, les chercheurs de Horizon3.ai, une entreprise spécialisée dans les tests de pénétration. « Souvent, les journaux ingérés peuvent contenir des données sensibles provenant d’autres services et peuvent permettre à une attaque de rassembler des jetons de session, des clés API et des informations personnelles identifiables (Personal Identifying Information PII). Ces clés et ces sessions peuvent permettre à un attaquant de pivoter vers d’autres systèmes et de compromettre davantage l’environnement », ont-ils ajouté.
Une attaque puissante, en combinant les vulnérabilités
Le cas est intéressant, car il met en évidence une réalité commune de la sécurité logicielle moderne, où une vulnérabilité seule ne peut pas conduire à une compromission importante, mais la combinaison de plusieurs peut débloquer une attaque puissante. Dans son avis, VMware décrit la première vulnérabilité, référencée CVE-2022-31704, comme un contrôle d’accès défectueux, sans donner de détails supplémentaires sur sa localisation. Cependant, le script de contournement manuel, publié par l’entreprise en même temps que les mises à jour du produit, donne quelques indices. Le script ajoute simplement une règle de pare-feu qui bloque l’accès aux ports TCP 16520 à 16580. D’après l’enquête d’Horizon3 et les notes de la documentation de vRealize Log Insight, ces ports sont utilisés pour la communication à l’aide du framework Apache Thrift RPC (Remote Procedure Call), le RPC étant un protocole de communication inter-processus, par lequel un processus peut demander à un autre processus d’exécuter une certaine procédure. « Cette information indique que la vulnérabilité se trouve probablement dans un serveur RPC », ont déclaré les chercheurs dans leur compte rendu. « Ensuite, en se connectant au système en cours d’exécution et on a pu constater que le port TCP 16520 était créé par une application Java », ont ajouté les chercheurs. Ces derniers ont réussi à retrouver le composant responsable du démarrage d’un serveur Thrift RPC qui expose plusieurs appels de procédure à distance. Ils ont ensuite construit un client Thrift RPC simple pour effectuer l’un de ces appels et ils ont constaté que les appels étaient passés et exécutés sans authentification, d’où la rupture du contrôle d’accès. Mais cette vulnérabilité seule, bien que donnant accès à des RPC potentiellement puissants, n’est pas suffisante pour exécuter du code malveillant.
Une seconde vulnérabilité de traversée de répertoire
La deuxième vulnérabilité, référencée CVE-2022-31706, est décrite comme une faille de traversée de répertoire, Directory Traversal ou Path Traversal. La traversée de répertoire permet à un attaquant ou à un processus malveillant de naviguer vers un chemin du système de fichiers auquel il n’est pas censé accéder. En examinant les RPC exposés par Thrift RPC, les chercheurs en ont trouvé le RPC remotePakDownloadCommand qui télécharge un fichier avec l’extension .pak (probablement un paquet) et le place dans le répertoire /tmp/. Un autre RPC appelé pakUpgradeCommand peut ensuite être utilisé pour invoquer un script Python qui décompresse ce fichier. Ces deux commandes étant utilisées pour effectuer des mises à niveau du système, les chercheurs ont réalisé que la faille de traversée de répertoire se trouvait sans doute quelque part dans le traitement des fichiers pak.
Il s’avère que les fichiers pak sont des archives au format TAR et que leur traitement avant extraction implique la validation de signatures, des contrôles d’intégrité, des contrôles de manifeste et plusieurs autres étapes. « Si l’on arrive à construire un fichier tar qui passe tous ces contrôles, on peut atteindre la ligne 493 et extractFiles analysera notre tar malveillant, ce qui nous permettra d’écrire un fichier avec le contenu de notre choix à n’importe quel endroit du système de fichiers », ont déclaré les chercheurs. « Certes, nous avons passé un certain temps à construire manuellement un fichier tar qui passerait tous ces contrôles avant de réaliser que nous pouvions simplement utiliser un fichier de mise à niveau légitime avec une petite modification pour accueillir notre charge utile ».
vRealize Log Insight forcé de télécharger un fichier pak malveillant
À ce stade, les chercheurs disposaient des informations nécessaires pour forcer le produit vRealize Log Insight à télécharger un fichier pak malveillant sans authentification, puis à placer une charge utile malveillante n’importe où sur le système. À l’exception d’un problème : l’invocation de la commande remotePakDownloadCommand nécessite un jeton de nœud pour fonctionner, une valeur unique générée par instance de Log Insight. Même si ce jeton n’est pas directement accessible à un utilisateur non authentifié, il peut être divulgué en invoquant d’autres RPC tels que getConfig et getHealthStatus. Il s’agit probablement du problème de divulgation d’informations que VMware mentionne dans son avis CVE-2022-31711. Grâce à cela, les chercheurs d’Horizon3 ont pu construire un exploit de preuve de concept qui place une nouvelle entrée dans crontab – le mécanisme de planification des tâches sur les systèmes basés sur Linux – qui, lorsqu’elle est exécutée, ouvre un shell inverse avec des privilèges d’utilisateur root pour les attaquants.
La quatrième vulnérabilité, référencée CVE-2022-31710, est, selon l’avis de VMware, une faille de désérialisation qui peut être exploitée pour faire planter le système et provoquer un déni de service. Cette vulnérabilité n’est pas nécessaire pour la chaîne d’exploitation qui aboutit à l’exécution de code à distance. Log Insight est utilisé pour collecter et analyser les journaux des réseaux locaux, il n’est donc pas habituel de trouver de tels systèmes exposés à Internet. Les recherches Shodan dans l’espace IP public n’ont révélé que 45 instances. Cependant, si un attaquant accède au réseau local, ce qui peut se faire de plusieurs façons, et que le serveur Log Insight n’est pas protégé par un pare-feu, il peut être compromis et potentiellement utilisé pour un mouvement latéral en raison des données sensibles qu’il peut contenir. Les chercheurs d’Horizon3 ont publié des indicateurs de compromission qui permettent aux entreprises de vérifier leurs déploiements pour des signes d’exploitation. VMware a publié un script de contournement qui bloque le trafic vers les numéros de port associés au serveur RPC Thrift, et la version 8.10.2 de vRealize Log Insight corrige également les failles.
L’exploitation d’une vulnérabilité permet aux attaquants d’exécuter à distance du code et des commandes arbitraires sans authentification dans des équipements de sécurité Fortinet non patchés.
En décembre, l’éditeur de solutions de sécurité réseau Fortinet a révélé qu’une vulnérabilité critique dans son système d’exploitation FortiOS était exploitée par des attaquants dans la nature. En fin de semaine dernière, après une analyse supplémentaire, l’équipementier a livré plus de détails sur l’implant de malware que ces attaquants ont déployé en exploitant la vulnérabilité. Sur la base des informations actuellement disponibles, l’attaque zero-day initiale ciblait fortement des entités liées à des instances gouvernementales. Cependant, comme la vulnérabilité est connue depuis plus d’un mois, tous les clients devraient la corriger dès que possible, car d’autres attaquants pourraient commencer à l’utiliser.
Exécution de code à distance dans FortiOS SSL-VPN
La vulnérabilité, référencée CVE-2022-42475, se situe dans la fonctionnalité SSL-VPN de FortiOS et elle est exploitable par des attaquants à distance sans authentification. Une exploitation réussie peut entraîner l’exécution de code et de commandes arbitraires. Fortinet a évalué la vulnérabilité à 9.3 (Critique) sur l’échelle du Common Vulnerability Scoring System (CVSS) et a publié des mises à jour pour les principales variantes de FortiOS, FortiOS-6K7K et FortiProxy, la solution de passerelle web sécurisée du fournisseur. FortiOS fonctionne sur les pares-feux de sécurité réseau FortiGate et d’autres appareils de l’équipementier. Les clients qui ne sont pas en mesure de déployer immédiatement les mises à jour peuvent, en guise de contournement, désactiver entièrement SSL-VPN, ce qui pourrait s’avérer difficile pour les entreprises qui s’appuient sur cette fonctionnalité pour leurs environnements de travail à distance ou hybrides. Le fournisseur a également publié une signature IPS (système de prévention des intrusions) pour détecter les tentatives d’exploitation, ainsi que des règles de détection pour l’implant connu dans son moteur antivirus. Les clients peuvent également rechercher dans leurs journaux les entrées suivantes qui pourraient révéler des tentatives d’exploitation : Logdesc=”Application crashed” et msg=”[…] application:sslvpnd,[…], Signal 11 received, Backtrace : […]”
L’implant, caché derrière une version trojanisée du moteur IPS de FortiOS
Dans l’attaque analysée par Fortinet, les attaquants ont exploité la vulnérabilité et copié une version trojanisée du moteur FortiOS IPS dans le système de fichiers. Cette modification montre que les attaquants sont très qualifiés et qu’ils sont capables de faire de la rétro-ingénierie de composants FortiOS personnalisés. La version malveillante du moteur IPS a été enregistrée sur le système de fichiers sous le nom de /data/lib/libips.bak. Il s’agit d’une copie de la version légitime /data/lib/libips.so mais avec des modifications malveillantes. En effet, la version malveillante exporte deux fonctions légitimes appelées ips_so_patch_urldb et ips_so_query_interface normalement associées à la version légitime libips.so, mais elles ont été détournées pour exécuter du code stocké dans d’autres composants malveillants. « Si libps.bak est nommé libips.so dans le répertoire /data/lib, le code malveillant sera exécuté automatiquement car les composants de FortiOS appelleront ces fonctions exportées », ont indiqué les analystes de Fortinet. « Le binaire ne tente pas de revenir au code propre du moteur IPS, de sorte que la fonctionnalité IPS est également compromise », ont-ils aussi précisé. En d’autres termes, une fois que la version malveillante est exécutée, la fonctionnalité IPS légitime ne fonctionne plus correctement. Les fonctions détournées exécutent un code malveillant qui lit et écrit ensuite dans un certain nombre de fichiers appelés libiptcp.so, libgif.so, .sslvpnconfigbk et libipudp.so.
Les analystes n’ont pas été en mesure de récupérer tous ces fichiers à partir de l’appareil compromis qu’ils ont analysé, et n’ont donc pas pu reconstituer toute la chaîne d’attaque. Néanmoins, ils ont trouvé un fichier appelé wxd.conf dont le contenu est similaire au fichier de configuration d’un proxy inverse open-source qui peut être utilisé pour exposer un système situé derrière un routeur NAT (Network Address Tanslation) à Internet. L’analyse des captures de paquets réseau de l’appareil suggère que le logiciel malveillant a connecté deux serveurs externes contrôlés par l’attaquant pour télécharger des charges utiles et des commandes supplémentaires à exécuter. L’un des serveurs était toujours en activité et disposait d’un dossier contenant des binaires conçus spécifiquement pour différentes versions du matériel FortiGate. Ainsi, les chercheurs ont pu analyser des fichiers supplémentaires qui, selon eux, ont été exécutés par les attaquants sur les systèmes pour manipuler la fonctionnalité de journalisation dans FortiOS.
Selon les chercheurs :
– Le malware patche les processus de journalisation de FortiOS afin de manipuler les journaux pour échapper à la détection. – /bin/miglogd & /bin/syslogd.
– Il comprend des offsets et des opcodes pour 27 modèles et paires de versions de FortiGate. Le malware ouvre une poignée ou handle sur les processus et y injecte des données.
– Les versions concernées vont de 6.0.5 à 7.2.1.
– Les modèles sont FG100F, FG101F, FG200D, FG200E, FG201F, FG240D, FG3H0E, FG5H0E, FG6H1E, FG800D, FGT5HD, FGT60F, FGT80F.
– Le malware peut manipuler les fichiers logs. Il recherche les fichiers elog, dénomination des journaux d’événements dans FortiOS. Après les avoir décompressés en mémoire, il recherche une chaîne de caractères spécifiée par l’attaquant, la supprime et reconstruit les journaux.
– Le malware peut également détruire les processus de journalisation.
Les chercheurs ont également trouvé sur le service d’analyse de fichiers en ligne VirusTotal de Google un échantillon d’un binaire Windows dont le code présente des similitudes avec le binaire Linux présent sur FortiOS. Cet échantillon Windows a été compilé sur une machine localisée dans le fuseau horaire UTC+8, qui comprend l’Australie, la Chine, la Russie, Singapour et d’autres pays d’Asie orientale. Les certificats auto-signés utilisés par les attaquants ont aussi été créés entre les fuseaux UTC+3 et +8. « Il est difficile d’en tirer des conclusions, car les pirates n’opèrent pas nécessairement pendant les heures de bureau, mais se calent souvent sur les heures de bureau de leurs victimes pour noyer leur activité dans le trafic réseau global », ont déclaré les chercheurs. L’avis de Fortinet contient de nombreux indicateurs de compromission, notamment des chemins de fichiers, des hachages de fichiers, des adresses IP, et même des signatures permettant de détecter les communications malveillantes de cet implant à l’intérieur des captures de paquets réseau.
Il est probable que la vulnérabilité Log4Shell continuera à être exploitée, car les entreprises manquent de visibilité sur leur chaîne d’approvisionnement logicielle.
Un an après l’application de correctifs, et malgré l’attention dont elle a bénéficié, la vulnérabilité critique Log4Shell, qui a touché des millions d’applications d’entreprise, demeure une cause fréquente de failles de sécurité, et elle devrait rester une cible privilégiée pendant un certain temps encore. Son impact durable souligne les risques majeurs posés par les failles dans les dépendances logicielles transitives et la nécessité pour les entreprises d’adopter de toute urgence des pratiques d’analyse de la composition des logiciels et de gestion sécurisée de la chaîne d’approvisionnement. Officiellement référencée sous l’appellation CVE-2021-44228, Log4Shell a été découverte en décembre 2021 dans Log4j, une bibliothèque Java open-source très répandue et utilisée pour la journalisation. Si les développeurs du projet ont rapidement créé un correctif pour cette faille divulguée à l’origine comme une faille zero day, l’adoption et le déploiement de ce correctif à grande échelle se sont avérés difficiles, car ils dépendent des codeurs qui ont utilisé ce composant dans leur logiciel pour publier leurs propres mises à jour. Le problème a été compliqué par la nature transitive de la vulnérabilité, car les projets logiciels qui incorporaient Log4j comprenaient de nombreux autres composants ou frameworks de développement tiers qui étaient eux-mêmes utilisés comme dépendances pour d’autres applications. Il n’était même pas nécessaire d’utiliser la bibliothèque Log4j elle-même pour être affecté, car la classe Java vulnérable appelée JndiManager incluse dans Log4j-core a été empruntée par 783 autres projets et se trouve désormais dans plus de 19 000 composants logiciels.
L’exploitation de Log4j « restera un défi »
« Les tentatives d’exploitation de Log4j resteront un défi pour les entreprises en 2023 et au-delà », ont déclaré les chercheurs du groupe Talos de Cisco dans leur rapport de fin d’année. « L’omniprésence de Log4j dans les environnements des entreprises complique l’application des correctifs. Parce que la bibliothèque est aussi largement utilisée, Log4j peut être profondément intégré dans de grands systèmes et il est difficile d’établir un inventaire complet de l’endroit où peuvent se trouver toutes les vulnérabilités logicielles dans un environnement particulier ». Selon les données de Tenable, spécialiste de l’analyse des vulnérabilités, au 1er octobre 2022, 72 % des entreprises possédaient encore des actifs vulnérables à Log4Shell. Si l’amélioration atteint 14 points par rapport au mois de mai 2022, ce pourcentage reste encore très élevé. Le nombre moyen d’actifs vulnérables par entreprise est passé de 10 % en décembre 2021 à 2,5 % en octobre, mais Tenable a observé qu’un actif sur trois présentait une récurrence de Log4Shell après une première réparation. « Nos données montrent que les entreprises disposant de programmes open-source matures ont largement remédié à la situation, mais, un an plus tard, d’autres sont toujours en difficulté », a expliqué Brian Fox, CTO de l’entreprise de gestion de la chaîne logistique logicielle Sonatype. « Le nombre de téléchargements de Log4j vulnérables chaque jour se compte en centaines de milliers, ce qui, à mon avis, montre qu’il ne s’agit pas d’un problème de mainteneurs de logiciels libres, mais d’un problème de consommateurs de logiciels libres. C’est la preuve que les entreprises ne savent tout simplement pas ce que contient leur chaîne d’approvisionnement logicielle », a ajouté le directeur de la technologie. Sonatype maintient et gère le Maven Central Repository, le référentiel de composants Java le plus important et le plus utilisé. L’entreprise est donc en mesure de suivre le nombre de téléchargements de n’importe quel composant, dont Log4,j et maintient une page avec des statistiques et des ressources pour Log4Shell. Depuis le 10 décembre, un téléchargement de Log4j sur trois concerne des versions vulnérables.
Des tentatives d’exploitation de Log4Shell toujours importantes
Après la divulgation publique de la faille fin 2021, la télémétrie du système de détection d’intrusion réseau open-source Snort a révélé un pic du nombre de détections de tentatives d’exploitation de Log4Shell, avec près de 70 millions de tentatives en janvier 2022. Le volume des nouvelles détections a diminué jusqu’en avril, mais il est resté relativement constant depuis lors, à environ 50 millions par mois. Ce volume montre que les attaquants recherchent toujours cette vulnérabilité dans les systèmes. Depuis la fin du mois de janvier, Arctic Wolf, une entreprise de cybersécurité spécialisée dans la détection et la réponse aux menaces, a constaté 63 313 incidents uniques de tentative d’exploitation contre 1 025 entreprises représentant environ un quart de sa clientèle. Dans près de 11 % des interventions d’Arctic Wolf auprès d’entreprises qui ne faisaient pas partie de ses clients, Log4Shell était la cause de l’intrusion. Cette proportion n’est dépassée que par la vulnérabilité ProxyShell (CVE-2021-34473) dans Microsoft Exchange. Selon les données de l’équipe de réponse aux incidents Talos de Cisco, au cours du premier semestre de l’année, l’exploitation des vulnérabilités dans les applications accessibles au public, dont Log4Shell, est arrivée ex æquo avec le phishing au premier rang des vecteurs d’infection. Au troisième trimestre, l’exploitation d’applications était le troisième vecteur d’infection le plus courant et comprenait le ciblage des serveurs VMware Horizon vulnérables à Log4Shell.
Parmi les attaquants qui exploitent Log4Shell, on trouve aussi bien des cybercriminels déployant des mineurs de crypto-monnaies et des ransomwares que des groupes de cyberespions parrainés par des États. Environ 60 % des cas de réponse aux incidents étudiés par Arctic Wolf cette année ont été attribués à trois groupes de ransomware : LockBit, Conti et BlackCat (Alphv). L’entreprise de cybersécurité estime à plus de 90 000 dollars le coût moyen d’un tel incident. Selon Cisco Talos, le groupe de ransomware Conti, aujourd’hui disparu, a commencé à exploiter Log4Shell peu après sa divulgation en décembre 2021. Cependant, l’exploitation de cette faille par des groupes de ransomware s’est poursuivie tout au long de l’année. Les gangs de minage de crypto-monnaies ont été encore plus rapides à adopter Log4Shell que les groupes de ransomware. Ils sont responsables d’une grande partie des premières activités d’analyse et d’exploitation associées à cette faille. Néanmoins, tout au long de l’année, Cisco Talos a constaté que Log4Shell était également utilisé dans des opérations de cyberespionnage par des groupes APT, notamment le groupe Lazarus de Corée du Nord, les acteurs de la menace associés au Corps des gardiens de la révolution islamique d’Iran et les groupes Deep Panda et APT41 liés à la Chine. « Log4j reste un vecteur d’infection très viable à exploiter pour les acteurs de la menace, et nous pensons qu’ils vont essayer d’abuser les systèmes vulnérables aussi longtemps que possible », ont déclaré les chercheurs de Cisco Talos. « Même si ces acteurs savent s’adapter, ils ne chercheront pas à dépenser plus de ressources pour développer de nouvelles méthodes s’ils peuvent continuer à exploiter avec succès les vulnérabilités connues ».