Les chercheurs de Group-IB ont travaillé sur un groupe nommé ShadowSyndicate particulièrement actif. Il s’agirait d’un affilié indépendant impliqué dans des opération de RaaS (ransomware as a service).
Au cours des deux dernières années, un groupe de cybercriminels non documenté, a mis en place plus de 80 serveurs de commande et contrôle (C2). Des chercheurs de Group-IB se sont penchés dessus et l’ont baptisé ShadowSyndicate. Il s’agirait d’un broker d’accès initial ou un affilié dans plusieurs opérations de ransomware as a service (RaaS). « Il est extrêmement rare qu’une empreinte Secure Shell (SSH) ait un réseau de connexions aussi complexe avec un grand nombre de serveurs malveillants », ont déclaré dans leur rapport les experts « Au total, depuis juillet 2022, nous avons trouvé l’empreinte SSH de ShadowSyndicate sur 85 serveurs », ajoutent-ils.
« En outre, nous pouvons affirmer avec plus ou moins de certitude que le groupe a utilisé sept familles de ransomware différentes au cours de l’année écoulée, ce qui rend ShadowSyndicate remarquable pour sa polyvalence », observent-ils. Les analystes du Group-IB se sont associés au chercheur Joshua Penny de l’European MSSP Bridewell et au chercheur indépendant en malware Michael Koczwara pour étudier toutes les connexions qu’ils ont trouvées et tenter de déterminer qui se cache vraiment derrière ShadowSyndicate. Est-ce un hébergeur de serveurs qui déploie des serveurs avec la même empreinte SSH, un ingénieur DevOps au service d’acteurs de la menace, un service d’hébergement protégé pour les cybercriminels, un courtier d’accès initial ou une société affiliée à un RaaS ?
Connexions à divers implants d’accès à distance
Plus de 50 serveurs parmi ceux pour lesquels l’empreinte SSH de ShadowSyndicate a été trouvée ont été utilisés comme serveurs C2 pour les implants Cobalt Strike. Cet outil commercial de test de pénétration, normalement vendu sous licence, est devenu le favori de nombreux groupes d’attaquants qui utilisent des versions piratées. Chaque implant Cobalt Strike comporte habituellement un filigrane associé à une clé de licence unique, mais les versions piratées utilisées par les cybercriminels comportent des watermark personnalisés tels que 12345. Parmi les serveurs exploités par ShadowSyndicate, les chercheurs ont trouvé des filigranes Cobalt Strike précédemment associés à des attaques ayant entraîné le déploiement des familles de ransomwares Royal, Cactus, Quantum et Nokoyawa.
D’autres serveurs portant l’empreinte SSH de ShadowSyndicate ont été utilisés comme serveurs C2 pour Sliver, un autre outil de test de pénétration open source écrit en Go, mais aussi pour IcedID, un cheval de Troie utilisé comme malware par de nombreux gangs de ransomware ces dernières années ; pour Meterpreter, l’implant du framework de test de pénétration Metasploit ; et pour Matanbuchus, un chargeur de logiciels malveillants en tant que service (MaaS), également utilisé pour déployer des charges utiles. En fait, il pourrait même y avoir un lien entre certains d’entre eux. Par exemple, IcedID a déjà été utilisé pour déployer des implants Cobalt Strike. Il a aussi été utilisé pour les familles de ransomwares Karakurt, RansomEXX, Black Basta, Nokoyawa, Quantum, REvil, Xingteam et Conti.
Une affiliation réussie
Les chercheurs ont déclaré qu’ils étaient assez convaincus que ShadowSyndicate n’était pas un service d’hébergement, car les serveurs étaient situés dans 13 pays différents, dont un grand nombre localisés au Panama, et sur différents réseaux appartenant à des organisations différentes. Les experts ont trouvé des liens étroits entre ShadowSyndicate et les attaques de Quantum (septembre 2022), Nokoyawa (octobre 2022, novembre 2022 et mars 2023) et le ransomware ALPHV (alias BlackCat) en février 2023. Des connexions moins manifestes ont été trouvées avec les ransomwares Royal, Cl0p et Play. « En vérifiant les serveurs de la liste A à l’aide des sources de données du Group-IB, nous avons constaté que certains serveurs étaient répertoriés sous les noms de Ryuk, Conti et Trickbot », ont déclaré les spécialistes. « Cependant, ces groupes criminels n’existent plus. Ryuk a cessé d’exister fin 2021, tandis que Conti et Trickbot (qui sont liés) ont été mis en sommeil début 2022 ». Les chercheurs pensent que les anciens membres de ces groupes pourraient poursuivre leurs activités criminelles en utilisant la même infrastructure, mais qu’ils pourraient désormais opérer individuellement ou au sein d’autres groupes criminels.
Il est possible que ShadowSyndicate soit un IAB (Initial Access Broker), c’est-à-dire un acteur de la menace qui compromet les systèmes et vend l’accès à d’autres cybercriminels, y compris des gangs de ransomware. Cependant, les chercheurs pensent qu’il est plus probable que le groupe soit en fait un affilié indépendant travaillant pour plusieurs opérations RaaS. Dans l’écosystème des ransomwares, les affiliés sont ceux qui s’introduisent dans les entreprises et déploient un programme de ransomware en échange d’une part importante de la rançon payée par les victimes. Les développeurs de ransomwares fournissent généralement le générateur de logiciels malveillants et l’infrastructure, comme le site de fuite de données et le site de négociation de la rançon. Ils s’occupent également de la négociation avec les victimes et de l’infrastructure de paiement. En revanche, ils ne se chargent pas eux-mêmes du piratage et du déploiement des malwares. « Même si nous ne pouvons pas émettre un avis définitif, tous les éléments obtenus au cours de ce projet de recherche commun suggèrent que l’hypothèse la plus plausible est que ShadowSyndicate est un affilié travaillant avec divers RaaS », ont déclaré les chercheurs.
Baptisée Ambersquid, cette campagne de cryptojacking exploite des services cloud sans déclencher les processus d’approbation d’AWS.
Pour passer inaperçus plus longtemps dans les environnements cloud, les attaquants ont commencé à abuser de services moins courants qui ne font pas l’objet d’un examen de sécurité approfondi de la part du fournisseur de cloud. C’est le cas de la campagne de cryptojacking Ambersquid découverte récemment, qui déploie des malware de minage de cryptomonnaie sur AWS Amplify, Fargate et SageMaker au lieu du plus évident Elastic Compute Cloud (EC2).
« L’opération Ambersquida pu exploiter des services cloud sans déclencher le processus d’approbation de ressources supplémentaires généralement exigé par AWS, ce qui aurait été le cas s’ils n’avaient spammé que des instances EC2 », ont déclaré les chercheurs de l’entreprise de sécurité Sysdig dans un rapport. « Cibler plusieurs services pose également des défis supplémentaires, notamment en matière de réponse aux incidents, puisqu’il faut trouver et supprimer tous les mineurs dans chaque service exploité », ont-ils ajouté.
Fonctionnement de la campagne
C’est en analysant 1,7 million d’images de conteneurs Linux hébergés sur Docker Hub pour y rechercher des charges utiles malveillantes que les chercheurs de Sysdig ont découvert la campagne de cryptojacking. Suite aux indices de cryptojacking trouvés lors de l’exécution d’un conteneur, une analyse plus poussée réalisée par les chercheurs a mis à jour plusieurs conteneurs similaires téléchargés par différents comptes depuis mai 2022 qui chargent des crypto-mineurs hébergés sur GitHub. À en juger par les commentaires utilisés dans les scripts malveillants à l’intérieur des conteneurs, les chercheurs pensent que les attaquants à l’origine de la campagne sont originaires d’Indonésie. Après leur déploiement sur AWS à l’aide d’identifiants volés, les images Docker malveillantes exécutent une série de scripts, à commencer par celui qui configure divers rôles et autorisations AWS. L’un d’eux appelé AWSCodeCommit-Role donne accès au service Amplify qui permet aux développeurs de créer, de déployer et d’héberger des applications web et mobiles complètes sur AWS. Ce rôle a également accès au service de référentiel de code source managé CodeCommit, et au service de surveillance de l’infrastructure et de visualisation des données CloudWatch.
Un deuxième rôle, appelé sugo-role, créé par les scripts de conteneur, dispose d’un accès complet à SageMaker, un autre service AWS utilisé par datascientist pour construire, entraîner et déployer des modèles d’apprentissage machine. Un troisième rôle appelé ecsTaskExecutionRole donne, quant à lui, accès à Elastic Container Service (ECS), un système de gestion de conteneurs Docker natif d’AWS. Les attaquants exploitent ensuite les rôles nouvellement créés dans divers services, à commencer par CodeCommit où ils créent un dépôt Git privé qui héberge le code dont ils ont besoin pour les prochaines étapes de leur attaque, ce qui leur évite de quitter l’écosystème AWS après la compromission initiale et réduit les risques d’alertes de trafic sortant. Le dépôt Git sert à héberger le code d’une application malveillante conçue pour être construite et déployée avec le service Amplify. Le script génère ensuite cinq applications Amplify à déployer dans différentes régions AWS et, dans le cadre de leurs scripts de construction, une commande télécharge et exécute un cryptomineur.
Fargate et CodeBuild dans le viseur
Étant donné que le cryptomining et le vol de ressources ont lieu pendant la construction de l’application, les attaquants ont ajouté du code pour prolonger ce processus autant que possible. Quand les applications finissent de se construire, un autre script est exécuté pour mettre à jour le code et le processus est redémarré, ce qui relance la phase de construction et, par conséquent, le cryptominage. Un autre script du conteneur met en place un processus similaire, mais sur le service ECS, qui permet de déployer des conteneurs sur des instances EC2, Fargate – le moteur de calcul serverless d’Amazon – ou des machines virtuelles sur site. Le script donne les autorisations nécessaires au compte ecsTaskExecutionRole, utilisé ensuite pour configurer une tâche ECS qui configure un conteneur sur Fargate avec deux CPU virtuels et 4 Go de RAM et déploie une image Linux regroupant un mineur. La tâche est configurée avec un desiredCount de 30, ce qui signifie que 30 instances seront créées.
Le service d’intégration continue CodeBuild, utilisé pour compiler et tester le code source, est une autre cible de cette campagne. Le fichier de spécification autorisant CodeBuild à exécuter des tâches peut inclure des commandes de compilation et les attaquants ont ajouté des commandes pour exécuter leur mineur. Les attaquants ont également fixé la valeur « timeout-in-minutes » pour la tâche de construction à un maximum de huit heures pour s’assurer que leur mineur fonctionnera pendant cette durée avant d’être redémarré. Ensuite, les attaquants ont ciblé le service d’infrastructure as-code, CloudFormation, qui propose aux utilisateurs de provisionner des ressources AWS et tierces via des modèles. Ces ressources peuvent être regroupées en piles et contrôlées comme une seule unité. « Les scripts des attaquants créent plusieurs piles CloudFormation à partir d’un modèle qui définit un composant EC2 Image Builder », ont expliqué les chercheurs. « Dans ce composant, ils mettent des commandes pour exécuter un mineur pendant la phase de construction de l’image. Ces commandes sont similaires à celles qui peuvent être définies dans un fichier Docker ».
Comme pour Amplify et CodeBuild, le processus de minage est lancé pendant une phase de construction. Les attaquants ont essayé de la prolonger autant que possible en ajoutant des commandes cron dans le modèle pour démarrer une nouvelle build toutes les minutes. Les attaquants ont également abusé de la fonction EC2 Auto Scaling, qui offre aux utilisateurs d’ajouter ou de supprimer des instances EC2 à l’aide de politiques de mise à l’échelle, définies dans des modèles. Cette fonction a été utilisée pour créer deux groupes de huit instances On-Demand et Spot, chacune exécutant une image de conteneur Docker avec un mineur. Enfin, les pirates ont aussi abusé des instances de calcul d’apprentissage machine exécutant Jupyter Notebook App dans le cadre du service Amazon SageMaker. Pour chaque instance Jupyter Notebook, les utilisateurs peuvent définir une configuration de cycle de vie qui inclut une série de scripts shell exécutés au moment de la création des instances. Ils ont utilisé cette fonctionnalité pour inclure une commande qui exécute Docker et déploie l’une de leurs images Docker Hub contenant un mineur. « L’abus de tous ces services, avec des instances de conteneurs voyous et des tâches de construction exécutées dans différentes régions, peuvent engendrer des coûts de fonctionnement de 2 244 dollars par jour et plus pour les victimes », ont estimé les chercheurs de Sysdig.
Des services cloud intégrant du calcul ciblés
« Les fournisseurs de services cloud (CSP) comme AWS offrent une gamme très étendue de services à leurs clients », ont déclaré les chercheurs. « Même si la plupart des attaquants motivés financièrement ciblent des services de calcul comme EC2, il est important de se rappeler que de nombreux autres services fournissent également un accès aux ressources de calcul (certes de manière plus indirecte). Or, on peut facilement négliger la sécurité de ces services, car la visibilité est moindre par rapport à celle offerte par la détection des menaces en cours d’exécution ».
Étant donné que bon nombre de ces services ne sont destinés qu’à exécuter du code temporairement, il n’est pas toujours possible d’installer des solutions de détection de l’exécution. Dans ce cas, les entreprises devraient mettre en place un système de journalisation et de surveillance des tendances d’utilisation de ces services sur leurs comptes afin d’identifier les anomalies et les comportements suspects.
Des chercheurs en sécurité de WatchTowr ont réussi à exécuter du code à distance à très fort impact et démontré un PoC d’exploit fonctionnel sur des pare-feux Juniper. Et ce alors que des correctifs avaient été tout dernièrement publiés par le fournisseur.
Des pirates ont commencé à exploiter des vulnérabilités récemment corrigées dans les pare-feu de Juniper Networks, qui peuvent être enchaînées pour exécuter du code à distance (Remote Code Execution, RCE). Les détails de l’exploit et d’un PoC associé ont été publiés fin de semaine dernière par une équipe de chercheurs en sécurité. « Cette chaîne de bogues intéressante exploite deux bogues presque inutiles de manière isolée, mais qui, une fois combinés, permettent une exécution de code à distance non authentifiée à très fort impact », ont déclaré les chercheurs de l’entreprise de sécurité WatchTowr dans leur analyse détaillée. « Ceux qui utilisent un appareil affecté sont invités à mettre à jour vers une version corrigée dès que possible, et/ou à désactiver l’accès à l’interface J-Web si c’est possible », ont recommandé les chercheurs.
Le 18 août, Juniper a corrigé quatre vulnérabilités identifiées dans ses pare-feu des séries SRX et EX. Les failles se trouvent dans le composant J-Web de Junos OS, le système d’exploitation des pare-feu Juniper, et elles ont toutes un score de 5,3 sur 10 sur l’échelle CVSS (Common Vulnerability Scoring System). Cela correspond à une criticité moyenne, c’est-à-dire que ces failles sont généralement traitées avec une priorité moindre dans les cycles de correction. Cependant, dans ce cas particulier, certaines des vulnérabilités peuvent être enchaînées pour permettre l’exécution de code à distance sans authentification, ce que Juniper met clairement en garde dans son avis.
Les CVE-2023-36846 et CVE-2023-36847 dans le viseur
Deux failles, référencées CVE-2023-36846 et CVE-2023-36847, sont similaires et donnent la capacité à un attaquant non authentifié d’envoyer des requêtes spécialement conçues à un appareil pour télécharger des fichiers arbitraires via J-Web vers le système de fichiers. Deux autres vulnérabilités, référencées CVE-2023-36844 et CVE-2023-36845, également similaires, permettent à un attaquant non authentifié de modifier certaines variables d’environnement PHP. Suite à l’avis de Juniper, les chercheurs de watchTowr ont été intrigués par la possibilité d’enchaîner ces failles et ont donc entrepris de les étudier. Il s’avère que seules deux failles sont nécessaires pour réaliser l’attaque, un téléchargement de fichier et une modification de variable d’environnement. Dans un premier temps, ils ont trouvé la vulnérabilité CVE-2023-36846 en examinant les fonctions internes de l’interface J-Web, qui est une application PHP. Ils en ont repéré une appelée do_upload qui gère le téléchargement de fichiers et ont immédiatement remarqué qu’elle ne comportait pas de contrôle d’authentification. L’exploitation était donc simple, mais le fichier de téléchargement était placé dans un dossier tmp et il semblait que le serveur web lui-même s’exécutait en tant que « jailed process », un processus emprisonné dans un environnement virtuel.
Les chercheurs n’ont pas eu trop de mal non plus à localiser la seconde faille nécessaire à la modification des variables d’environnement PHP. Par contre, le passage à l’exécution de code arbitraire a été difficile grâce aux défenses de sécurité de Junos OS. Tout d’abord, les chercheurs ont essayé d’abuser de la variable LD_PRELOAD qui demande au processus PHP de charger une bibliothèque. Ils ont pointé cette variable vers l’emplacement du fichier qu’ils ont téléchargé en utilisant la première faille, mais la tentative d’exécution a échoué avec un message d’erreur d’authentification. Les chercheurs ont essayé de déboguer l’erreur pendant un long moment pour comprendre ce qui se passait et ont même essayé de charger des bibliothèques qui existaient déjà sur le système, sans succès. « Il s’avère que Juniper utilise (judicieusement) un outil appelé veriexec, qui limite l’exécution aux binaires ayant une signature valide et vérifie également leur emplacement sur le système de fichiers », ont expliqué les chercheurs. « Cela signifie que les tentatives de téléchargement et d’exécution d’une charge utile échoueront, car les charges utiles se trouvent à un emplacement qui ne figure pas sur la liste blanche (et aussi parce qu’elles ne sont pas signées cryptographiquement). C’est excellent pour la sécurité, mais mauvais pour nous ».
Un PoC d’exploit publié sur Github
Les chercheurs se sont ensuite demandé quels binaires à signature numérique pouvaient exister sur le système et s’ils pouvaient influencer leur exécution par le biais d’une variable d’environnement. La réponse, c’est qu’il s’agit du binaire PHP lui-même. PHP est un framework et un runtime, et lorsqu’il démarre, il a un fichier de configuration, généralement appelé php.ini, dont l’emplacement est défini dans une variable d’environnement appelée PHPRC. Les chercheurs ont donc pu télécharger un fichier de configuration php.ini spécialement conçu à l’aide de la vulnérabilité de téléchargement de fichiers, puis utiliser la seconde vulnérabilité pour modifier la variable PHPRC et y faire pointer le processus PHP. Ensuite, ils se sont demandés comment exécuter un code arbitraire à partir d’un fichier de configuration.
Il s’avère que php.ini possède une entrée appelée auto_prepend_file qui permet à l’utilisateur de pointer vers un fichier que le processus exécutera avant tout autre code PHP. La chaîne était désormais complète. Télécharger un fichier contenant un shellcode malveillant, puis télécharger un php.ini spécialement conçu avec une entrée auto_prepend_file pointant vers lui, puis modifier la variable PHPRC pour exécuter le php.ini et implicitement le shellcode malveillant. En plus de leur article détaillé, les chercheurs ont également publié sur GitHub une preuve de concept qui automatise l’ensemble de l’attaque. « Même si la qualité du code est très proche de celle d’autres dispositifs de sa catégorie, comme les dispositifs Fortiguard et Sonicwall que nous avons cassés, il convient de souligner ici que l’utilisation de veriexec par Juniper a été judicieuse, car elle complique l’exécution du code et des commandes », ont déclaré les chercheurs de watchTowr. Mais cela ne suffira pas à décourager des pirates déterminés. Au total, les chercheurs auront mis environ une demi-heure à contourner la limite d’exécution (et, je l’admets, beaucoup plus de temps à se rendre compte qu’elle était en vigueur).
Des attaques en cours
Le jour même où watchTowr a publié son exploit PoC, la Shadowserver Foundation, une entreprise qui analyse l’Internet à la recherche de logiciels malveillants et surveille les attaques à l’aide d’honeypot, a signalé des tentatives d’exploitation de la vulnérabilité Juniper J-Web CVE-2023-36844 et les autres failles. L’organisation a indiqué qu’elle suivait actuellement plus de 8 200 adresses IP avec des interfaces J-Web exposées à Internet. Les chercheurs de watchTowr ont souligné que l’application de correctifs pourrait ne pas être simple, en particulier pour les systèmes Juniper virtualisés fonctionnant dans le cloud.
« Nous avons effectué cette recherche en utilisant un appareil SRX hébergé par Amazon Elastic Compute Cloud EC2, et nous avons été consternés de constater qu’il était apparemment impossible pour nous de mettre à jour l’appareil », ont-ils déclaré. « Les mises à jour ne sont disponibles que pour les utilisateurs enregistrés, et il semble que l’intégration EC2 qui effectue l’enregistrement soit défectueuse ». Les chercheurs conseillent aux utilisateurs qui ne peuvent pas appliquer les correctifs immédiatement de désactiver le composant J-Web ou d’en limiter l’accès à des utilisateurs de confiance. Leur rapport comprend également des indicateurs de compromission que les administrateurs peuvent rechercher dans les fichiers logs PHP de leurs terminaux.
Pour détecter et répondre aux incidents de sécurité affectant les applications de transfert de fichiers managés, IBM pousse un framework open source de défense spécifique, MFT-Detect-Response.
Ces dernières années, de nombreux cybergangs en ransomware et autres acteurs malveillants ont exploité des vulnérabilités dans les applications de transfert de fichiers managés (MFT) mises en place par les entreprises pour proposer un accès à distance sécurisé à leurs documents. Après analyse des composants de 13 de ces solutions, des chercheurs d’IBM ont développé un framework pour aider les défenseurs à élaborer rapidement des détections et des stratégies de réponse aux incidents pouvant bloquer leur exploitation. « Les charges de travail sont massives et les équipes de sécurité sont débordées au point qu’elles n’ont plus le temps d’inspecter de manière proactive ou même de se familiariser avec les mécanismes de fonctionnement de chaque logiciel dans leur environnement », a déclaré l’équipe IBM Security X-Force Incident Response dans un billet de blog. « Le plus souvent, ce n’est qu’après la divulgation d’une vulnérabilité qu’ils essaient de comprendre les composants essentiels d’un outil, alors qu’ils sont déjà en train de courir après le temps pour corriger un système ou pire, contenir un incident, afin de réduire au minimum l’impact du risque sur l’entreprise.
Ce dernier framework est disponible sur GitHub et couvre les outils MFT suivants, qui ont été sélectionnés en fonction de leur popularité et de leur exposition directe sur Internet : Cerberus FTP Server, FileZilla, Cornerstone MFT, SolarWinds Serv-U, JSCAPE, Oracle MFT, WingFTP, Aspera, Diplomat MFT, MyWorkDrive, EasyFTPServer FTPD, ShareFile et ShareTru.
Des attaques MFT qui se multiplient
En juin, le cybergang à l’origine du ransomware Clop a exploité une vulnérabilité d’injection SQL zero-day dans une application MFT appelée MOVEit Transfer pour voler des données aux entreprises et leur extorquer de l’argent. Ce n’était pas la première fois que le groupe, à l’origine des exploits pour les applicances Accellion File Transfer Appliance (FTA) en 2020 et 2021 et les serveurs MFT Fortra/Linoma GoAnywhere au début de 2023, ciblait un outil MFT. Le groupe de cybercriminels Clop n’est pas le seul à cibler ces applications. En mars, un autre acteur de la menace qui a déployé le ransomware IceFire a exploité une faille de désérialisation dans le logiciel de partage de fichiers Aspera Faspex.
Développement du framework de détection des attaques MFT
Les chercheurs d’IBM ont déployé des instances de démonstration, lu la documentation disponible et recueilli des informations sur les forums d’assistance afin de constituer une collection de chemins d’accès aux fichiers, de noms de processus et de services, de numéros de port et d’autres artefacts qu’un outil créerait sur un système. Ils ont ensuite commencé à simuler diverses actions susceptibles de faire partie d’une attaque basée sur une exploitation réelle passée : génération d’événements d’authentification, création de nouveaux comptes d’utilisateurs, exécution de commandes via le logiciel MFT, exfiltration de données en masse, ou déploiement et interaction avec des shells web, ces scripts web qui ne font pas partie de l’application proprement dite.
L’objectif était de comprendre les associations entre ces événements et les données ou les changements qu’ils créent et que l’on peut surveiller dans le cadre d’une stratégie de détection. Il s’agissait notamment de l’activité des fichiers en temps réel, des données de réseau et des données de processus sur le système, des événements enregistrés dans les logs du système ou de l’application et des changements dans la base de données de l’application. Toutes ces sources de données potentielles ont été documentées pour chaque application, ainsi que le processus nécessaire pour les acquérir. « Notre analyse a confirmé ce que nous pensions : tous ces outils sont largement architecturés de la même manière, ce qui signifie que l’approche de la détection et de la réponse pour toutes les solutions MFT peut être généralement la même », ont déclaré les chercheurs.
Composants du framework MFT-Detect-Response
Le framework de détection et de réponse MFT (Manage File Transfer) qui en résulte, appelé MFT-Detect-Response, se compose de plusieurs éléments. MFTData contient des informations spécifiques à chaque application, comme les noms de processus, les noms de fichiers, les chemins d’accès aux fichiers, l’emplacement des fichiers de configuration, les options de configuration, l’emplacement des fichiers logs, les événements enregistrés en cas d’actions diverses, les numéros de port, les dépendances et bien d’autres choses encore.
Un autre composant, appelé MFTDetect, contient des scripts qui exploitent les données MFTData pour générer automatiquement des détections utilisables avec des outils populaires de réponse aux incidents et de détection comme Velociraptor ou des systèmes SIEM qui prennent en charge le format de signature Sigma. Les signatures de détection se déclenchent si les processus associés aux MFT couverts appellent des outils système comme powershell, certutil, cmd.exe ou wmic.exe avec des commandes ou des arguments spécifiques, ou si des services système comme rundll32, regsvr32, mshta, wscript, cscript ou conhost sont appelés par les MFT de manière suspecte. Ces outils et services Windows sont couramment utilisés de manière abusive par les attaquants dans le cadre d’activités de post-exploitation. Un autre composant du framework appelé MFTRespond contient des scripts qui peuvent aider les intervenants en cas d’incident à collecter des données pertinentes à partir de l’une des MFT prises en charge en cas de suspicion de compromission. Enfin, le composant MFTPlaybook contient un modèle de playbook de réponse à un incident MFT qui peut servir de point de départ aux intervenants pour élaborer des stratégies de réponse à un incident pour les logiciels MFT.
L’IA pour créer des signatures de détection pour n’importe quelle application
Les chercheurs d’IBM X-Force ont construit un moteur d’IA de démonstration qui exploite la plateforme d’IA et de données watsonx d’IBM pour automatiser le processus nécessaire à l’élaboration de solutions de détection comme celles du framework de détection MFT, mais pour n’importe quel type de logiciel. Le moteur analyse automatiquement la documentation, les forums et les données système pour identifier les processus que les équipes de sécurité devraient surveiller, peut produire des stratégies de détection et de réponse personnalisées et peut produire un score de risque pour les défenseurs basé sur une analyse de la probabilité qu’une technologie soit ciblée dans des attaques d’exploitation de masse si un exploit est publié. « Des milliers d’outils logiciels disparates sont déployés dans les entreprises, et même si les défenseurs sont très qualifiés pour identifier les activités malveillantes, ils doivent d’abord savoir où chercher », ont déclaré les chercheurs d’IBM. « Il est important de pouvoir hiérarchiser les actifs en fonction de l’aide qu’ils peuvent apporter à un attaquant pour atteindre ses buts et objectifs, de leur degré d’exposition et de l’impact qu’ils pourraient avoir sur l’entreprise ».
Des chercheurs ont mis à jour un malware nommé P2PInfect ciblant les instances Redis via une faille dans une sandbox codée en Lua. Il s’agirait d’un essai pour des attaques plus importantes.
Un galop d’essai ou une campagne ciblée. Les experts de Palo Alto penchent pour la première solution à propos d’un ver touchant les instances Redis, un SGBD en mémoire. Baptisé P2PInfect, le ver, écrit en Rust, utilise un protocole de communication et un réseau point à point (P2P) personnalisés. Il exploite une vulnérabilité connue dans le langage Lua.
Selon Unit 42 (activité recherche de Palo Alto), « cette campagne P2PInfect prépare une attaque potentiellement plus puissante exploitant un solide réseau point à point de serveurs de commande et contrôle ». Le rapport ajoute « des occurrences du mot ‘miner’ sont présentes dans la boîte à outils malveillante de P2PInfect, même si les chercheurs n’ont pas trouvé la preuve formelle de la mise en œuvre d’opérations de cryptomining ».
La sandbox Lua vulnérable
Généralement, le langage de programmation multi-plateformes et moteur de script Lua est intégré en tant que bibliothèque en sandbox dans les applications pour la prise en charge des scripts. C’est également le cas de Redis qui propose à ses utilisateurs de télécharger et d’exécuter des scripts Lua sur le serveur afin d’étendre ses fonctionnalités. Jusque-là, l’infection des instances Redis par des acteurs malveillants et des botnets résultait principalement de l’exploitation de vulnérabilités ou d’erreurs de configuration dans Redis lui-même. Mais le ver P2PInfect exploite également dans la sandbox Lua une vulnérabilité critique, référencée CVE-2022-0543, qui affecte spécifiquement les paquets Redis sous Debian Linux. Selon les chercheurs de l’Unité 42, plus de 307 000 instances Redis sont actuellement accessibles sur Internet, mais seul un petit sous-ensemble d’environ 900 est vulnérable à cette faille. Reste que le ver va tenter de sonder et d’infecter toutes les instances publiques. « L’exploitation de la vulnérabilité CVE-2022-0543 rend P2PInfect efficace dans les environnements de conteneurs dans le cloud », ont déclaré les chercheurs. « Les conteneurs sont dotés d’un ensemble réduit de fonctionnalités. Par exemple, ils ne disposent pas de services ‘cron’. La plupart des vers les plus actifs qui exploitent Redis utilisent une technique RCE à l’aide des services cron. Ce procédé ne fonctionne pas dans les conteneurs. P2PInfect intègre l’exploit ciblant la vulnérabilité CVE-2022-0543 afin de couvrir le plus grand nombre possible de scénarios vulnérables, y compris les environnements de conteneurs dans le cloud ».
Dans une analyse distincte, des chercheurs de Cado Networks ont observé un vecteur d’infection différent. Ces derniers ont également vu que l’un de leurs serveurs pot de miel Redis avait été compromis par le ver P2Pinfect. Mais au lieu d’utiliser la vulnérabilité CVE-2022-0543 pour s’introduire, les attaquants ont exploité la fonction de réplication de Redis qui permet aux nœuds Redis de fonctionner en tant qu’esclaves d’un nœud maître désigné. Cette fonctionnalité peut être déclenchée à l’aide d’une commande appelée SLAVEOF qui transforme le nœud en réplique du nœud maître. Dans le passé, cette technique a été utilisée par plusieurs groupes d’attaquants contre des instances Redis exposées publiquement en se connectant à elles et en les rendant esclaves d’instances Redis compromises. L’avantage de cette méthode, c’est que les attaquants peuvent alors insérer un fichier d’objets partagés Linux dans leur mode maître qui sera répliqué sur les esclaves compromis et pourra ensuite être chargé en tant que module sur les esclaves avec la commande MODULE LOAD. Les modules sont destinés à étendre les fonctionnalités de Redis et, dans ce cas, les attaquants en ont conçu un avec lequel ils peuvent accéder au shell inversé et implémenter une commande appelée system.exec. Ils ont pu ainsi exécuter des commandes shell arbitraires sur les systèmes des victimes.
Un malware multi-plateformes et résistant
Une fois que le dropper principal de P2PInfect est déployé, il se connecte au réseau P2P et télécharge des informations sur le protocole de communication personnalisé, qui fonctionne sur TLS 1.3, ainsi qu’une liste des nœuds actifs dans le réseau. Il met également à jour le réseau avec ses propres informations et choisit un port de communication aléatoire. Le fait que le ver utilise un protocole de commande et de contrôle point à point et des numéros de port aléatoires pour chaque nœud le rend résistant aux tentatives de débranchage (takedown), car il n’y a pas de point de défaillance central. Ses communications sont aussi plus difficiles à bloquer par des pare-feux, parce qu’il n’y a pas de port spécifique pour arrêter son trafic. Le ver est écrit en Rust, un langage de programmation moderne multi-plateformes, connu pour la sécurité de sa mémoire et de ses types, ce qui l’a rendu populaire dans les grandes entreprises. Les chercheurs ont pu observer le dropper P2PInfect en train d’infecter des instances Redis sous Linux et Windows et de déployer des charges utiles supplémentaires écrites en Rust. Certaines d’entre elles sont nommées linux, miner, winminer et windows.
Sur les systèmes Windows, les chercheurs de Palo Alto ont également constaté le déploiement d’un autre composant appelé Monitor, qui active la persistance et s’assure que le ver est en cours d’exécution. Après avoir déployé ses composants supplémentaires, le ver commence immédiatement à rechercher des instances Redis vulnérables, mais il recherche également dans des plages aléatoires d’adresses IP le port 22, normalement associé à SSH. La raison pour laquelle ce port est scanné n’est pas claire, car les chercheurs n’ont trouvé aucune preuve que le bot tente d’exploiter ou de se connecter à d’autres systèmes via SSH, du moins pas encore. « Nous recommandons aux entreprises de surveiller toutes les applications Redis, à la fois sur site et dans les environnements cloud, pour s’assurer qu’elles ne contiennent pas de noms de fichiers aléatoires dans le répertoire /tmp », ont déclaré les chercheurs. « En outre, le personnel DevOps devrait continuellement surveiller leurs instances Redis pour s’assurer qu’elles maintiennent des opérations légitimes et qu’elles conservent l’accès au réseau. Toutes les instances Redis doivent aussi être mises à jour vers leur dernière version ou toute version postérieure à redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 et redis/5:7.0~rc2-2 ».
P2PInfect est le dernier-né d’une série de botnets à propagation automatique qui ciblent les technologies cloud et de conteneurs. Les chercheurs d’Aqua Security ont récemment documenté un autre ver, baptisé Silentbob, qui cible les clusters Kubernetes, les API Docker, les instances Weave Scope, les déploiements JupyterLab et Jupyter Notebook, les serveurs Redis et les clusters Hadoop.
Des chercheurs ont découvert une attaque via des malwares fileless en Python sur des charges de travail cloud. Pouvant échapper ainsi à la surveillance des outils de sécurité, elle met en place un mineur pour du cryptojacking.
Avec le déploiement croissant de solutions de sécurité sur les infrastructures cloud, les pirates ont commencé à adopter des tactiques innovantes pour cibler ces environnements. L’une d’elles consiste à utiliser des charges utiles fileless qui ne créent jamais de fichiers sur le disque et sont chargées directement dans la mémoire du système. Une technique capable d’échapper à la surveillance des outils de sécurité.
« Nous avons récemment détecté une attaque fileless ciblant des workload dans le cloud », ont déclaré dans leur rapport des chercheurs de Wiz, une entreprise spécialisée dans la sécurité du cloud. « L’attaque s’appuie sur un code Python qui charge un mineur XMRig directement dans la mémoire à l’aide de memfd, une technique sans fichier connue de Linux. À notre connaissance, c’est la première attaque fileless basée sur Python documentée publiquement et ciblant des charges de travail dans le cloud, et d’après nos preuves, cette attaque a été utilisée dans près de 200 cas pour le cryptominage », ont-ils ajouté.
Le malware PyLoose
En se basant sur les chaînes de caractères de l’URL à partir de laquelle les attaquants l’ont déployée, les experts ont baptisé cette charge utile du malware PyLoose. Elle a été trouvée sur des instances non protégées de Jupyter Notebook, une plateforme interactive basée sur le web qui peut être déployée sur des serveurs cloud et qui prend en charge plus de 40 langages de programmation, dont Python. Outre qu’elles sont accessibles au public, ces instances ne limitaient pas l’accès à certains modules Python comme os et subprocess, lesquels peuvent entraîner l’exécution de commandes système. Les attaquants ont utilisé le code Python pour télécharger et exécuter un script créé à l’aide d’un outil open source appelé fileless-elf-exec. Le script a importé des bibliothèques pour l’invocation directe de syscall, l’exécution de commandes os, les opérations base64 et la décompression zlib. Il a ensuite procédé au décodage et à la décompression d’une charge utile et a utilisé memfd pour créer une mémoire tampon, y écrire le contenu de la charge utile et l’invoquer directement depuis la mémoire.
La fonctionnalité memfd de Linux – abréviation de « memory file descriptors » (descripteurs de fichiers en mémoire) – stocke des objets de fichiers en mémoire pour les utiliser dans la communication inter-processus ou comme stockage temporaire. « Les cybercriminels abusent parfois de cette fonction de Linux pour exécuter des charges utiles sans les écrire sur le disque, et éviter ainsi les outils de sécurité traditionnels qui reposent sur des scans binaires », ont déclaré les chercheurs de Wiz. « Une fois que le payload est placé dans une section de mémoire créée par memfd, les attaquants peuvent invoquer l’un des syscalls exec sur ce contenu de mémoire, en le traitant comme s’il s’agissait d’un fichier normal sur le disque, et lancer ainsi un nouveau processus ». S’ils sont recherchés, les processus créés à partir de contenus memfd peuvent être assez facilement identifiés car les liens symboliques vers lesquels ils pointent ne sont pas des chemins de fichiers sur le disque, mais des entrées du type /memfd. Dans le cas présent, la charge utile exécutée à partir de la mémoire était une version précompilée de XMRig, un programme open-source pour le minage de crypto-monnaie couramment utilisé dans les attaques de cryptojacking qui consistent à détourner les ressources informatiques pour miner de la crypto-monnaie à l’insu du propriétaire.
Les attaques fileless sur Linux, plutôt rares
Les attaques sans fichier sur les serveurs Linux ne sont pas nouvelles, mais elles sont relativement rares pour les workload dans le cloud. L’avantage pour les attaquants est qu’elles sont plus difficiles à détecter sans solutions de sécurité basées sur le comportement et la surveillance de la mémoire. Ces attaques compliquent, par ailleurs, les enquêtes post-mortem après la compromission, car les charges utiles disparaissent de la mémoire quand les workload s’arrêtent et que les équipes de sécurité ne sont pas encore familiarisées avec ces techniques. L’un des rares cas documentés d’attaques sans fichier contre des serveurs Linux date de 2021 : un groupe de pirates connu sous le nom de TeamTNT avait déployé un malware écrit en langage Go en exploitant un outil de chargement de mémoire appelé Ezuri.
Avec PyLoose, « l’attaquant s’est donné beaucoup de mal pour se rendre intraçable : il a utilisé un service de partage de données ouvert pour héberger la charge utile Python, il a adapté la technique d’exécution sans fichier à Python et il a compilé un mineur XMRig pour intégrer sa configuration afin d’éviter de toucher le disque ou d’utiliser une ligne de commande pouvant révéler sa présence », ont déclaré les chercheurs de Wiz. « Toutes ces étapes suggèrent que l’adversaire dispose d’un niveau de sophistication rarement observé dans la plupart des attaques de charges de travail dans le cloud, documentées publiquement ». Les chercheurs conseillent aux entreprises d’éviter d’exposer publiquement des services comme Jupyter Notebook, d’utiliser l’authentification multifactorielle ou d’autres plateformes d’identité forte pour accéder à ces services, et de restreindre les fonctionnalités pouvant conduire à l’exécution de commandes système.
Une faille de sécurité frappant le registre npm compromet la fiabilité des paquets et ouvre la voie à l’exécution de scripts malveillants et à de la dissimulation de malwares dans les dépendances. Des attaques dites de confusion de fichiers manifest.
Utilisé pour automatiser l’installation, la mise à niveau et la configuration des paquets, le gestionnaire npm est à risque. Ce dernier présente en effet un bogue de conception que les attaquants pourraient exploiter pour dissimuler des dépendances et des scripts malveillants à l’intérieur de ses paquets. Le problème, appelé « confusion de manifest », provient du manque de cohérence entre les fichiers manifest qui accompagnent les paquets archivés et le fichier de métadonnées json inclus dans le paquet lui-même. Le bug a été révélé publiquement cette semaine par Darcy Clarke, un ancien responsable de l’ingénierie de l’équipe npm CLI. Ce dernier a quitté GitHub – qui possède npm – en décembre 2022 mais a déclaré que la société était au courant de ce problème depuis novembre dernier, et qu’il l’a notifié à nouveau en mars 2023. Après une recherche indépendante, il est arrivé à la conclusion que l’impact était plus important que ce que l’on pensait à l’origine.
Selon Darcy Clarke, la communauté part généralement du principe que les manifests publiés avec un paquet sur le registre npm correspondent au contenu du fichier de métadonnées package.json inclus dans le paquet lui-même, l’archive tarball téléchargée à partir du dépôt. Ce n’est pas le cas et les gestionnaires de paquets JavaScript côté client tels que npm – mais aussi les outils de sécurité qui analysent les paquets à partir des dépôts npm – ne valident pas correctement ces fichiers les uns par rapport aux autres. Cela signifie que les paquets peuvent avoir des dépendances cachées ou des scripts d’installation listés dans leurs fichiers package.json mais pas dans le fichier manifest séparé. Ces dépendances et ces scripts seront analysés et exécutés par des clients JavaScript tels que l’interface de ligne de commande (CLI) npm et d’autres, même s’ils ne sont pas répertoriés dans le manifest du paquet. « Il y a plusieurs façons dont ce bogue a un impact sur les consommateurs/utilisateurs finaux : Empoisonnement du cache (c’est-à-dire que le paquet sauvegardé peut ne pas correspondre au nom et à la spécification de version de ce paquet dans le registre/URI), installation de dépendances inconnues/non listées (tromper les outils de sécurité/audit) ; exécution de scripts inconnus/non listés (tromper les outils de sécurité/audit) ; attaque potentielle par rétrogradation (où la spécification de version sauvegardée dans les projets correspond à une version vulnérable non spécifiée du paquet) », a déclaré M. Clarke.
Une validation dans les mains des installateurs de paquets
À la base, ce problème est dû au fait qu’il n’existe pas de « source canonique de vérité » claire pour les métadonnées d’un paquet, comme le nom, la version, les dépendances, les scripts, la licence, etc. Ces éléments sont spécifiés dans le fichier package.json qui est inclus dans l’archive du paquet elle-même et qui prend en charge les valeurs de vérification de l’intégrité telles que les hachages cryptographiques. Cependant, certaines de ces données peuvent être spécifiées dans le fichier manifest du paquet lors de sa publication sur le registre npm et ce manifeste dicte les informations que le registre affichera. Par exemple, Darcy Clarke a créé un exemple de paquet dont le fichier package.json mentionne un autre paquet comme dépendance, mais lorsqu’il l’a publié, il n’a pas inclus la dépendance dans le manifest. En conséquence, l’entrée du paquet sur le référentiel npm.js liste le paquet avec 0 dépendance, parce que le registre utilise le manifest comme source unique de vérité.
Cependant, le registre lui-même ne valide pas que les informations du package.json qui correspondent à celles du manifest. Cette tâche est laissée au client qui installe le paquet. Mais il s’avère qu’ils n’effectuent pas vraiment cette validation non plus… Par exemple, la version 6 de npm (npm@6), livrée avec la version 14 du moteur d’exécution node.js (support à long terme), exécutera un script d’installation défini dans le fichier package.json même si le script n’est pas défini dans le manifest. Une dépendance listée dans package.json et absente du manifest ne sera ainsi pas déployée lors du première téléchargement et de la première installation de paquet. Toutefois, si celui-ci est mis en cache localement et installé ultérieurement à partir de la source locale avec les options de ligne de commande -prefer-offline et -no-package-lock, les dépendances cachées du fichier package.json seront installées. Npm version 9 (npm@9), la version stable actuelle de npm, installera de la même manière les dépendances référencées dans le package.json d’un paquet mis en cache lors de l’utilisation de la configuration -offline.
Yarn et pnpm aussi vulnérables
Les gestionnaires de paquets yarn et pnpm, qui sont des alternatives à npm, sont également vulnérables et exécuteront les scripts référencés dans le fichier package.json qui sont absents du manifest. Yarn préférera également la version du paquet définie dans package.json à celle-ci. Comme ces deux valeurs peuvent être différentes, cela ouvre la porte à une attaque par rétrogradation. Ces dernières sont dangereuses, car un paquet peut être remplacé par une version plus ancienne qui présente une vulnérabilité connue. Ces itérations présentant des failles ne manquent pas, même dans les projets activement maintenus. La semaine dernière, des chercheurs de Snyk et de Redhunt Labs ont publié les résultats d’un projet de recherche qui a consisté à analyser plus de 11 000 dépôts appartenant aux 1 000 premières entreprises sur GitHub. L’analyse a cherché des failles dans les dépendances listées dans ces projets couvrant plusieurs langages de programmation. Pour JavaScript (npm et yarn), l’équipe a extrait 1,9 million de dépendances et identifié environ 550 000 cas de trous de sécurité connus.
Darcy Clarke pense que ce problème relève de différentes catégories de failles. Il note qu’ « il y a une histoire qui repose fortement sur le client (aka le CLI de npm) pour faire le travail qui devrait être fait côté serveur ». Outre ces gestionnaires de paquets côté client, le problème touche également d’autres outils et registres de paquets tiers, y compris ceux axés sur la sécurité : Snyk, le miroir chinois NPM, le miroir CloudFlare npm CDN, le miroir UNPKG CDN, Skypack, JSPM, et même les dépôts locaux créés avec Artifactory de jFrog.
Pas de solution facile pour remédier à la vulnérabilité liée à la confusion des manifest
La résolution de ce problème et l’application soudaine de la validation n’est pas simple et pourrait prendre un certain temps jusqu’à ce que GitHub trouve une solution. Car il y a probablement de nombreux paquets qui présentent cette confusion, et ce n’est pas pour des raisons malveillantes. Darcy Clarke a noté que l’interface de programmation de npm elle-même provoque également de telles incohérences. Par exemple, lors de la publication d’un paquet via l’interface de commande npm où un fichier binding.gyp est situé à l’intérieur du projet, le client ajoutera une entrée au fichier manifest appelé : « node-gyp rebuild » scripts.install. Cette entrée ne sera pas présente dans le fichier package.json. « GitHub est logiquement dans une situation difficile », a déclaré le responsable. « Le fait que npmjs.com fonctionne de cette manière depuis plus de dix ans signifie que l’état actuel est assez codifié et susceptible de percer une défense de manière unique. Comme mentionné précédemment, l’interface de programmation npm elle-même repose sur ce comportement et il existe potentiellement d’autres utilisations non malveillantes dans la nature de ce comportement aujourd’hui ».
Les utilisateurs devraient contacter tous les auteurs connus d’outils qui s’appuient sur npm et leur demander de s’appuyer sur les informations du package.json plutôt que sur le manifest, à l’exception de la version et du nom qui peuvent être différents pour des raisons légitimes. Une autre option serait d’utiliser un proxy entre le client et le registre qui valide strictement les métadonnées des deux sources pour assurer la cohérence.
Un pirate a créé de faux comptes Twitter et Github vue d’attirer de vrais chercheurs en sécurité. Des dépôts de code compromis ont également servi aux pirates dans leur opération malveillante.
Dans cette campagne d’attaque inhabituelle, le pirate a mis en place des référentiels GitHub frauduleux hébergeant de faux exploits de type zero day pour des applications populaires, mais qui, en réalité, contiennent des logiciels malveillants. Le pirate a également créé de faux comptes GitHub et Twitter de chercheurs en sécurité et a même utilisé de vraies photos de chercheurs travaillant pour des entreprises de cybersécurité bien connues. « L’attaquant a fait beaucoup d’efforts pour créer tous ces faux profils, uniquement pour livrer des logiciels malveillants très évidents », ont déclaré dans un rapport les chercheurs de l’entreprise de sécurité VulnCheck, à l’origine de la découverte des référentiels malveillants. « On ne sait pas si leurs manœuvres ont porté leurs fruits, mais ils poursuivent leur stratégie d’attaque, semblant croire à un succès possible.
Si les attaques visant les chercheurs en sécurité ne sont pas nouvelles, elles sont relativement rares et davantage le fait de groupes de menaces persistantes avancées (Advanced Persistent Threat, APT) qui cherchent à accéder à des informations sensibles auxquelles ont accès les chercheurs. C’est ce qui s’est passé dans la campagne signalée par le Threat Analysis Group de Google en 2021, au cours de laquelle une entité nord-coréenne soutenue par le gouvernement avait créé un réseau de faux comptes de personnes qui se faisaient passer pour des chercheurs en sécurité sur Twitter, Telegram, LinkedIn et d’autres plateformes de médias sociaux, et qu’elle avait utilisé pour promouvoir des exploits « proof-of- concept » pour des vulnérabilités existantes, publiés sur un blog et dans des vidéos sur YouTube.
Une campagne de faux comptes GitHub
Les faux comptes ont été utilisés pour contacter de vrais chercheurs et les inviter à collaborer. Dans le cadre de cette campagne, un projet Visual Studio contenant le code d’un exploit « proof-of-concept » a été partagé, mais ce projet comprenait également une DLL malveillante qui déployait des logiciels malveillants sur l’ordinateur de la victime. Par ailleurs, certains chercheurs ayant visité le blog ont vu leurs systèmes à jour exploités, ce qui suggère que les attaquants avaient accès à des exploits de type « zero-day ». Le premier référentiel frauduleux a été découvert au début du mois de mai par VulnCheck qui l’a signalé à GitHub, qui l’a supprimé rapidement. Ce dépôt prétendait héberger un exploit d’exécution de code à distance de type « zero day » pour Signal, une application de communication sécurisée très populaire et très appréciée dans la communauté de la sécurité. L’attaquant a continué à créer de nouveaux comptes et référentiels avec de faux exploits pour Microsoft Exchange, Google Chrome, Discord et Chromium. Tous ont été créés par de faux comptes prétendant appartenir à des chercheurs travaillant pour une entreprise appelée High Sierra Cyber Security, qui ne semble pas exister.
Certains noms et informations de profil ont été réutilisés pour créer des comptes Twitter qui ont ensuite servi à promouvoir les dépôts, comme dans l’attaque signalée par Google. Cependant, il semble que l’attaque de 2021 était beaucoup plus sophistiquée que cette dernière campagne et rien ne prouve qu’elle soit l’œuvre des mêmes attaquants. Le code malveillant distribué à partir des dépôts GitHub compromis sous la forme d’un fichier appelé poc.py télécharge l’un de ces deux fichiers supplémentaires en fonction du système d’exploitation, l’un appelé cveslinux.zip et l’autre appelé cveswindows.zip. Ces fichiers d’archive sont ensuite décompressés et le fichier qu’ils contiennent est exécuté. La charge utile Windows est détectée par 36 programmes antivirus sur VirusTotal comme un Trojan, tandis que le binaire Linux est signalé par 25.
Une vigilance de tous les instants à avoir
« On ne sait pas si la campagne a été initiée par une personne seule qui a du temps à perdre ou si c’est une action plus avancée comme celle découverte par Google TAG en janvier 2021 », ont déclaré les chercheurs de VulnCheck. « Quoi qu’il en soit, les chercheurs en sécurité doivent comprendre qu’ils sont des cibles utiles pour les acteurs malveillants et doivent être prudents quand ils téléchargent du code à partir de GitHub. Ils doivent toujours examiner le code qu’ils exécutent et ne jamais utiliser un code qu’ils ne comprennent pas », ont-ils ajouté. Généralement, les spécialistes expérimentés prennent des précautions quand ils travaillent avec du code potentiellement malveillant. Pour tester un exploit « proof-of-concept », ils utilisent un système de test à l’intérieur d’une machine virtuelle bien surveillée et supprimée ensuite. Dans la plupart des entreprises, l’exécution d’un tel code sur une machine de travail constituerait très probablement une violation des politiques de sécurité standard, d’autant plus s’il s’agit d’une entreprise de cybersécurité.
Une étude menée par des chercheurs en sécurité d’Eclypsium montre que des attaquants sont en mesure de compromettre le micrologiciel UEFI de cartes mères Gigabyte pour injecter un code malveillant exécutable dans le noyau Windows.
Mauvaise nouvelle pour Gigabyte. Après le ransomware RobinHood en 2020 et plus récemment le rootkit ComicStrand en juillet 2022, des chercheurs en sécurité avertissent que le micrologiciel UEFI (ex BIOS) de plusieurs centaines de modèles de cartes mères du fournisseur informatique peut être exploité pour injecter du code exécutable dans le noyau Windows. « Bien que notre enquête en cours n’ait pas confirmé l’exploitation par un acteur de menace spécifique, une porte dérobée active et répandue, difficile à supprimer, pose un risque pour les entreprises possédant des systèmes Gigabyte », ont déclaré les chercheurs de la société de sécurité Eclypsium dans un rapport.
Les chercheurs d’Eclypsium ont découvert cette brèche après des alertes émises par sa plateforme sur un comportement qui semblait cohérent avec un rootkit BIOS/UEFI. Ces rootkits, également connus sous le nom de bootkits, sont très dangereux et difficiles à supprimer car ils résident dans le micrologiciel de bas niveau du système et injectent du code dans le système d’exploitation à chaque démarrage. Cela signifie que la réinstallation du système d’exploitation ou même le changement de disque dur ne supprimerait pas l’infection et qu’elle réapparaîtrait. UEFI est un mini-OS en soi, composé de différents modules qui gèrent l’initialisation du matériel avant de transmettre la séquence de démarrage au chargeur de boot et au système d’exploitation installé. Le processus d’injection du code du micrologiciel dans la mémoire du système d’exploitation a déjà été utilisé pour la mise en œuvre de diverses fonctionnalités. Par exemple, certains BIOS sont dotés d’une fonction antivol appelée Absolute LoJack, anciennement connue sous le nom de Computrace, qui permet aux utilisateurs de suivre et d’effacer leur ordinateur à distance en cas de vol. Cette fonction est mise en œuvre par un agent du BIOS qui injecte une application dans le système d’exploitation, même s’il est réinstallé.
Des connexions non sécurisées au serveur de téléchargement
Selon les chercheurs, des groupes APT sophistiqués exploitent des implémentations similaires activement. Les chercheurs en sécurité ont déjà averti depuis 2014 que l’agent LoJack Windows par exemple pouvait être utilisé de manière abusive et connecté à un malware. Puis, en 2018, les chercheurs ont découvert que la technologie était utilisée de manière abusive par APT28, alias Fancy Bear, une division de piratage du service de renseignement militaire russe. Le cas est similaire avec le module firmware de Gigabyte, qui injecte un exécutable Windows dans la table ACPI WPBT lors du démarrage du système, d’où il est automatiquement exécuté par le Windows Session Manager Subsystem (smss.exe) et écrit un fichier dans le dossier Windows system32 appelé GigabyteUpdateService.exe. L’objectif dans ce cas est que le BIOS déploie automatiquement une application de mise à jour du système et des pilotes Gigabyte lorsque la fonction du BIOS appelée APP Center Download & Install est activée.
L’application de mise à jour de Gigabyte recherche automatiquement les mises à jour à télécharger et à exécuter en vérifiant trois URL. L’une d’entre elles est un serveur de téléchargement Gigabyte via HTTPS, une autre est le même serveur mais la connexion utilise un simple HTTP, et la troisième est une URL vers un domaine non qualifié appelé software-nas qui peut être un appareil sur le réseau local. Deux des trois méthodes de téléchargement de fichiers sont très problématiques. Les connexions HTTP non chiffrées sont vulnérables aux attaques de type man-in-the-middle. Un attaquant se trouvant sur le même réseau ou contrôlant un routeur sur le réseau peut diriger le système vers un serveur sous son contrôle et l’application n’aurait aucun moyen de savoir qu’elle ne parle pas avec le vrai serveur de Gigabyte. La troisième URL est tout aussi problématique et encore plus facile à abuser, car un attaquant sur le même réseau, sur un système compromis, pourrait déployer un serveur web et définir le nom de l’ordinateur sur software-nas sans même avoir recours à l’usurpation de DNS ou à d’autres techniques. Enfin, même la connexion HTTPS est vulnérable au man-in-the-middle car l’application de mise à jour n’implémente pas correctement la validation du certificat du serveur, ce qui signifie que les attaquants peuvent toujours usurper le serveur.
Une solution de contournement proposée
Un autre problème est que même si les outils et les mises à jour de Gigabyte sont signés numériquement avec une signature valide, le micrologiciel n’effectue aucune vérification ou validation de cette marque sur les exécutables, de sorte que les attaquants pourraient facilement abuser de la fonctionnalité. « Le rythme de découverte de nouveaux rootkits UEFI s’est fortement accéléré ces dernières années, comme en témoigne la découverte de LoJax (2018), MosaicRegressor (2020), FinSpy (2021), ESPecter (2021), MoonBounce (2022), CosmicStrand (2022) et BlackLotus (2023) », expliquent les chercheurs d’Eclypsium. « La plupart d’entre eux ont été utilisés pour permettre la persistance d’autres logiciels malveillants basés sur le système d’exploitation. Les images du micrologiciel de Gigabyte et l’exécutable Windows persistant permettent le même scénario d’attaque. Souvent, les implants susmentionnés font passer leurs exécutables Windows natifs pour des outils de mise à jour légitimes. Dans le cas de MosaicRegressor, la charge utile Windows était nommée IntelUpdater.exe ».
Les chercheurs conseillent aux entreprises équipées de systèmes Gigabyte de désactiver la fonction de téléchargement et d’installation de l’APP Center dans l’UEFI et de bloquer les trois URL à risque dans les parefeux. Les organisations peuvent également rechercher les tentatives de connexion à ces URL afin de détecter les systèmes susceptibles d’être affectés sur leurs réseaux, mais elles devraient plus généralement rechercher les connexions qui pourraient provenir de fonctions similaires d’autres fabricants. Même si elles ne sont pas déployées dans les microprogrammes, les applications préinstallées par les fabricants de PC sur les ordinateurs peuvent également présenter des vulnérabilités. C’est ce qui s’est passé avec une application Lenovo appelée Superfish, qui a déployé un certificat racine non fiable pouvant être utilisé de manière abusive par des attaquants.
Une étude menée par des chercheurs en sécurité d’Eclypsium montre que des attaquants sont en mesure de compromettre le micrologiciel UEFI de cartes mères Gigabyte pour injecter un code malveillant exécutable dans le noyau Windows.
Mauvaise nouvelle pour Gigabyte. Après le ransomware RobinHood en 2020 et plus récemment le rootkit ComicStrand en juillet 2022, des chercheurs en sécurité avertissent que le micrologiciel UEFI (ex BIOS) de plusieurs centaines de modèles de cartes mères du fournisseur informatique peut être exploité pour injecter du code exécutable dans le noyau Windows. « Bien que notre enquête en cours n’ait pas confirmé l’exploitation par un acteur de menace spécifique, une porte dérobée active et répandue, difficile à supprimer, pose un risque pour les entreprises possédant des systèmes Gigabyte », ont déclaré les chercheurs de la société de sécurité Eclypsium dans un rapport.
Les chercheurs d’Eclypsium ont découvert cette brèche après des alertes émises par sa plateforme sur un comportement qui semblait cohérent avec un rootkit BIOS/UEFI. Ces rootkits, également connus sous le nom de bootkits, sont très dangereux et difficiles à supprimer car ils résident dans le micrologiciel de bas niveau du système et injectent du code dans le système d’exploitation à chaque démarrage. Cela signifie que la réinstallation du système d’exploitation ou même le changement de disque dur ne supprimerait pas l’infection et qu’elle réapparaîtrait. UEFI est un mini-OS en soi, composé de différents modules qui gèrent l’initialisation du matériel avant de transmettre la séquence de démarrage au chargeur de boot et au système d’exploitation installé. Le processus d’injection du code du micrologiciel dans la mémoire du système d’exploitation a déjà été utilisé pour la mise en œuvre de diverses fonctionnalités. Par exemple, certains BIOS sont dotés d’une fonction antivol appelée Absolute LoJack, anciennement connue sous le nom de Computrace, qui permet aux utilisateurs de suivre et d’effacer leur ordinateur à distance en cas de vol. Cette fonction est mise en œuvre par un agent du BIOS qui injecte une application dans le système d’exploitation, même s’il est réinstallé.
Des connexions non sécurisées au serveur de téléchargement
Selon les chercheurs, des groupes APT sophistiqués exploitent des implémentations similaires activement. Les chercheurs en sécurité ont déjà averti depuis 2014 que l’agent LoJack Windows par exemple pouvait être utilisé de manière abusive et connecté à un malware. Puis, en 2018, les chercheurs ont découvert que la technologie était utilisée de manière abusive par APT28, alias Fancy Bear, une division de piratage du service de renseignement militaire russe. Le cas est similaire avec le module firmware de Gigabyte, qui injecte un exécutable Windows dans la table ACPI WPBT lors du démarrage du système, d’où il est automatiquement exécuté par le Windows Session Manager Subsystem (smss.exe) et écrit un fichier dans le dossier Windows system32 appelé GigabyteUpdateService.exe. L’objectif dans ce cas est que le BIOS déploie automatiquement une application de mise à jour du système et des pilotes Gigabyte lorsque la fonction du BIOS appelée APP Center Download & Install est activée.
L’application de mise à jour de Gigabyte recherche automatiquement les mises à jour à télécharger et à exécuter en vérifiant trois URL. L’une d’entre elles est un serveur de téléchargement Gigabyte via HTTPS, une autre est le même serveur mais la connexion utilise un simple HTTP, et la troisième est une URL vers un domaine non qualifié appelé software-nas qui peut être un appareil sur le réseau local. Deux des trois méthodes de téléchargement de fichiers sont très problématiques. Les connexions HTTP non chiffrées sont vulnérables aux attaques de type man-in-the-middle. Un attaquant se trouvant sur le même réseau ou contrôlant un routeur sur le réseau peut diriger le système vers un serveur sous son contrôle et l’application n’aurait aucun moyen de savoir qu’elle ne parle pas avec le vrai serveur de Gigabyte. La troisième URL est tout aussi problématique et encore plus facile à abuser, car un attaquant sur le même réseau, sur un système compromis, pourrait déployer un serveur web et définir le nom de l’ordinateur sur software-nas sans même avoir recours à l’usurpation de DNS ou à d’autres techniques. Enfin, même la connexion HTTPS est vulnérable au man-in-the-middle car l’application de mise à jour n’implémente pas correctement la validation du certificat du serveur, ce qui signifie que les attaquants peuvent toujours usurper le serveur.
Une solution de contournement proposée
Un autre problème est que même si les outils et les mises à jour de Gigabyte sont signés numériquement avec une signature valide, le micrologiciel n’effectue aucune vérification ou validation de cette marque sur les exécutables, de sorte que les attaquants pourraient facilement abuser de la fonctionnalité. « Le rythme de découverte de nouveaux rootkits UEFI s’est fortement accéléré ces dernières années, comme en témoigne la découverte de LoJax (2018), MosaicRegressor (2020), FinSpy (2021), ESPecter (2021), MoonBounce (2022), CosmicStrand (2022) et BlackLotus (2023) », expliquent les chercheurs d’Eclypsium. « La plupart d’entre eux ont été utilisés pour permettre la persistance d’autres logiciels malveillants basés sur le système d’exploitation. Les images du micrologiciel de Gigabyte et l’exécutable Windows persistant permettent le même scénario d’attaque. Souvent, les implants susmentionnés font passer leurs exécutables Windows natifs pour des outils de mise à jour légitimes. Dans le cas de MosaicRegressor, la charge utile Windows était nommée IntelUpdater.exe ».
Les chercheurs conseillent aux entreprises équipées de systèmes Gigabyte de désactiver la fonction de téléchargement et d’installation de l’APP Center dans l’UEFI et de bloquer les trois URL à risque dans les parefeux. Les organisations peuvent également rechercher les tentatives de connexion à ces URL afin de détecter les systèmes susceptibles d’être affectés sur leurs réseaux, mais elles devraient plus généralement rechercher les connexions qui pourraient provenir de fonctions similaires d’autres fabricants. Même si elles ne sont pas déployées dans les microprogrammes, les applications préinstallées par les fabricants de PC sur les ordinateurs peuvent également présenter des vulnérabilités. C’est ce qui s’est passé avec une application Lenovo appelée Superfish, qui a déployé un certificat racine non fiable pouvant être utilisé de manière abusive par des attaquants.