La CISA alerte sur l’exploitation par des cybercriminels d’une vulnérabilité critique dans l’outil de développement IA, Langflow. La faille peut entraîner l’exécution d’un code Python malveillant sur des serveurs API.
Les outils pour le développement de l’IA ne sont pas exemptes de failles de sécurité. La CISA (Cybersecurity and Infrastructure Security Agency) vient de lancer un avertissement sur une faille critique dans Langflow. Elle a été corrigée le mois dernier, mais cela n’empêche pas la vulnérabilité d’être ciblée activement par les cybercriminels pour toucher des logiciels non mis à jour. Pour bien insister sur la gravité de la situation, l’agence américaine a classé cette faille à son catalogue des vulnérabilités exploitées connues (KEV), indiquant ainsi aux agences gouvernementales et aux organisations privées qu’elle doit être corrigée immédiatement.
La brèche peut être exploitée sans authentification pour exécuter à distance un code arbitraire sur des serveurs. Écrit en Python, l’outil open source Langflow est utilisé pour construire et déployer des agents d’IA en passant par une interface visuelle et un serveur API. Alors que de nombreuses entreprises cherchent à exploiter de grands modèles de langage (LLM) pour automatiser les flux de travail internes, Langflow a beaucoup gagné en popularité, affichant près de 60 000 étoiles sur GitHub. De par sa nature, Langflow propose aux utilisateurs authentifiés d’exécuter du code. Au moment de la construction d’agents à l’aide des composants visuels de Langflow, les utilisateurs modifient librement le code Python sous-jacent. Mais la vulnérabilité CVE-2025-3248 découverte par les chercheurs de Horizon3.ai donne la même liberté à des utilisateurs non authentifiés. Ce problème est aggravé par le fait qu’il existe plus de 500 instances Langflow exposées à Internet et beaucoup d’autres accessibles via des réseaux internes.
Un défaut d’authentification sur le serveur API
La faille est assez simple. Elle résulte de l’absence de contrôles d’authentification à un point de terminaison de l’API appelé /api/v1/validate/code, point qui transmet du code à la fonction exec de Python. Cependant, la vulnérabilité n’exécute pas la fonction exec directement sur les fonctions, mais sur les définitions de fonctions, qui rendent les fonctions disponibles pour l’exécution, mais n’exécutent pas leur code. C’est la raison pour laquelle les chercheurs d’Horizon3.ai ont dû trouver une autre méthode d’exploitation en tirant parti de fonctions de Python appelées « decorators », qui renvoient des fonctions qui enveloppent d’autres fonctions.
Le PoC publié par Horizon3.ai le 9 avril exploite ces « decorators » pour réaliser une exécution de code à distance, mais les chercheurs signalent qu’un chercheur tiers a obtenu le même résultat en abusant d’une autre caractéristique des fonctions Python appelée « default arguments ». Depuis, un exploit pour cette vulnérabilité a également été ajouté au framework de test de pénétration Metasploit, il n’est donc pas surprenant que les attaquants aient déjà commencé à exploiter cette faille dans des attaques.
Remédiation
Il est conseillé aux utilisateurs de Langflow de mettre à jour immédiatement leurs déploiements vers la version 1.3.0 publiée le 1er avril, qui inclut le correctif, ou vers la dernière version, 14.0, qui contient des correctifs supplémentaires. Les chercheurs d’Horizon3.ai soulignent que tout utilisateur de Langflow peut déjà élever ses privilèges au rang de super utilisateur, car il peut exécuter du code sur le serveur de par sa conception. En tant que tel, tout identifiant d’utilisateur Langlow volé ou faible peut représenter un risque important.
« D’une manière générale, nous recommandons de faire preuve de prudence lorsque l’on expose à Internet des outils d’intelligence artificielle récents », ont déclaré les chercheurs. « Si ces outils doivent être exposés à l’extérieur, il vaut mieux prévoir de les placer dans un Cloud Privé Virtuel (Virtual Private Cloud, VPC) isolé et/ou derrière un SSO. Il suffit d’une erreur ou d’un déploiement fantôme de ces outils sur une instance de cloud pour qu’une brèche soit ouverte. »
Selon Sophos, deux groupes de cybercriminels mènent des campagnes de vishing auprès des utilisateurs de Teams en se faisant passer pour le support de l’entreprise. Cette technique les bombarde de messages et d’appels vidéo ou vocaux et vise à obtenir un accès aux postes de travail pour voler des données ou installer des malwares.
Le phishing se décline en plusieurs variations via le QR Code (quishing), le SMS (smishing),… Il faut compter aussi sur le vishing qui combine des spams et des appels vocaux ou vidéo. Sophos a observé deux groupes d’attaquants, probablement affiliés à des groupes de ransomware, qui ont mené des campagnes actives sur les utilisateurs de Teams l’offre collaborative de Microsoft. Ils se font passer pour des membres du support de l’entreprise. En bombardant les utilisateurs de messages, les pirates essayent de créer…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Avec la GenAI, les cybercriminels ont amélioré leurs attaques et leurs campagnes de phishing ne sont plus centrées sur les courriels, comme l’enseignent les formations de sensibilisation à la sécurité.
Pendant des années, les entreprises ont investi dans des programmes de sensibilisation à la sécurité pour apprendre aux employés à repérer et à signaler les tentatives de phishing. Or, selon un rapport du fournisseur de solutions de sécurité Netskope, malgré ces efforts, les utilisateurs ont été trois fois plus exposés au risque de tomber sur des pages de phishing en 2024 que l’année précédente. Sur la base des données télémétriques collectées à partir de sa passerelle web sécurisée et de sa plateforme SASE basée sur le cloud, Netskope a constaté que 8,4 utilisateurs sur 1 000 ont cliqué sur un lien d’hameçonnage chaque mois au cours de l’année écoulée, contre 2,9 en 2023.
« Les principaux facteurs pouvant expliquer cette augmentation sont d’une part la fatigue, les utilisateurs étant bombardés en permanence de tentatives de phishing, et d’autre part la créativité et l’adaptabilité des attaquants dont les leurres sont plus difficiles à détecter », a déclaré l’entreprise dans son rapport annuel sur le cloud et les menaces. L’essor des grands modèles de langage (LLM) a certainement joué un rôle dans cette montée en puissance, car les attaquants peuvent désormais facilement automatiser la création de leurres de hameçonnage plus diversifiés, grammaticalement corrects et ciblés pour chaque entreprise.
Un hameçonnage basé les résultats des moteurs de recherche
Dans les entreprises, la formation à la détection du phishing se concentre majoritairement sur la détection des courriels de phishing, mais c’est loin d’être la seule méthode utilisée par les attaquants pour inciter les utilisateurs à cliquer sur des liens qui redirigent vers de faux sites web conçus pour voler les identifiants. D’après les données de Netskope, la majorité des clics de phishing proviennent de divers endroits du web, les moteurs de recherche étant l’un des plus représentés. Les pirates ont réussi à diffuser des publicités malveillantes ou à utiliser des techniques d’empoisonnement du référencement pour injecter des liens malveillants dans les premiers résultats des moteurs de recherche pour des termes spécifiques.
Viennent ensuite les pages des sites d’achat, de technologie, d’affaires et de divertissement sur lesquelles les pirates introduisent des liens malveillants en envoyant des spams dans les sections de commentaires, en achetant des publicités malveillantes qui sont ensuite affichées sur ces sites par l’intermédiaire de réseaux publicitaires, une technique connue sous le nom de malvertising, ou en compromettant les sites eux-mêmes et en injectant directement des fenêtres pop-up d’hameçonnage dans les pages. « La diversité des sources de phishing témoigne de la créativité des attaquants dans l’ingénierie sociale », ont écrit les chercheurs de Netskope. « Ils savent que leurs victimes, à qui l’on répète sans cesse de ne pas cliquer sur les liens dans les mails qu’ils reçoivent, peuvent se méfier des courriels entrants, mais qu’elles cliqueront beaucoup plus librement sur les liens qui apparaissent dans les résultats des moteurs de recherche. »
Le recours à l’IA change la donne
Les attaques de phishing cherchent en premier lieu à voler les identifiants des applications cloud, Microsoft 365 étant le plus visé avec 42 %, suivi d’Adobe Document Cloud (18 %) et de DocuSign (15 %). Un grand nombre de sites de phishing se présentent comme des pages de connexion à ces services, mais proposent également des options de connexion à d’autres fournisseurs d’identité, notamment Office 365, Outlook, AOL ou Yahoo. « Il ne fait aucun doute que les LLM ont joué un rôle dans l’élaboration par les attaquants de leurres de phishing plus convaincants », a constaté Ray Canzanese, directeur de Netskope Threat Labs. « Les LLM peuvent fournir une meilleure localisation et une plus grande variété pour tenter d’échapper aux filtres anti-spam et augmenter la probabilité de tromper la victime », a-t-il ajouté.
Les cybercriminels ont même créé des chatbots spécialisés assistés par des LLM, comme WormGPT ou FraudGPT, mis en avant et vendus sur des forums clandestins, qui prétendent, entre autres choses, avoir la capacité d’écrire de meilleurs leurres d’hameçonnage. « De manière plus générale, Netskope constate que des outils d’IA générative sont utilisés dans le cadre de campagnes de phishing ciblées, généralement en imitant une personne très en vue de l’entreprise visée », a indiqué M. Canzanese. « L’attaquant envoie des messages générés à l’aide de LLM ou utilise même de faux enregistrements audios et de fausses vidéos. » Selon une enquête de Deloitte, 15 % des cadres ont récemment déclaré que les données financières de leur entreprise avaient été ciblées par des cybercriminels via des « deepfake ».
Pendant plusieurs années, le malware de cryptominage perfctl a infecté des serveurs Linux sans presque se faire remarquer. Selon des chercheurs, il pourrait servir à d’autres attaques via du proxyjacking.
Des experts de la société Aqua Security ont découvert une campagne de malwares baptisés « perfctl » actives au cours des 3 ou 4 dernières années. Elle a ciblé des millions de serveurs Linux en tentant d’exploiter environ 20 000 configurations erronées exposant des informations d’identification ou des interfaces d’administration non sécurisées. Doté d’une porte dérobée, perfectl offre aux attaquants une grande latitude d’actions. Il semble que le malware…
Il vous reste 95% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Siemens et d’autres constructeurs ont corrigé plusieurs failles dans leurs systèmes de contrôle industriel. Au total, 15 bulletins de sécurité ont été publiés avec des vulnérabilités entraînant de l’exécution de code à distance.
La CISA (Cybersecurity and Infrastructure Security Agency) a publié 15 avis concernant des vulnérabilités graves dans des produits de contrôle industriel (ICS) de Siemens, Mitsubishi Electric, Delta Electronics et Softing Industrial Automation. Certaines de ces failles, qualifiées de gravité élevée ou critique, peuvent entraîner l’exécution d’un code à distance.
Onze des 15 avis couvrent des vulnérabilités dans les produits Siemens, mais ce nombre n’est pas surprenant compte tenu de la quantité de lignes de produits dont Siemens dispose dans son portefeuille et du fait que, en tant que fournisseur ICS, l’entreprise a un programme de cybersécurité très actif. Quatre des avis de Siemens contiennent des vulnérabilités de gravité critique avec des scores CVSS compris entre 9 et 10, tandis que trois autres contiennent des failles de gravité élevée avec des scores compris entre 7 et 9. Les autres avis portent sur des problèmes de gravité moyenne ou faible.
Des équipements et des informations sensibles à risque
La première vulnérabilité d’exécution de code à distance concerne un problème de contrôle d’accès incorrect (CVE-2022-32257) dans les endpoints des services web qui font partie du SINEMA Remote Connect Server, une plateforme de Siemens qui permet de gérer des tunnels VPN entre le siège, les techniciens de service et les machines ou usines installées. La faille est affectée d’un score de 9.8 sur l’échelle CVSS et concerne les versions du serveur antérieures à la V3.2 et V3.1. Un problème de Cross-Site Scripting, XSS de moindre gravité (CVE-2020-23064) a également été corrigé dans la bibliothèque jQuery qui fait partie du service et qui pourrait permettre à des attaquants distants d’exécuter un code arbitraire par l’intermédiaire de l’élément options de JQuery.
Une vulnérabilité à haut risque a aussi été colmatée dans le composant SINEMA Remote Connect Client. Cette faille, répertoriée sous la référence CVE-2024-22045, pourrait donner à des attaquants la capacité d’accéder à des informations sensibles parce que le produit a placé ces informations dans des fichiers et des répertoires accessibles à des utilisateurs non autorisés. De plus, une mise à jour logicielle majeure a été publiée pour le lecteur mobile RFID SIMATIC RF160B, un terminal portable alimenté par batterie et utilisé dans de nombreux secteurs d’activité. La nouvelle version 2.2 corrige plus de 150 vulnérabilités découvertes au cours des dernières années, dont 11, jugées critiques, pourraient entraîner l’exécution de code.
Des débordements de mémoire critiques
Un bug critique de débordement de mémoire tampon (CVE-2024-22039) affecté du score CVSS de 10.0, le plus élevé possible, a été comblé dans les systèmes de protection incendie Sinteso EN and Cerberus PRO EN Fire Protection Systems. La faille se situe dans la bibliothèque de communication réseau utilisée dans les systèmes qui valide incorrectement la longueur des attributs des certificats X.509. La faille peut être exploitée par des attaquants de type man-in-the-middle qui peuvent intercepter la communication de l’outil d’ingénierie utilisé dans le réseau du système de protection contre les incendies et peuvent entraîner l’exécution de code arbitraire sur le système d’exploitation sous-jacent en tant que root. A noter que deux autres failles de mémoire réparées dans la même bibliothèque de communication réseau, qui pourraient être exploitées par des attaquants de type man-in-the-middle pour faire planter le service. Comme ces brèches n’affectent que l’application, et non le système sous-jacent, elles ont été classées dans la catégorie « gravité élevée ».
De multiples vulnérabilités, dont trois critiques pouvant conduire à l’exécution de code à distance, ont été endiguées dans la plateforme matérielle Siemens RUGGEDCOM APE1808 qui est équipée du pare-feu de dernière génération Fortigate. Les failles ont été héritées de FortiOS et précédemment corrigées. Parmi les constructeurs touchés, il y a Mitsubishi Electric qui a mis à jour ses contrôleurs de la série MELSEC-Q/L utilisés pour l’automatisation des usines et dans le module CPU de la série MELSEC. Ces vulnérabilités peuvent être exploitées à distance par l’envoi, à travers le réseau, de paquets spécifiquement conçus vers les appareils concernés.
Des correctifs pour des failles ICS de haute gravité
Siemens a aussi corrigé des failles à risque élevé et à faible risque dans les dispositifs de surveillance de l’alimentation SENTRON 7KM PAC3120 et SENTRON 7KM PAC3220, l’outil de développement de produits Siemens Solid Edge, le module d’extension Ethernet SENTRON 3KC ATC6, les commutateurs Ethernet industriels des familles SCALANCE XB-200, XC-200, XP-200, XF-200BA et XR-300WG, et la solution de gestion des informations de sécurité physique (Physical Security. Information Management systems, PSIM) de Siemens Surveillance Control. Delta Electronics a corrigé plusieurs failles à haut risque (CVSS 8.8) dans son système de gestion de l’énergie industrielle DIAEnergie.
Ces vulnérabilités basées sur le web exposent à des contournements d’autorisation, des injections SQL, des attaques XSS et de traversée de répertoire. Une faille de traversée de répertoire à haut risque et un problème de divulgation d’informations ont été corrigés dans Softing edgeConnector, un module logiciel qui connecte les contrôleurs SIMATIC S7 aux applications IIoT.
Le groupe UAC-0184 cible le personnel militaire ukrainien, y compris à l’étranger, et utilise la stéganographie pour infecter leurs terminaux avec un cheval de Troie d’accès à distance.
Le conflit en Ukraine est souvent qualifié de guerre hybride avec une présence de plus en plus marquée du volet cyber-offensif. Dernier exemple en date, l’usage de la stéganographie où un groupe d’attaquants a diffusé des charges utiles en les cachant dans les pixels d’images. Repéré sous le nom de UAC-0184 par plusieurs entreprises de sécurité, ainsi que par le CERT ukrainien, le groupe a ciblé des militaires ukrainiens via des courriels d’hameçonnage se faisant passer pour des messages de la 3e brigade d’assaut Separate Assault Brigade de l’Ukraine et des Forces de défense israéliennes (Israeli Defense Forces, IDF).
Bien que la plupart des destinataires de ces messages se trouvaient en Ukraine, l’éditeur de sécurité Morphisec a confirmé l’existence de cibles en dehors du pays. « Si l’adversaire a stratégiquement ciblé des entités basées en Ukraine, il a apparemment cherché à s’étendre à d’autres entités affiliées à l’Ukraine », ont indiqué les chercheurs dans un rapport. Ils ajoutent que « les investigations ont mis en évidence une cible plus spécifique : les entités ukrainiennes basées en Finlande ». Morphisec a également observé que cette technique d’attaque stéganographique avait été élaborée pour livrer des charges utiles malveillantes après la compromission initiale.
La diffusion du cheval de Troie Remcos comme finalité
Les attaques détectées par Morphisec comprennent un chargeur de malware connu sous le nom d’IDAT ou HijackLoader, utilisé par le passé pour diffuser divers chevaux de Troie et programmes malveillants, notamment Danabot, SystemBC et RedLine Stealer. Dans le cas présent, UAC-0184 s’en est servi pour déployer un RAT (Remote Access Trojan) appelé Remcos. « IDAT se distingue par son architecture modulaire et utilise des caractéristiques uniques comme l’injection de code et les modules d’exécution, ce qui le différencie des chargeurs conventionnels », ont expliqué les chercheurs. « Le chargeur utilise des techniques sophistiquées comme le chargement dynamique des fonctions de l’API Windows, les tests de connectivité HTTP, les listes de blocage de processus et les appels système pour échapper à la détection. Le processus d’infection d’IDAT se déroule en plusieurs étapes, chacune remplissant des fonctions distinctes », complètent-ils. L’infection se déroule en plusieurs phases, la première consistant à appeler une URL distante pour accéder à un fichier .js (JavaScript). Le code de ce fichier indique à l’exécutable où chercher un bloc de code chiffré dans son propre fichier et la clé à utiliser pour le déchiffrer.
Les chercheurs ont retracé le processus d’infection via la stéganographie. (Crédit Photo : Morphisec)
La configuration IDAT exploite aussi un fichier PNG intégré dont le contenu est recherché pour localiser et extraire la charge utile en prenant l’emplacement 0xEA79A5C6 comme point de départ. Le code des malwares peut être caché dans les données des pixels des fichiers image et vidéo sans nécessairement avoir d’incidence sur le fonctionnement de ces fichiers ou sur les informations multimédias qu’ils contiennent. Même si cette technique n’est pas nouvelle pour les attaquants, elle est rarement observée. « Par exemple, une image avec une profondeur de pixel de 24 bits (16,7 millions de couleurs) peut contenir un code intégré dans les bits de poids faible (Least Significant Digit, LSD) de chaque pixel, sans modifier l’aspect de l’image », ont encore expliqué les experts de Morphisec. « Même en scannant le fichier multimédia, la charge utile malveillante étant obscurcie, elle peut échapper à la détection basée sur les signatures, ce qui permet à un chargeur de logiciels malveillants de déposer le média, d’extraire la charge utile malveillante et de l’exécuter dans la mémoire ».
Des IoC publiés
Pour exécuter le payload caché, le chargeur IDAT s’appuie sur une autre méthode connue sous le nom de « module stomping », où il est injecté dans un fichier DLL légitime – appelé PLA.dll (Performance Logs and Alerts) dans ce cas – afin de réduire les chances d’être détectée par un produit de sécurité des endpoint.
Remcos permet aux attaquants de voler des informations et de surveiller l’activité d’une victime. Il donne également aux attaquants la capacité de contrôler un ordinateur infecté et, comme il s’agit d’un RAT commercial et non d’un RAT personnalisé, de nombreux groupes l’ont utilisé par le passé. Les avis de sécurité de Morphisec et du CERT-UA contiennent des hachages de fichiers et des adresses IP qui peuvent servir d’indicateurs de compromission pour développer des signatures de détection.
Des chercheurs ont découvert que de nombreux déploiements de Salesforce comprennent du code Apex non sécurisé. Des failles critiques ont été observées pouvant entraîner des fuites ou des corruptions de données.
Des experts de Varonis alertent sur la présence d’instances de code Apex non sécurisé dans les déploiements Salesforce de nombreuses entreprises, laissant craindre de sérieuses vulnérabilités qui mettent en danger leurs données et les workflows. Ces derniers disent avoir trouvé des failles de gravité élevée et critique dans le code Apex utilisé par plusieurs entreprises du Fortune 500 et des agences gouvernementales.
« Si elles sont exploitées, ces vulnérabilités peuvent entraîner des fuites et des corruptions de données et nuire aux fonctions métiers de Salesforce », ont expliqué les chercheurs dans un rapport. « C’est la raison pour laquelle il est essentiel de garder une trace des classes Apex et de leurs propriétés, de savoir qui peut les exécuter et comment elles sont utilisées ».
Des classes Apex insuffisamment restreintes
Apex est un langage de programmation orienté objet dont la syntaxe est similaire à Java et que les développeurs peuvent utiliser pour exécuter des instructions de flux et de contrôle sur les serveurs Salesforce ainsi que des appels via l’API Salesforce. Apex propose aux utilisateurs de personnaliser leurs instances Salesforce en ajoutant une logique métier supplémentaire aux événements du système, notamment les clics sur les boutons, les mises à jour d’enregistrements connexes et les pages Visualforce. « Une classe Apex est un template ou un blueprint utilisé pour créer des objets Apex », ont encore expliqué les spécialistes. « Les classes comprennent d’autres classes, des méthodes définies par l’utilisateur, des variables, des exceptions de types et un code d’initialisation statique ». Elles constituent donc un outil puissant pour les développeurs, mais il est également très important d’examiner attentivement leurs capacités et de restreindre les personnes qui peuvent y accéder.
Le code Apex peut fonctionner en deux modes « sans partage » et « avec partage ». Dans le premier, le code Apex ignore les autorisations de l’utilisateur et peut accéder à n’importe quel enregistrement et apporter des modifications, alors que dans le second, le code respecte les autorisations de l’utilisateur au niveau de l’enregistrement mais ignore celles au niveau de l’objet et du champ. Les classes Apex configurées pour fonctionner en mode « sans partage » sont parfois nécessaires pour mettre en œuvre des fonctionnalités importantes, mais elles peuvent présenter un risque sérieux, en particulier quand elles sont mises à la disposition d’invités ou d’utilisateurs externes. Parmi les problèmes les plus courants pouvant découler des classes Apex, on peut citer les références directes d’objets non sécurisées (Insecure Direct Object References, IDOR), où un attaquant peut lire, manipuler ou supprimer des tables complètes de données auxquelles il ne devrait pas avoir accès, ou l’injection SOQL ; et l’injection SOSL, où le code présente des failles qui permettent aux attaquants de manipuler les requêtes effectuées par la classe pour exfiltrer des données ou modifier le flux de processus prévu.
Vérifier l’appel des classes Apex
Les experts recommandent aux entreprises de vérifier qui peut appeler les différentes classes Apex utilisées dans leurs instances et leurs capacités, en particulier les classes qui fonctionnent en mode « sans partage ». Cette opération peut être réalisée manuellement en passant en revue chaque classe, mais ce processus prend du temps. « Pour déterminer qui peut appeler une classe Apex, il faut vérifier à la fois les profils et les ensembles de permissions (depuis Winter, si l’on clique sur « Sécurité » en examinant la classe Apex elle-même, on ne peut voir que les profils, ce qui n’est pas suffisant pour déterminer qui peut appeler une classe Apex) », mettent en garde les chercheurs. La bonne façon de procéder est d’aller d’abord dans la section « Utilisateur », puis dans « Profils », et de cocher la case « Accès activé à la classe Apex » (Enabled Apex Class Access) dans chaque profil. Ensuite, pour chaque entrée de l’option « Accès activé à la classe Apex », l’administrateur doit faire défiler la section Apps et cliquer sur l’option « Accès à la classe Apex » (Apex Class Access) pour voir les droits. En outre, pour vérifier si une classe Apex est configurée pour fonctionner « sans partage », son code source peut être examiné, car la chaîne « sans partage » se trouve dans l’une des premières lignes de la déclaration de la classe.
Le rapport Varonis comprend également des bonnes pratiques sur la manière de sécuriser le code Apex pour éviter les entrées non sécurisées qui peuvent conduire à une injection SOQL ou SOSL. Selon le modèle de responsabilité partagée, ce sont les clients de Salesforce et non Salesforce qui sont responsables de la sécurité de leur code Apex. « Une stratégie de sécurité complète devrait vérifier que les classes Apex ont été examinées par des spécialistes de la sécurité, et pas seulement par les développeurs et les administrateurs de Salesforce », ont déclaré les chercheurs. « C’est généralement le cas pour le code qui fait partie d’un paquet AppExchange, mais ce n’est pas toujours le cas pour les autres codes qui ne font pas partie d’AppExchange. Cela s’applique particulièrement au code interne, qui est souvent négligé. »
Plusieurs groupes de cybercriminels ont utilisé le gestionnaire de protocole ms-appinstaller pour contourner les protections et diffuser des ransomwares et d’autres malwares. Microsoft a décidé de désactiver cette fonctionnalité.
L’année début fort pour la sécurité de Windows. En effet, Microsoft a désactivé la fonctionnalité App Installer qui, comme son nom l’indique, déploie des applications Windows 10. Elle le fait directement depuis un page web en cliquant sur un lien au format URI (uniform ressource identifier) ms-appinstaller. Le problème est que depuis quelques mois cette fonction a été largement utilisée par des cybercriminels pour diffuser des ransomwares ou d’autres malwares.
« Les attaquants ont probablement choisi le vecteur du gestionnaire de protocole ms-appinstaller car il offre la possibilité de contourner les mécanismes conçus pour protéger les utilisateurs contre les malwares, comme Defender SmartScreen et les alertes intégrées au navigateur qui se déclenchent en cas de téléchargements de formats de fichiers exécutables », a déclaré Microsoft dans un avis publié la semaine dernière. Le gestionnaire de protocole a été désactivé le 28 décembre avec la publication de la version 1.21.3421.0 d’App Installer. Une décision prise après la mis en garde contre la vulnérabilité Windows AppX Installer Spoofing Vulnerability, référencée CVE-2021-43890, lors du dernier Patch Tuesday.
Fonctionnement d’App Installer
C’est pour faciliter l’installation des apps Universal Windows Platform (UWP), anciennement connues sous le nom d’apps Windows Store que Microsoft a introduit la fonctionnalité App Installer dans Windows 10 en 2016. Ces applications peuvent être déployées sur tous les appareils Windows et sont distribuées dans un format de paquet appelé MSIX sous forme de fichiers .msxi ou .msixbundle. Introduit en 2019, le format MSIX a remplacé l’ancien format d’emballage AppX pour les applications du Microsoft Store. Cependant, les paquets MSIX ne doivent pas nécessairement être déployés à partir du Microsoft Store, ils peuvent également être installés hors ligne et peuvent aussi être déployés à partir de n’importe quel site web grâce au schéma URI et au gestionnaire de protocole ms-appinstaller.
La firme de Redmond encourage les entreprises à utiliser les paquets MSIX pour déployer leurs applications, car ils offrent une meilleure fiabilité et un taux élevé de succès de l’installation, et qu’ils optimisent l’usage de la bande passante et de l’espace disque. « MSIX offre aux entreprises d’être en phase avec les dernières évolutions et de s’assurer que leurs applications sont toujours à jour. Grâce à ce format, les informaticiens et les développeurs peuvent fournir une solution centrée sur l’utilisateur tout en réduisant le coût de possession de l’application en limitant la nécessité d’un reconditionnement », a encore déclaré l’entreprise.
Quand l’application est déployée directement à partir d’un site web, la page contiendra un lien de la forme ms-appinstaller:?source=http://link-to.domain/app-name.msix. En cliquant sur ce lien, le navigateur transmet la demande au gestionnaire de protocole ms-appinstaller de Windows, qui lance App Installer. Cette fonctionnalité est comparable à celle d’autres applications qui enregistrent des gestionnaires de protocole personnalisés dans Windows, par exemple quand on clique sur le bouton d’une page web pour participer à une conférence téléphonique et que le navigateur ouvre automatiquement les applications de bureau Zoom ou Microsoft Teams.
Plusieurs groupes de cybercriminels à la manoeuvre
Cela fait un certain temps que les attaquants ont commencé à abuser du schéma URI ms-appinstaller en redirigeant les utilisateurs vers des pages web frauduleuses censées proposer des logiciels populaires, mais livrant à la place des malwares emballés dans le format MSIX. Selon Microsoft, la technique a été adoptée par de nombreux groupes de pirates, avec un pic d’attaques en novembre et décembre 2023. Début décembre, un groupe de courtiers d’accès, suivi par l’éditeur sous le nom de Storm-0569, a lancé une campagne d’optimisation des moteurs de recherche pour distribuer BATLOADER avec cette technique. Le groupe a empoisonné les résultats de recherche avec des liens vers de fausses pages web imitant des sites officiels d’applications légitimes comme Zoom, Tableau, TeamViewer et AnyDesk. « Les utilisateurs qui cherchent une application légitime sur Bing ou Google peuvent se voir présenter une page d’atterrissage usurpant les pages du fournisseur du logiciel original et comprenant des liens vers des programmes d’installation malveillants via le protocole ms-appinstaller », a expliqué Microsoft. « L’usurpation de l’identité d’un logiciel légitime populaire est une tactique courante d’ingénierie sociale », a ajouté le fournisseur. Si les utilisateurs cliquent sur les liens malveillants, la fenêtre d’App Installer s’affiche, avec un bouton d’installation. Si l’utilisateur clique sur ce bouton, le paquet MSIX malveillant est installé avec des scripts PowerShell et batch supplémentaires qui déploient BATLOADER. Ce chargeur de logiciels malveillants est ensuite utilisé pour déployer d’autres implants comme Cobalt Strike Beacon, l’outil d’exfiltration de données Rclone et le ransomware Black Basta.
Un autre courtier d’accès repéré sous le nom de Storm-1113 et spécialisé dans la distribution de logiciels malveillants via des annonces de recherche a également utilisé cette technique à la mi-novembre 2023 pour déployer un chargeur de logiciels malveillants appelé EugenLoader qui usurpait des téléchargements Zoom. Étant donné que ce groupe propose le déploiement de malware en tant que service, EugenLoader a été utilisé pour déployer divers implants, notamment Gozi, Redline stealer, IcedID, Smoke Loader, NetSupport Manager (aussi connu sous le nom de NetSupport RAT), Sectop RAT et Lumma stealer. « Le groupe Sangria Tempest a aussi utilisé des publicités Google pour inciter les utilisateurs à télécharger des paquets d’applications MSIX malveillants – peut-être en s’appuyant sur l’infrastructure de Storm-1113 – et, dans ce cas, à la livraison de POWERTRASH, un script PowerShell hautement obscurci », ont déclaré les chercheurs de Microsoft.
Une désactivation nécessaire, mais pas suffisante
Un autre groupe repéré par Microsoft sous le nom de Storm-1674 a utilisé l’infrastructure et les services de Storm-1113 pour abuser du gestionnaire de protocole malveillant ms-appinstaller et déployer SectopRAT ou DarkGate. Cependant, le groupe a distribué des liens vers les pages d’accueil falsifiées via des messages sur Teams. Les pages usurpaient l’identité de services comme OneDrive et SharePoint et invitaient les utilisateurs à télécharger Adobe Acrobat Reader ou d’autres outils pour accéder aux fichiers censés y être répertoriés. Tous les fichiers MSIX frauduleux fournis par l’intermédiaire de ces sites web sont signés numériquement afin d’éviter les alertes de sécurité.
En désactivant par défaut le gestionnaire de protocole ms-appinstaller, Microsoft oblige ces fichiers à être téléchargés sur le disque avant d’être exécutés, ce qui signifie que les produits de type EDR ont une chance de les analyser et de les signaler. Même si la désactivation n’empêche pas l’installation de fichiers MSIX directement à partir de sites web, ces fichiers peuvent toujours être téléchargés et installés hors ligne, ce qui ne devrait pas avoir d’incidence sur les entreprises qui utilisent ce format d’emballage d’application. Les utilisateurs qui ont besoin de cette fonctionnalité peuvent la réactiver en faisant basculer la stratégie de groupe EnableMSAppInstallerProtocol en mode « Disabled ».
Des chercheurs ont découvert une campagne d’un botnet spécialisé dans les attaques DDoS qui cible les instances fonctionnant avec l’API Docker Engine. L’image malveillante a été téléchargée plus de 3 000 fois.
La conteneurisation se développe rapidement et intéresse de facto les cybercriminels. Les experts de Cado Security ont observé une campagne menée par un botnet nommé OracleIV, spécialisé dans les attaques en déni de service. Elle a la particularité de s’attaquer aux environnements se servant de l’API Docker Engine à travers une image malveillante. « L’hébergement du conteneur malveillant dans Dockerhub, la bibliothèque d’images de conteneurs de Docker, rationalise encore davantage ce processus », souligne les chercheurs dans un rapport.
Image OracleIV malveillante
L’attaque observée par Cado commence par une requête HTTP POST ” /images/create” sur l’instance de l’API Docker non protégée. Ensuite, des paramètres pointent vers une image appelée oracleiv_latest, téléchargée sur Docker Hub par un utilisateur nommé robbertignacio328832. Cette requête équivaut à une commande docker pull qui télécharge l’image du conteneur et l’installe localement, suivie d’une commande de démarrage du conteneur. Le ciblage des API de Docker Engine exposées publiquement et non protégées n’est pas nouveau. Plusieurs groupes d’attaquants recherchent de telles instances et déploient généralement des malwares de cryptojacking.
C’est le cas d’un groupe appelé TeamTNT qui s’attaque principalement aux environnements cloud. Ce groupe est à l’origine d’un ver baptisé Silentbob, lancé au début de l’année, qui ciblait des instances Docker et Jupyter Notebook non sécurisées et volait des informations d’identification AWS. Comme pour cette attaque, TeamTNT a hébergé ses images de conteneurs malveillants sur Dockerhub à partir de plusieurs comptes. L’image OracleIV trouvée par Cado était régulièrement mise à jour et comptait plus de 3 000 téléchargements, ce qui laisse penser que la campagne a été active et réussie.
Réseau de zombies DDoS et cryptojacking
Une fois lancée, l’image du conteneur compromis exécute un binaire ELF appelé oracle.sh, suivi de commandes wget qui attirent et exécutent une variante du cryptomineur XMRig avec une configuration personnalisée. L’instance XMRig n’est pas réellement utilisée, et ces attaquants sont bien plus intéressés par le détournement des ressources du serveur pour des attaques DDoS. L’exécutable oracle.sh a été écrit à l’origine en code Python et compilé avec Cython (C-Extensions for Python). Le code met en œuvre plusieurs méthodes DDoS différentes, notamment les inondations de paquets TCP, UDP et SYN, ainsi que des variantes spécifiques visant à déjouer diverses défenses. Par exemple, l’inondation UDP standard implique des paquets de 40 000 octets, fragmentés en raison de la limite de taille des paquets de l’UDP, ce qui crée une surcharge de calcul sur la cible pour réassembler les fragments. Cependant, le botnet met également en œuvre des débordements UDP avec des paquets de 18, 20 et 8 octets. Ceux-ci sont lancés avec les commandes appelées FIVE, VSE et OVH et semblent viser les serveurs FiveM, le moteur de jeu Source de Valve et le fournisseur de cloud français OVH.
Le botnet met aussi en œuvre une attaque de type Slowloris qui consiste à ouvrir de nombreuses connexions à un serveur et à envoyer continuellement de petites quantités de données pour maintenir ces connexions ouvertes. Le client du bot se connecte à un serveur de commande et de contrôle en utilisant une authentification ordinaire basée sur une clé codée en dur, envoie des informations de base sur le système hôte et écoute les commandes. « La portabilité qu’apporte la conteneurisation permet aux charges utiles malveillantes d’être exécutées de manière déterministe sur les hôtes Docker, quelle que soit la configuration de l’hôte lui-même », ont expliqué les chercheurs de Cado. « Même si OracleIV n’est pas techniquement une attaque de la supply chain, les utilisateurs de Docker Hub doivent savoir que des images de conteneurs malveillants existent effectivement dans la bibliothèque d’images de Docker, un problème qui ne sera semble-t-il pas corrigé dans un avenir proche. L’entreprise de sécurité conseille aux entreprises d’évaluer périodiquement les images Docker qu’elles tirent de Docker Hub pour s’assurer qu’elles n’ont pas été transformées en chevaux de Troie. En outre, elles devraient s’assurer que toutes les API et interfaces de gestion des technologies cloud comme Jupyter, Docker et Redis sont sécurisées par une authentification et protégées par des règles de pare-feu.
Des chercheurs ont découvert une campagne d’un botnet spécialisé dans les attaques DDoS qui cible les instances fonctionnant avec l’API Docker Engine. L’image malveillante a été téléchargée plus de 3 000 fois.
La conteneurisation se développe rapidement et intéresse de facto les cybercriminels. Les experts de Cado Security ont observé une campagne menée par un botnet nommé OracleIV, spécialisé dans les attaques en déni de service. Elle a la particularité de s’attaquer aux environnements se servant de l’API Docker Engine à travers une image malveillante. « L’hébergement du conteneur malveillant dans Dockerhub, la bibliothèque d’images de conteneurs de Docker, rationalise encore davantage ce processus », souligne les chercheurs dans un rapport.
Image OracleIV malveillante
L’attaque observée par Cado commence par une requête HTTP POST ” /images/create” sur l’instance de l’API Docker non protégée. Ensuite, des paramètres pointent vers une image appelée oracleiv_latest, téléchargée sur Docker Hub par un utilisateur nommé robbertignacio328832. Cette requête équivaut à une commande docker pull qui télécharge l’image du conteneur et l’installe localement, suivie d’une commande de démarrage du conteneur. Le ciblage des API de Docker Engine exposées publiquement et non protégées n’est pas nouveau. Plusieurs groupes d’attaquants recherchent de telles instances et déploient généralement des malwares de cryptojacking.
C’est le cas d’un groupe appelé TeamTNT qui s’attaque principalement aux environnements cloud. Ce groupe est à l’origine d’un ver baptisé Silentbob, lancé au début de l’année, qui ciblait des instances Docker et Jupyter Notebook non sécurisées et volait des informations d’identification AWS. Comme pour cette attaque, TeamTNT a hébergé ses images de conteneurs malveillants sur Dockerhub à partir de plusieurs comptes. L’image OracleIV trouvée par Cado était régulièrement mise à jour et comptait plus de 3 000 téléchargements, ce qui laisse penser que la campagne a été active et réussie.
Réseau de zombies DDoS et cryptojacking
Une fois lancée, l’image du conteneur compromis exécute un binaire ELF appelé oracle.sh, suivi de commandes wget qui attirent et exécutent une variante du cryptomineur XMRig avec une configuration personnalisée. L’instance XMRig n’est pas réellement utilisée, et ces attaquants sont bien plus intéressés par le détournement des ressources du serveur pour des attaques DDoS. L’exécutable oracle.sh a été écrit à l’origine en code Python et compilé avec Cython (C-Extensions for Python). Le code met en œuvre plusieurs méthodes DDoS différentes, notamment les inondations de paquets TCP, UDP et SYN, ainsi que des variantes spécifiques visant à déjouer diverses défenses. Par exemple, l’inondation UDP standard implique des paquets de 40 000 octets, fragmentés en raison de la limite de taille des paquets de l’UDP, ce qui crée une surcharge de calcul sur la cible pour réassembler les fragments. Cependant, le botnet met également en œuvre des débordements UDP avec des paquets de 18, 20 et 8 octets. Ceux-ci sont lancés avec les commandes appelées FIVE, VSE et OVH et semblent viser les serveurs FiveM, le moteur de jeu Source de Valve et le fournisseur de cloud français OVH.
Le botnet met aussi en œuvre une attaque de type Slowloris qui consiste à ouvrir de nombreuses connexions à un serveur et à envoyer continuellement de petites quantités de données pour maintenir ces connexions ouvertes. Le client du bot se connecte à un serveur de commande et de contrôle en utilisant une authentification ordinaire basée sur une clé codée en dur, envoie des informations de base sur le système hôte et écoute les commandes. « La portabilité qu’apporte la conteneurisation permet aux charges utiles malveillantes d’être exécutées de manière déterministe sur les hôtes Docker, quelle que soit la configuration de l’hôte lui-même », ont expliqué les chercheurs de Cado. « Même si OracleIV n’est pas techniquement une attaque de la supply chain, les utilisateurs de Docker Hub doivent savoir que des images de conteneurs malveillants existent effectivement dans la bibliothèque d’images de Docker, un problème qui ne sera semble-t-il pas corrigé dans un avenir proche. L’entreprise de sécurité conseille aux entreprises d’évaluer périodiquement les images Docker qu’elles tirent de Docker Hub pour s’assurer qu’elles n’ont pas été transformées en chevaux de Troie. En outre, elles devraient s’assurer que toutes les API et interfaces de gestion des technologies cloud comme Jupyter, Docker et Redis sont sécurisées par une authentification et protégées par des règles de pare-feu.