Pour la troisième fois Solarwinds a corrigé une faille de désérialisation Java qui touche Web Help Desk, son outil d’ITSM. Les chercheurs en sécurité s’inquiètent de la difficulté à combler cette vulnérabilité activement exploitée.
Il arrive parfois que la correction d’une vulnérabilité ne marche pas du premier coup. Mais pour Solarwinds, il s’agit de la troisième tentative pour venir à bout d’une même faille dans son outil ITSM Web Help Desk. Elle a d’abord été corrigée pour la première fois en août 2024 après des avertissements de la CISA indiquant qu’elle avait été exploitée dans la nature. « Cette vulnérabilité est un contournement du correctif de la CVE-2024-28988, qui est lui-même un contournement du patch sur la CVE-2024-28986 », a écrit Solarwinds dans son dernier avis, qui suit la vulnérabilité sous la référence CVE-2025-26399 et dont le score de gravité CVSS est de 9,8 sur 10.
Même si les trois identifiants CVE soient différents, ils font référence au même bug, à savoir un problème de désérialisation Java non sécurisé dans le composant AjaxProxy qui peut conduire à l’exécution de code à distance sans authentification. En programmation, la sérialisation désigne le processus de conversion de données en un flux d’octets, généralement pour les transmettre par câble. La désérialisation inverse ce processus et, comme la plupart des opérations d’analyse de données, elle peut être source de faiblesses. Ce type de brèches touchent le plus souvent les applications Java, mais aussi celles écrites dans d’autres langages de programmation comme ASP.NET peuvent également être affectées. Elles entraînent souvent l’exécution de commandes arbitraires, ce qui les rend très prisées des pirates.
La troisième fois sera-t-elle la bonne ?
En août 2024, quelques jours seulement après la correction de la faille CVE-2024-28986, la CISA l’a ajoutée à son catalogue des vulnérabilités connues exploitées, même si l’on ne sait pas très bien si la faille a été exploitée en tant que zero-day avant la publication du correctif. En octobre 2024, SolarWinds a publié un autre patch pour remédier à une faille contournant son correctif initial, découverte par des chercheurs du programme Zero Day Initiative (ZDI) de Trend Micro. Près d’un an plus tard, ces mêmes chercheurs ont trouvé un moyen supplémentaire de contourner la faille. « La troisième fois sera-t-elle la bonne ? », s’est interrogé Ryan Dewhurst, responsable du renseignement proactif sur les menaces chez watchTowr. « Le bug d’origine a été activement exploité dans la nature, et même si une exploitation active de ce dernier contournement du correctif n’est pas encore avérée, on peut penser qu’elle aura lieu tôt ou tard. »
Ces contournements ne sont pas nécessairement rares, en particulier lorsqu’il s’agit de failles impliquant une analyse non sécurisée des entrées utilisateur non fiables. En effet, de nombreux développeurs adoptent une approche de liste noire pour corriger ces failles et se contentent de bloquer les entrées spécifiques utilisées dans le PoC connu ou l’exploit actif. Mais cela ne résout souvent pas le problème à la racine, laissant d’autres moyens de contourner la liste noire et d’atteindre la même partie vulnérable du code. Il est difficile de dire à quelle fréquence cela se produit, car de nombreux programmeurs traitent le contournement d’un correctif comme une faille distincte et pas comme un évitement.
Quatre vulnérabilités récemment découvertes dans la plateforme de simulation de pannes peuvent conduire à l’injection de commandes OS et à la prise de contrôle du cluster, même à partir de pods sans privilèges.
Des chercheurs ont découvert des vulnérabilités critiques dans Chaos-Mesh, une plateforme populaire utilisée par les propriétaires de clusters Kubernetes pour simuler l’impact des bogues et des défaillances sur leurs déploiements. Si elles sont exploitées, les failles pourraient donner aux attaquants ayant accès à des pods sans privilèges la possibilité d’exécuter des commandes sur d’autres pods et même de prendre le contrôle de l’ensemble du cluster. Répertoriées sous les…
Il vous reste 87% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Des cybercriminels dissimulent des liens de phishing dans les URL réacheminées par les services de protection des messageries pour tromper des utilisateurs, les rediriger vers de faux sites et voler leurs identifiants.
La meilleure défense c’est parfois l’attaque. Preuve en est la découverte par des experts de Cloudflare d’une technique de détournement du link wrapping par les éditeurs de sécurité pour protéger les messageries. Ce procédé réécrit les URL des messages afin de les acheminer via un domaine intermédiaire pour les analyser. Des pirates ont eu l’idée d’insérer des liens de phishing dans ces URL réacheminés. Une technique à première vue contre-intuitive, mais les cybercriminels profitent du délai de mise en œuvre de ces services avant que les services d’analyse ne commencent à les détecter et à bloquer leurs pages de phishing.
Des campagnes via Proofpoint et Intermedia
Ces deux derniers mois, plusieurs campagnes de phishing exploitant des comptes de messagerie compromis protégés par les services de Proofpoint et Intermedia.net ont été identifiées par les équipes de Cloudflare. Les URL contenues dans les e-mails envoyés à partir de ces comptes ont été automatiquement réécrites par les services de sécurité pour pointer vers des domaines comme http://urldefense.proofpoint.com et http://url.emailprotection.link pour Intermedia. « Des fournisseurs comme Proofpoint ont spécialement développé le link wrapping pour protéger les utilisateurs en acheminant toutes les URL cliquées via un service d’analyse afin de bloquer les destinations malveillantes connues au moment du clic », ont écrit les chercheurs dans leur rapport sur les attaques.
« Si cette technique est efficace contre les menaces connues, les attaques peuvent toujours aboutir si le lien encapsulé n’a pas été marqué par l’analyse au moment du clic », ajoutent-ils. Les destinataires de ces e-mails frauduleux cliquent plus facilement sur les liens encapsulés, pensant qu’ils ont déjà été vérifiés par les solutions de sécurité. Parallèlement, les filtres anti-spam basés sur la réputation peuvent ne pas bloquer ces liens, car ils semblent pointer vers des domaines de confiance.
De multiples niveaux de dissimulation
Afin de maximiser leurs chances de réussite, les auteurs de ces campagnes utilisent des techniques supplémentaires pour dissimuler leurs charges utiles finales. Dans une campagne, l’URL de phishing a été acheminée via plusieurs domaines de redirection, puis encapsulée par le service de réécriture de liens de Proofpoint, avant d’être finalement transmise via un raccourcisseur d’URL, ajoutant ainsi plusieurs niveaux de dissimulation. Les courriels de phishing utilisent différentes méthodes pour tromper les destinataires : fausses notifications de messages vocaux avec un bouton pour accéder au message, alertes concernant des messages prétendument reçus via Microsoft Teams, notifications sur des documents sécurisés envoyés via Zix Secure Message. Mais dans tous les cas, la page de destination finale, atteinte après une série de redirections, était une fausse page de connexion Microsoft Office 365 dont le but est de récolter les identifiants des utilisateurs. « L’utilisation abusive de services de link wrapping fiables par cette campagne augmente considérablement les chances de réussite d’une attaque », ont déclaré les experts. « Les attaquants exploitent la confiance inhérente que les utilisateurs accordent à ces outils de sécurité, ce qui peut entraîner des taux de clics plus élevés », observent-ils.
Si cette technique de piratage est une évolution intéressante, l’utilisation abusive de services officiels pour dissimuler des charges utiles malveillantes n’est ni nouvelle ni susceptible de disparaître. Que ce soit des humains ou des logiciels qui inspectent les liens, la détection ne doit jamais reposer uniquement sur la réputation du domaine. Les entreprises doivent former leurs employés à repérer les pages de phishing s’ils tombent dessus, et les outils automatisés doivent utiliser des algorithmes de détection de contenu plus sophistiqués pour identifier ces pages.
Des chercheurs ont trouvé des paquets malveillants dans le registre npm qui, une fois installés, injectent du code frauduleux dans des paquets officiels.
L’écosystème npm fait souvent l’objet d’attaques par des cybercriminels et les chercheurs en cybersécurité travaillent dessus pour dénicher des failles. C’est le cas des experts de la société ReversingLabs qui ont trouvé une technique de persistance dans les paquets malveillants hébergés sur le dépôt npm. Les cybercriminels peuvent ainsi créer une porte dérobée dans les paquets officiels installés dans les environnements locaux des victimes. Cette tactique…
Il vous reste 93% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Le chargeur de logiciels malveillants Latrodectus comble le vide laissé par le démantèlement des grands botnets de distribution de malwares comme IcedID. Voici comment il est utilisé et comment il fonctionne.
Cette année, certains des plus grands botnets utilisés comme plateformes de distribution de charges utiles par les gangs de ransomwares ont été démantelés. Mais, dans l’écosystème du cyber crime, la disparition de grands acteurs est rapidement comblée par d’autres. C’est le cas de Latrodectus, un chargeur de logiciels malveillants, dont la présence n’a cessé de croître dans les campagnes d’attaques de ces derniers mois. « Actuellement, de plus en plus d’acteurs de la menace adoptent…
Il vous reste 93% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Outil couramment utilisé en red team, EDRSilencer a été détourné de son usage par des pirates pour court-circuiter la plateforme de filtrage de Windows en empêchant les solutions de détection et de réponse à incidents de signaler les malwares.
Développé pour les tests de pénétration et les exercices des équipes offensives en cybersécurité (red team), EDRSilencer a été trafiqué par des pirates afin d’améliorer leurs attaques. Cet outil exploite la plateforme de filtrage Windows Filtering Platform (WFP) pour bloquer la communication réseau des agents logiciels EDR, les empêchant ainsi d’envoyer des données télémétriques ou des alertes aux consoles de gestion surveillées par les équipes de sécurité.
« Cet outil apporte la preuve qu’il est possible de détourner une technique de ses adversaires pour échapper à la détection : le blocage du trafic EDR peut masquer la présence de logiciels sur un système, ce qui les rend plus difficiles à identifier et à supprimer », ont expliqué les chercheurs de l’entreprise de sécurité Trend Micro dans un rapport. L’équipe de l’éditeur et ses chasseurs de menaces se sont intéressés de plus près à EDRSilencer et à son fonctionnement après avoir constaté que des attaquants essayaient de l’intégrer dans leurs opérations. Il s’avère que cet outil open-source s’inspire d’un outil propriétaire appelé FireBlock, créé par l’entreprise britannique MDSec, spécialisée dans la simulation d’attaques et les tests de pénétration.
De nombreux EDR réduits au silence
WFP est un ensemble d’API et de services Windows que les développeurs peuvent utiliser pour interagir avec le traitement des paquets réseau au sein de la pile réseau de Windows. Généralement, cette puissante capacité est exploitée par les pare-feux et d’autres applications de sécurité pour surveiller, bloquer ou modifier les paquets réseau en fonction des adresses IP, des ports, des processus d’origine, etc. EDRSilencer crée des filtres WFP qui ciblent les processus associés aux outils EDR les plus courants.
Les agents pris en charge par défaut comprennent Defender for Endpoint et Antivirus, Elastic EDR, Trellix EDR, Qualys EDR, SentinelOne, Cylance, Cybereason, Carbon Black EDR et Cloud, Tanium, Palo Alto Networks Traps/Cortex XDR, FortiEDR, Cisco Secure Endpoint (anciennement Cisco AMP), ESET Inspect, Harfanglab EDR et TrendMicro Apex One. Si l’agent EDR installé sur un système ne figure pas dans cette liste et n’est pas automatiquement reconnu, l’utilisateur peut indiquer le chemin d’accès complet au processus dont il souhaite bloquer les communications réseau. En théorie, l’outil pourrait donc bloquer le trafic réseau de n’importe quel programme et pas seulement des agents EDR.
L’identifiant unique du PAM capturé
Les filtres WPF déployés par l’outil sont persistants, ce qui signifie qu’ils survivront aux redémarrages du système et que l’outil lui-même peut être déployé directement dans la mémoire par d’autres implants de test de pénétration dotés de modules d’exécution PE (Portable Execution). Cela veut aussi dire qu’il prend en charge l’exécution sans fichier. Le développeur d’EDRSilencer a même mis en œuvre une technique pour obtenir l’identifiant unique de l’application de gestion des accès à privilèges (privileged access management ou PAM) du processus ciblé tout en évitant de déclencher les mécanismes d’autodéfense de certains processus EDR qui pourraient détecter des tentatives d’application d’un filtre WPF contre eux-mêmes. « Certains contrôles EDR (le minifiltre, par exemple) refusent l’accès lorsqu’un processus tente d’obtenir un handle de fichier de ses processus EDR (par exemple, via CreateFileW) », a indiqué le développeur sur GitHub. « Cependant, l’API FwpmGetAppIdFromFileName0, utilisée pour obtenir l’identifiant d’application FWP du processus EDR ciblé, appelle CreateFileW en interne. Pour éviter cela, un FwpmGetAppIdFromFileName0 personnalisé a été mis en œuvre pour construire l’identifiant de l’application sans invoquer CreateFileW, évitant ainsi des échecs inattendus lors de l’ajout d’un filtre WFP à un processus EDR. »
Lorsque les chercheurs de Trend Micro ont testé l’outil contre l’agent maison Vision One Endpoint Agent qui n’est pas pris en charge par défaut, celui-ci n’a pas réussi à identifier et à bloquer complètement les communications réseau pour tous les composants. Cependant, ils ont utilisé avec succès la commande de blocage de l’outil avec un chemin d’accès complet aux processus. « Quand nous avons exécuté un binaire de ransomware, aucun journal n’a été affiché sur le portail, l’appareil semblait déconnecté ou inactif, ce qui indique que l’outil était efficace », ont déclaré les chercheurs.
De plus en plus souvent, les utilisateurs de services cloud d’IA tels qu’Amazon Bedrock sont la cible d’attaquants qui utilisent des identifiants volés pour accéder à des ressources LLM. Avec à la clé d’importants dommages financiers pour leurs victimes.
Selon une étude de Sysdig, le marché noir de l’accès aux grands modèles de langage (LLM) se développe. Dans ce que l’on appelle désormais le LLMjacking, les attaquants abusent d’identifiants volés pour interroger des services de requête d’IA tels qu’Amazon Bedrock. D’après les requêtes API observées par Sysdig, il semble que les acteurs de la menace interrogent non seulement les LLM que les propriétaires de comptes ont déjà déployés sur ces plateformes, mais qu’ils tentent également d’en activer de nouveaux, ce qui pourrait rapidement faire grimper les coûts pour les victimes. « Le LLMjacking lui-même est en hausse : au cours du mois de juillet, les requêtes LLM ont été multipliées par 10 et au cours du premier semestre 2024, le nombre d’adresses IP uniques engagées dans ces attaques a été multiplié par 2 », ont déclaré les chercheurs de l’entreprise de sécurité dans un rapport. « Avec la progression continue du développement de LLM, le premier coût potentiel pour les victimes est monétaire : par exemple, l’utilisation de modèles de pointe comme Claude 3 Opus peut quasiment tripler le coût à hauteur de 100 000 $ par jour. »
C’est pour profiter des jeux de rôle, générer des scripts, analyser des images et utiliser des invites textuelles sans payer et sans les limites normales imposées par les services gratuits que les attaquants souhaitent accéder aux LLM. Sysdig a trouvé des preuves que, dans certains cas au moins, les utilisateurs qui se livrent au LLMjacking sont basés en Russie, où les sanctions occidentales ont imposé des limites sévères à l’accès aux chatbots LLM et aux services fournis par des entreprises occidentales. « La principale langue utilisée dans les invites est l’anglais (80 %), la deuxième, le coréen (10 %), le reste étant le russe, le roumain, l’allemand, l’espagnol et le japonais », ont indiqué les chercheurs.
Des API Bedrock abusées
Le service Amazon Bedrock d’AWS permet aux entreprises de déployer et d’utiliser facilement les LLM de plusieurs fournisseurs d’IA, de les enrichir de leurs propres ensembles de données et de créer des agents et des applications autour d’eux. Le service prend en charge une longue liste d’actions API pour gérer les modèles et d’interagir avec eux par programmation. Les actions API les plus courantes appelées par les attaquants via des informations d’identification compromises au début de cette année comprenaient InvokeModel, InvokeModelStream, Converse et ConverseStream. Mais récemment, les chercheurs ont aussi vu que des attaquants abusaient de PutFoundationModelEntitlement et de PutUseCaseForModelAccess, utilisées pour activer des modèles, ainsi que ListFoundationModels et GetFoundationModelAvailability, afin de détecter à l’avance les modèles auxquels un compte a accès. Cela signifie que les entreprises qui ont déployé Bedrock sans activer certains modèles ne sont pas à l’abri.
L’écart de coût entre les différents modèles peut être substantiel. Par exemple, pour l’utilisation d’un modèle Claude 2.x, les chercheurs ont estimé le coût potentiel à plus de 46 000 $ par jour, mais pour des modèles tels que Claude 3 Opus, le coût pourrait être deux à trois fois plus élevé. Les chercheurs ont vu des attaquants utiliser Claude 3 pour générer et améliorer le code d’un script destiné à interroger le modèle en premier lieu. Le script a pour objectif d’interagir en permanence avec le modèle, en générant des réponses, en surveillant un contenu spécifique et en enregistrant les résultats dans des fichiers texte. « La désactivation des modèles dans Bedrock et l’exigence d’activation ne doivent pas être considérées comme une mesure de sécurité », ont mis en garde les chercheurs. « Les attaquants peuvent les activer à la place de l’utilisateur et le feront pour atteindre leurs objectifs ». C’est ce qui se passe par exemple avec l’API Converse, annoncée en mai, qui simplifie l’interaction des utilisateurs avec les modèles Amazon Bedrock. Selon Sysdig, les attaquants ont commencé à abuser de l’API dans les 30 jours qui ont suivi sa publication. Ils précisent par ailleurs que les actions Converse API n’apparaissent pas automatiquement dans les journaux CloudTrail, contrairement aux actions InvokeModel.
La sécurisation des identifiants et des jetons LLM en guise d’atténuation
Même si la journalisation est activée, les attaquants malins essaieront de la désactiver en appelant DeleteModelInvocationLoggingConfiguration, qui désactive la journalisation des invocations pour CloudWatch et S3. Dans d’autres cas, ils vérifieront l’état de la journalisation et éviteront d’utiliser des informations d’identification volées afin de dissimuler leur activité. Souvent, les attaquants n’appellent pas directement les modèles Bedrock d’Amazon, mais utilisent des services et des outils tiers. C’est le cas par exemple de SillyTavern, une application frontale pour interagir avec les LLM qui demande aux utilisateurs de fournir leurs propres identifiants à un service LLM de leur choix ou à un service proxy. « Compte tenu du coût important, tout un marché et un écosystème se sont développés autour de l’accès aux LLM », avertissent les chercheurs. « Les informations d’identification sont obtenues de différentes manières : paiement, essais gratuits ou vol. Comme cet accès est une denrée précieuse, des serveurs proxy inversés sont utilisés pour garder les informations d’identification en lieu sûr et sous contrôle. »
Les entreprises doivent prendre des mesures pour s’assurer que leurs identifiants et jetons AWS ne sont pas divulgués dans des référentiels de code, des fichiers de configuration et ailleurs. Elles doivent également appliquer le principe du moindre privilège en limitant les jetons à la tâche pour laquelle ils ont été créés. « Les entreprises doivent évaluer en permanence leur cloud par rapport aux contrôles de posture des meilleures pratiques, telles que la norme AWS Foundational Security Best Practices », ont recommandé les chercheurs de Sysdig. « Elles doivent surveiller leur cloud pour détecter les informations d’identification potentiellement compromises, les activités inhabituelles, l’usage inattendu de LLM et les indicateurs de menaces actives ciblant l’IA. »
Une campagne malveillante utilise actuellement des techniques de phishing basées sur le trojan d’accès distant SugarGh0st. D’après Proofpoint elle sert à obtenir des informations non publiques sur la GenAI détenues par des experts américains du domaine.
Une campagne de cyberespionnage cible des experts en intelligence artificielle travaillant dans l’industrie privée, le gouvernement et les universités, selon une alerte de chercheurs de l’entreprise de sécurité Proofpoint. Les attaquants, probablement d’origine chinoise, utilisent un cheval de Troie d’accès à distance (Remote Access Tojan, RAT) appelé SugarGh0st. « La date de la récente campagne coïncide avec un rapport de Reuters daté du 8 mai 2024, indiquant que le gouvernement américain s’employait toujours à limiter l’accès de la Chine à l’IA générative », ont constaté les chercheurs. « L’impossibilité pour les entités chinoises d’accéder aux technologies nécessaires au développement de l’IA incite peut-être des cyberacteurs prochinois à cibler les personnes qui ont accès à ces informations pour aider le pays dans ses objectifs. »
Il convient toutefois de noter que Proofpoint n’a pas établi avec certitude de lien avec un acteur connu de la menace, et encore moins avec un acteur parrainé par un État, et attribue pour l’instant l’activité à un alias temporaire UNK_SweetSpecter. SugarGh0st est une version personnalisée d’un cheval de Troie Gh0stRAT, toujours utilisé dans des attaques par de nombreux groupes chinois. SugarGh0st a été documenté pour la première fois par des chercheurs de Cisco Talos en novembre 2023, alors qu’il était utilisé contre des cibles gouvernementales en Ouzbékistan et en Corée du Sud. À l’époque, l’équipe de Talos avait attribué ces attaques, avec un degré de confiance faible, à un acteur de la menace parlant chinois, en raison des artefacts en langue chinoise présents dans le code du cheval de Troie. Selon Proofpoint, ces artefacts sont toujours présents dans les échantillons utilisés dans cette nouvelle campagne contre les experts en IA et la chaîne d’infection est similaire à celle utilisée dans l’attaque de novembre.
L’hameçonnage comme point d’accès initial
Les victimes sont ciblées via un courrier électronique ayant pour objet l’IA, dans lequel les attaquants se présentent comme des utilisateurs d’un outil que les victimes connaissent bien et demandent de l’aide pour résoudre un problème. Les courriels contenaient une pièce jointe ZIP malveillante contenant un fichier .LNK (raccourci Windows). Les fichiers LNK servent souvent à distribuer des logiciels malveillants, car ils sont capables d’exécuter des commandes shell. Dans le cas présent, le fichier LNK contient des paramètres de ligne de commande permettant d’exécuter un code JavaScript qui agit comme un dropper de logiciel malveillant.
Le dropper est un programme ou un script utilisé pour « déposer » des charges utiles supplémentaires sur un système, soit en décryptant leur code stocké dans un fichier existant, soit en téléchargeant les charges utiles à partir d’un emplacement distant. « Le dropper JavaScript contenait un document leurre, un outil ActiveX enregistré puis utilisé abusivement pour le sideloading, et un binaire chiffré, tous encodés en base64 », ont expliqué les chercheurs de Proofpoint. « Pendant que le document leurre était affiché au destinataire, le dropper JavaScript installait la bibliothèque, qui était utilisée pour exécuter les API Windows directement à partir du JavaScript ». Le dropper JavaScript s’appuie sur la bibliothèque ActiveX pour exécuter un shellcode sur le système afin de créer une entrée de démarrage dans le registre appelée CTFM0N.exe et de charger par réflexion le binaire SugarGh0st en mémoire.
Un RAT pour des attaques très ciblées
Le RAT SugarGh0st se connecte à un serveur de commande et de contrôle distant (C2) différent de celui utilisé en novembre. Il collecte des informations sur le système infecté et lance un shell inversé qui permet aux attaquants d’accéder au système et d’exécuter des commandes. Toutes les campagnes d’attaques utilisant SugarGh0st et suivies par Proofpoint depuis novembre semblent très ciblées. Parmi les cibles, on trouve une entreprise de télécommunications américaine, un média international, une organisation gouvernementale d’Asie du Sud et désormais une dizaine de personnes ayant des liens avec une entité d’IA de premier plan basée aux États-Unis.
« Même si Proofpoint n’est pas en mesure d’attribuer avec certitude ces campagnes à un état en particulier, le thème du leurre faisant spécifiquement référence à un outil d’intelligence artificielle, le ciblage d’experts en intelligence artificielle, la demande de mise en relation avec du « personnel technique », l’intérêt pour un logiciel spécifique et la nature hautement ciblée de cette campagne sont remarquables », ont déclaré les chercheurs. « Il est probable que l’objectif de l’acteur était d’obtenir des informations non publiques sur l’IA générative ». Le rapport de Proofpoint comprend des indicateurs de compromission sous la forme de hachages de fichiers, d’URL et d’adresses IP utilisés dans la campagne, ainsi que des signatures de détection.
La publication d’un prototype d’exploit sur une faille critique dans FortiClient Server inquiète les experts en cybersécurité. Ils craignent un ciblage plus large de la part de cyberattaquants.
Des chercheurs en sécurité ont publié des détails techniques et un PoC pour une vulnérabilité critique corrigée la semaine dernière dans la solution de gestion de la sécurité des endpoints FortiClient Enterprise Management Server (FortiClient EMS) de Fortinet. Signalée à Fortinet comme faille zero-day par le National Cyber Security Centre (NCSC) du Royaume-Uni, la CVE-2023-48788, a été activement exploitée dans la nature au moment de l’application du correctif, mais vraisemblablement dans le cadre d’attaques très ciblées.
La disponibilité du récent PoC, même s’il n’est pas armé, pourrait permettre une exploitation plus large et une adoption plus facile par un plus grand nombre d’attaquants. La faille résulte d’une mauvaise vérification des éléments d’une commande SQL, qui pourrait être exploitée dans un scénario d’injection SQL pour exécuter du code ou des commandes non autorisées sur le FortiClient EMS. Il est conseillé aux clients de passer à la version 7.0.11 ou supérieure pour la série 7.0.x et à la version 7.2.3 ou supérieure pour la série 7.2.x.
Une vulnérabilité triviale de Fortinet à exploiter
FortiClient EMS est le composant serveur central utilisé pour gérer les terminaux sous FortiClient. Selon les chercheurs de Horizon3.ai (spécialisée dans le pen test) qui ont reconstitué la vulnérabilité, celle-ci se trouve dans un composant appelé FCTDas.exe, ou Data Access Server, qui communique avec la base de données Microsoft SQL Server pour stocker les informations reçues des points d’extrémité. Les terminaux sur lesquels FortiClient est installé communiquent avec un composant de l’EMS appelé FmcDaemon.exe sur le port 8013 à l’aide d’un protocole textuel personnalisé, crypté dans un second temps avec TLS à des fins de protection. FmcDaemon.exe transmet ensuite des informations à FCTDas.exe sous la forme de requêtes SQL exécutées dans la base de données.
Les chercheurs ont réussi à construire un script Python pour interagir avec FmcDaemon.exe et envoyer un simple message pour mettre à jour le FCTUID suivi d’une charge utile d’injection SQL pour déclencher une mise en veille de 10 secondes. Après quoi, ils ont observé que la charge utile était transmise à FCTDas.exe, confirmant ainsi la vulnérabilité. « Pour transformer cette vulnérabilité d’injection SQL en exécution de code à distance, nous avons utilisé la fonctionnalité xp_cmdshell intégrée de Microsoft SQL Server », ont expliqué les chercheurs dans leur rapport technique. « À l’origine, la base de données n’était pas configurée pour exécuter la commande xp_cmdshell. Cependant, elle a été activée de manière triviale à l’aide de quelques autres instructions SQL ». Les chercheurs ont intentionnellement laissé la partie exécution du code xp_cmdshell en dehors de l’exploit PoC, de sorte qu’il ne peut pas servir directement sans modification. Cependant, la technique xp_cmdshell est bien connue et a déjà été utilisée pour attaquer des bases de données SQL Server, ce qui signifie qu’il n’est pas difficile d’implémenter cette partie.
Des failles qui attirent les attaquants
En février, Fortinet a corrigé une autre vulnérabilité critique d’exécution de code à distance dans le service VPN SSL du système d’exploitation FortiOS utilisé sur ses appliances. Cette vulnérabilité, référencée CVE-2024-21762, était également accompagnée d’un avertissement indiquant qu’elle pouvait être exploitée dans la nature. L’entreprise a signalé par ailleurs que des groupes de cyberespions chinois avaient déjà exploité par le passé des vulnérabilités N-Day (dans la nature depuis plusieurs jours) FortiOS pour cibler des fournisseurs d’infrastructures critiques.
Cette semaine, la Shadowserver Foundation, une institution qui surveille le trafic Internet malveillant, a signalé qu’elle observait des tentatives d’exploitation à grande échelle de la vulnérabilité CVE-2024-21762 après la publication d’un programme d’exploitation et que plus de 133 000 appareils Fortinet exposés à Internet étaient toujours vulnérables un mois après l’application du correctif.