Une vulnérabilité critique a été découverte dans les versions datacenter et server de Confluence d’Atlassian. Elle peut aboutir à l’exécution de code à distance. Un correctif a été appliqué via une mise à jour.
Atlassian a publié récemment un avis de sécurité concernant son produit Confluence pour datacenter et server. La plateforme collaborative est en effet touchée par une faille critique entraînant l’exécution de code à distance (RCE). Référencée comme CVE-2024-21683 et affectée d’un score CVSS de 8.3/10, la vulnérabilité ne nécessite aucune interaction de la part de l’utilisateur, avec un impact élevé sur la confidentialité, l’intégrité et la disponibilité du service de configuration
« Cette vulnérabilité RCE (Remote Code Execution) de haute gravité a été introduite dans la version 5.2 de Confluence Data Center et Confluence Server », peut-on lire dans l’alerte. « Atlassian recommande aux clients de Confluence Data Center et de Confluence Server d’effectuer une mise à jour vers la dernière version ». La vulnérabilité a été corrigée par le fournisseur dans les dernières versions du logiciel.
Défaut de validation des entrées
La brèche a été découverte par les équipes de SonicWall qui ont publié les résultats de leurs travaux. Elle provient du mécanisme de validation des entrées dans la fonction « Add a new language » de la section « Configure Code Macro ». « Cette fonction est utilisée pour télécharger une nouvelle définition de langage macro de bloc de code pour personnaliser le formatage et la mise en évidence de la syntaxe », explique le rapport. Il ajoute, « elle s’attend à ce que le fichier Javascript soit formaté conformément à la syntaxe Custom Brush. Un attaquant authentifié peut profiter de cette validation insuffisante pour injecter un code Java malveillant intégré dans un fichier, qui sera exécuté sur le serveur ».
Ainsi, pour que le cybercriminel puisse exploiter la faille, il doit gagner l’accès au réseau vulnérable, avoir le privilège d’ajouter d’autres langages macro et télécharger le langage JavaScript falsifié dans Configure Code Macro. La recherche de SonicWall fait également référence à une exploitation de la vulnérabilité dans le cadre d’une preuve de concept (PoC).
Mises à jour avec correctif
La faille affecte les versions 5.2, 7.19.0, 7.20.0, 8.0.0, 8.1.0, 8.2.0, 8.3.0, 8.4.0, 8.5.0, 8.6.0, 8.8.0, 8.7.1, 8.9.0 de Confluence Data Center et Server. Des correctifs pour le logiciel défectueux sont inclus dans les versions 8.9.1, 8.5.9, et 7.19.22, qui corrigent toutes les versions affectées. « Atlassian recommande aux clients de Confluence Server d’effectuer une mise à jour vers la dernière version », indique l’éditeur dans son avis. « Si vous n’êtes pas en mesure de le faire, mettez votre instance à niveau vers l’une des versions corrigées prises en charge spécifiées » ajoute-t-il. Par ailleurs, SonicWall a fourni deux signatures de prévention des intrusions (Intrusion Prevention Signatures, IPS) pour que les clients empêchent toute exploitation de la vulnérabilité. « Compte tenu du rôle central de Confluence Server dans la maintenance de la base de connaissances d’une entreprise, les utilisateurs sont fortement encouragés à mettre à jour leurs instances vers les dernières versions, comme indiqué dans l’avis du fournisseur », a ajouté le fournisseur de sécurité.
Une vulnérabilité a été découverte dans l’application EmbedAI. Elle peut être exploitée pour tromper un utilisateur et lui faire télécharger à son insu des données incorrectes dans le LLM de l’application.
Avec l’engouement autour de l’IA, les spécialistes la cybersécurité se penchent sur le sujet pour détecter et dénicher des failles dans les différentes solutions proposées. C’est ce que vient de faire Synopsys qui a découvert une vulnérabilité d’empoisonnement des données dans l’application EmbedAI, spécialisée dans la création de chatbot via ChatGPT et Gemini. « Cette faille pourrait compromettre l’application et entraîner des entrées non autorisées ou des attaques par empoisonnement de données », a déclaré Synopsys dans un blog. « L’exploitation de cette vulnérabilité peut perturber le fonctionnement immédiat du modèle et avoir des effets durables sur sa fiabilité et la sécurité des systèmes qui en dépendent ». La CVE-2024-5185, dont le score CVSS est de 7,5/10, affecte la branche « principale » d’EmbedAI.
Une faille CSRF
Selon Synopsys, EmbedAI est confronté à une faille CSRF (cross-site request forgery), une vulnérabilité de sécurité web où les pirates incitent les utilisateurs finaux à exécuter des actions non désirées sur une application web dans laquelle ils sont actuellement authentifiés. « Ces attaques sont rendues possibles par une vulnérabilité CSRF (cross-site request forgery) résultant de l’absence d’implémentation de la gestion des sessions sécurisées et de politiques de partage de ressources inter-origines faibles », a expliqué l’éditeur.
Dans le contexte des LLM, le bug autorise des tentatives malveillantes pour inciter les utilisateurs victimes à télécharger des données empoisonnées dans leur modèle de langage. Les applications utilisant le composant EmbedAI peuvent ainsi être exposées à des fuites de données potentielles. En outre, la compromission des données peut nuire aux applications de l’utilisateur de bien d’autres façons, notamment en diffusant des informations erronées, en introduisant des biais, en dégradant les performances et en risquant de provoquer des attaques par déni de service.
L’isolation des applications peut aider
Synopsys fait remarquer que la seule solution disponible pour remédier à ce problème est d’isoler les applications potentiellement affectées des réseaux intégrés. Dans son blog, le Cybersecurity Research Center (CyRC) de Synopsys « recommande de déconnecter immédiatement les applications des réseaux » en ajoutant qu’il a informé les développeurs au sujet de la vulnérabilité, mais qu’il n’a pas eu de réponse de leur part dans le délai de 90 jours imposé par sa politique de divulgation responsable. La vulnérabilité a été découverte par Mohammed Alshehri, chercheur en sécurité chez Synopsys. « Certains produits prennent une implémentation existante de l’IA et la fusionnent pour créer quelque chose de nouveau », a expliqué le chercheur lors d’un entretien avec DarkReeading.
« Ce que nous voulons souligner ici, c’est que même après l’intégration, les entreprises devraient tester pour s’assurer que les mêmes contrôles mis en place pour les applications Web sont également mis en œuvre sur les API pour leurs applications d’IA. » Le travail de recherche montre que l’intégration rapide de l’IA dans les opérations métiers comporte des risques, en particulier pour les entreprises qui accordent aux LLM et autres applications d’IA générative (GenAI) d’accéder à de vastes référentiels de données. Même si ce domaine est très nouveau, les fournisseurs de sécurité comme Dig Security, Securiti, Protect AI, eSentire, etc. se démènent déjà pour mettre en place une défense contre les menaces GenAI en constante évolution.
Le groupe Forest Blizzard a utilisé une faille affectant le service Print Spooler de Windows, désormais corrigée, pour déposer le malware d’élévation de privilèges, GooseEgg afin de voler des informations d’identification et persister.
Selon un rapport de Microsoft, depuis juin 2020, le groupe APT Forest Blizzard, affilié à la Russie, exploite une vulnérabilité Windows désormais corrigée pour diffuser un malware personnalisé nommé GooseEgg et inconnu jusqu’alors. Celui-ci a pour objectif d’obtenir une élévation de privilèges sur des systèmes cibles et voler des identifiants et des informations. « Même si l’on sait que des acteurs russes ont exploité un ensemble de vulnérabilités similaires connues sous le nom de PrintNightmare (CVE-2021-34527 et CVE-2021-1675), l’utilisation de GooseEgg dans les opérations de Forest Blizzard est une découverte qui n’avait pas été signalée auparavant par les fournisseurs de sécurité », a déclaré Microsoft dans son rapport.
GooseEgg utilisé pour l’élévation de privilèges
La vulnérabilité critique (CVSS 7.8/10) référencée CVE-2022-38028 qui permettait une élévation de privilèges dans le service Windows Print Spooler, a été corrigée en octobre 2022 par le Patch Tuesday. Windows Print Spooler est une application de l’OS qui stocke temporairement les travaux d’impression dans la mémoire de l’ordinateur jusqu’à ce que l’imprimante soit prête à les imprimer. Selon les observations de la firme de Redmond, une fois l’accès au système cible obtenu, Forest Blizzard utilise GooseEgg pour augmenter ses droits dans l’environnement. Généralement, le malware est déployé à l’aide d’un script batch, un ensemble de commandes stockées dans un fichier texte brut à exécuter par un interpréteur de ligne de commande Windows.
Le script batch invoque l’exécutable binaire malveillant GooseEgg, qui contient des commandes d’élévation de privilèges et de vol d’identifiants. « Même si GooseEgg est une simple application de lancement, elle est capable d’engendrer d’autres applications spécifiées dans la ligne de commande avec des autorisations élevées, ce qui offre aux groupes de mener des actions ultérieures, par exemple exécuter du code à distance, installer une porte dérobée et effectuer un déplacement latéral à travers des réseaux compromis », souligne Microsoft. Selon ce même rapport, Forest Blizzard a utilisé GooseEgg dans le cadre d’activités post-compromission contre diverses cibles gouvernementales en Ukraine, en Europe occidentale et en Amérique du Nord, mais aussi contre des ONG et des entités du secteur de l’éducation et des transports.
Des exploits, dès avril 2019
Également connu sous les noms de Fancy Bear, GRU Unit 26165, APT28, Sednit, Sofacy et STROTIUM, Forest Blizzard serait actif depuis 2010 et collecterait des renseignements à l’appui des initiatives de politique étrangère du gouvernement russe. Il a été lié à l’unité militaire 26165 du GRU, et si ses cibles étaient mondiales, son attention s’est majoritairement portée sur des entités américaines et européennes. « Forest Blizzard se concentre principalement sur des cibles stratégiques de renseignement et se distingue d’autres groupes affiliés et parrainés par le GRU, que Microsoft a liés à des attaques destructrices, comme Seashell Blizzard (IRIDIUM) et Cadet Blizzard (DEV-0586) », a déclaré l’entreprise.
Selon Microsoft Threat Intelligence, avec le déploiement de GooseEgg, Forest Blizzard cherche, au moins depuis juin 2020 et peut-être dès avril 2019, à accéder aux systèmes cibles et à voler des informations. Outre l’application des correctifs d’octobre 2022, Microsoft recommande aux utilisateurs de désactiver le service Windows Print Spooler pour les opérations des contrôleurs de domaine, d’exécuter l’EDR en mode bloqué, d’automatiser entièrement le mode d’investigation et de remédiation sur Microsoft Defender, et d’activer la protection cloud sur Defender Antivirus.
Plus de 300 000 systèmes Internet utilisant les protocoles UDP sont vulnérables à des attaques par déni de service en boucle. Un attaquant non authentifié peut utiliser des paquets malveillants contre une implémentation vulnérable basée sur DNS, NTP ou encore TFTP.
La technique tout juste découverte permet de lancer une attaque par déni de service en boucle entre deux applications réseau, bloquant indéfiniment l’accès légitime à leurs serveurs respectifs. Elle cible la couche application sur des systèmes utilisant le protocole UDP (User Datagram Protocol), un protocole vulnérable de la couche Transport Layer Security (TLS), qui, en raison de sa nature sans connexion, manque intrinsèquement de vérification des requêtes. « Les attaques DoS en boucle de la couche application reposent sur l’usurpation d’adresse IP et peuvent être déclenchées à partir d’un seul hôte capable d’usurper l’adresse IP », a déclaré le centre de recherche allemand sur la cybersécurité CISPA (Helmholtz Center for Information Security, CISPA) à l’origine de la découverte, dans un blog. « Ces attaques associent deux services réseau de telle sorte qu’ils continuent à répondre indéfiniment aux messages de l’un et de l’autre. La couche application est la couche conceptuelle la plus élevée d’un système de communication classique, qui comprend également, dans cet ordre, les couches physique, liaison de données, réseau, transport, session et présentation.
Un protocole plus rapide, mais moins sûr
Le protocole de couche de transport UDP est chargé de transporter des paquets de données sur des systèmes réseau qui communiquent à l’aide de protocoles de couche d’application. Spécifiquement conçu pour les transmissions sensibles au temps, comme la lecture de vidéos ou les recherches DNS, l’UDP fonctionne selon le principe de l’absence de connexion, c’est-à-dire qu’il peut transférer des données sans établir de connexion entre les systèmes concernés. La transmission plus rapide est parfois un compromis risqué, car la nature inhérente de l’UDP peut entraîner la perte de données en transit ou, dans ce cas, permettre à des attaquants de mener des attaques DDoS. La vulnérabilité inhérente à l’UDP est répertoriée sous la référence CVE-2024-2169. « Les implémentations du protocole d’application UDP sont vulnérables aux boucles de réseau », selon la base de données sur les vulnérabilités NVD (National Vulnerability Database) du NIST (National Institute of Standards and Technology). « Un attaquant non authentifié peut utiliser des paquets malveillants contre une implémentation vulnérable, ce qui peut entraîner un déni de service (DOS) et/ou une utilisation abusive des ressources ».
Les chercheurs du CISPA ont expliqué que la boucle d’attaque peut être initiée en envoyant un seul message d’erreur par usurpation d’adresse IP à l’un ou l’autre d’un couple de serveurs défectueux. « Les serveurs vulnérables continueraient alors à s’envoyer des messages d’erreur, ce qui mettrait à rude épreuve les deux serveurs et toute liaison réseau entre eux », ont écrit les chercheurs dans leur blog. « Une fois qu’un déclencheur est injecté et que la boucle est enclenchée, même les attaquants sont incapables d’arrêter l’attaque », selon le blog. La vulnérabilité affecte d’anciens protocoles comme Daytime, Time, Active Users, Echo, Chargen et QOTD, ainsi que des protocoles contemporains comme TFTP, DNS et NTP, de la couche application.
Le basculement en TCP peut aider
Même si, à ce jour, aucune exploitation connue de cette vulnérabilité n’a été signalée, la CISPA avertit qu’elle pourrait affecter près de 300 000 hôtes Internet, ainsi que les réseaux qu’ils exposent. « Pour autant, d’après ce que nous savons, ce type d’attaque n’a pas encore été mené sur le terrain. Il serait toutefois facile pour les attaquants d’exploiter cette vulnérabilité si aucune mesure n’était prise pour atténuer le risque », a déclaré Christian Rossow, l’un des chercheurs du CISPA à l’origine de la découverte, dans le blog. Bien que moins rapide que l’UDP, le protocole de contrôle de transmission TCP (Transmission Control Protocol) est un protocole de couche de transport plus fiable, qui établit une connexion entre des systèmes uniquement après une vérification automatisée appelée « handshake » entre les systèmes concernés. L’ajout d’une couche supplémentaire de validation des requêtes sur les transmissions UDP ou leur remplacement complet par des implémentations TCP peut contribuer à empêcher l’exploitation de cette vulnérabilité.
Se définissant comme toute faille qui persiste sans être corrigée pendant plus d’un, la dette de sécurité logicielle des entreprises reste critique selon Veracode. Un phénomène renforcé par la génération de code par l’IA souvent moins sécurisé.
Comme dans le domaine de l’IT, les questions de dette touchent le sujet de la cybersécurité en entreprise. Veracode met en lumière ce sujet moins connu et qui recense les failles non corrigées depuis un an encore présentes dans le parc applicatif. L’étude est basée sur les données recueillies par l’éditeur lors de récents tests de sécurité des applications statiques (Static Application Security Testing, SAST), tests de sécurité des applications dynamiques (Dynamic Application Security Testing, DAST) et l’analyse de composition logicielle (Software component analysis, SCA) de plus d’un million d’applications.
« La prolifération du code généré par l’IA s’accompagne d’un code non sécurisé à grande échelle et de la probabilité qu’il devienne une dette de sécurité », a déclaré Chris Eng, directeur de la recherche chez Veracode. « Compte tenu de l’ampleur de la dette de sécurité que nous avons constatée, il convient de se demander si les outils de remédiation assistés par l’IA peuvent être utiles pour réduire cette dette, sans avoir à réorienter les équipes de développement ou à en augmenter la taille ». L’étude a également révélé un nombre considérable de failles dans les codes de première main et de tierce partie, soulignant l’importance de les tester tous les deux tout au long du cycle de vie du développement logiciel.
Les failles critiques en baisse, mais pas éliminées
L’étude a révélé qu’en 2023, la prévalence des failles de grande gravité avait chuté (dans 17,9 % des applications) à la moitié de son niveau de 2016 (dans 37,9 % des applications). Et si, 3,2 % seulement de toutes les failles ont été jugées très graves (score CVSS supérieur ou égal à 9), près de 16 % de ces brèches étaient « fortement susceptibles » d’être exploitées. Cela signifie qu’un peu moins de 1 % (0,7 %) de toutes les vulnérabilités détectées en 2023 étaient à la fois critiques et hautement exploitables. Globalement, d’après les analyses SAST, DAST et SCA de Veracode, 80 % de toutes les applications actives présentent des failles non résolues, alors que ce chiffre était de 73 % pour les analyses SAST uniquement, qui prennent en compte les problèmes spécifiques à la phase de développement des applications. Les failles détectées dans les composants tiers et open-source étaient comparables à celles détectées dans les codes de première main. En fait, 63,4 % des applications présentaient des failles dans les codes d’origine, tandis que 70,2 % des applications présentaient des failles dans les codes de tierce partie.
Selon l’étude, cette situation est liée à l’adoption plus large de l’IA et nécessite une analyse approfondie des deux sources dans le cycle de développement. En outre, l’étude a mis en évidence le fait qu’en moyenne, une application typique comporte 42 failles pour 1 Mo de code. Les scripts intersites XSS, les injections, les traversées de répertoire et les composants vulnérables et obsolètes sont les principales failles dans les applications à forte intensité (moyenne des résultats par application) et à fort volume (pourcentage d’applications).
Des recommandations pour réduire la dette technique
La dette de sécurité logicielle concerne 42% de toutes les applications. Ce chiffre tombe à 23 % si l’on ajoute les applications de moins d’un an, ce qui signifie que 57 % des applications présentent des failles, mais n’ont pas de dette. La situation est un peu différente si l’on prend en compte l’héritage de sécurité critique (failles critiques non corrigées). « Une grande majorité des entreprises (71 %) ont peu ou prou une dette de sécurité », selon l’étude. « Près de la moitié des entreprises (46 %) présentent des failles persistantes de grande gravité que l’on peut classer dans la catégorie des dettes de sécurité critiques.
En moyenne, près de la moitié de toutes les failles (47 %) d’une entreprise peuvent être attribuées à la dette de sécurité. Pour faire face à celle-ci, l’étude formule quelques recommandations, notamment l’intégration de la sécurité dans la gestion du cycle de développement, la remédiation continue avec une priorisation sur les dettes de sécurité critiques, le renforcement des compétences des développeurs en matière de sécurité et la connaissance du profil de la dette pour le langage de programmation concerné.
Récemment, Solarwinds a demandé à la justice de rejeter les accusations de la SEC concernant la mauvaise gestion interne de la cyberattaque Sunburst de 2020. La société souhaite l’abandon des poursuites.
Dans le contentieux opposant Solarwinds à la SEC sur la cyberattaque de 2020, la société a nié les accusations du gendarme américain de la bourse de mauvaise gestion interne. C’est ce qui ressort d’une requête en annulation déposée auprès du tribunal du district sud de New York. L’entreprise conteste les poursuites engagées par la SEC en octobre 2023 pour « divulgation insuffisante ». Dans sa requête, Solarwinds demande le rejet de toutes les accusations à son encontre, mais aussi contre son CISO, Timothy G .Brown.
La SEC leur reproche notamment d’avoir trompé les investisseurs en ne divulguant pas les « risques connus », d’avoir violé les règles sur les contrôles de divulgation et d’avoir présenté de manière inexacte les mesures de cybersécurité de l’entreprise pendant et avant l’attaque de cyber-espionnage soutenue par la Russie. « La SEC cherche à victimiser la victime en portant des accusations de fraude sur la sécurité et les contrôles contre l’entreprise et son CISO, Tim Brown », a déclaré Solarwinds dans le document déposé au tribunal. « L’affaire est fondamentalement lacunaire et devrait être rejetée dans son intégralité », a ajouté la firme qui considère ces accusations totalement « infondées », ajoutant qu’elle a, « rapidement et de manière transparente, informé sur l’attaque et les investisseurs au fur et à mesure de l’avancement de son enquête ».
Des accusations inexplicables, selon Solarwinds
Dans sa requête, le spécialiste de la gestion de l’IT maintient que les allégations de la SEC sont erronées et ne relèvent pas de son domaine d’expertise. Il estime qu’il s’agit d’un stratagème du régulateur en vue d’établir un mandat pour des réglementations de sécurité qui n’existent pas actuellement. « En ce qui concerne les accusations relatives aux contrôles, la SEC ne parvient pas à identifier les contrôles de divulgation dont l’élaboration aurait été déraisonnable », a déclaré Solarwinds. « Et sa théorie sur les violations des « contrôles internes » équivaut à une réécriture complète de la loi. L’agence cherche à transformer le concept de responsabilité sur les contrôles internes en un vaste mandat lui permettant de réglementer les contrôles de cybersécurité des entreprises publiques, un rôle pour lequel la SEC n’a pas l’autorisation du Congrès ou l’expertise nécessaire », ajoute la plainte.
Toujours selon la société, « outre l’absence de « preuves matérielles » à l’appui de ses allégations de fraude, les accusations de violation de l’obligation d’information portées par la SEC dans le dossier d’octobre étaient irréalistes et illégales ». L’entreprise ajoute qu’elle avait prévenu ses parties prenantes que ses systèmes étaient « vulnérables à des acteurs sophistiqués soutenus par des États-nations ». « La SEC se plaint que ces informations sont insuffisantes, affirmant que les entreprises doivent divulguer des informations détaillées sur les vulnérabilités dans leurs notifications », poursuit SolarWinds dans sa plainte. « Mais ce n’est pas la loi, et pour une bonne raison : diffuser de tels détails serait inutile pour les investisseurs, peu pratique pour les entreprises, et néfaste pour les deux, car ils dévoileraient des feuilles de route aux attaquants ».
Les responsabilités du RSSI en point de mire
L’affaire a été suivie de près par le secteur car elle devrait créer de nombreux précédents, notamment sur la responsabilité du CISO. C’est la première fois qu’un RSSI d’entreprise est cité dans des accusations de la SEC pour non-divulgation. La procédure devrait permettre au CISO de faire l’objet d’un examen plus approfondi et d’assumer de nouvelles responsabilités. « Comme on pouvait s’y attendre, Solarwinds se défend en disant qu’elle a informé les investisseurs de manière adéquate », a déclaré Pareekh Jain, analyste en chef chez Pareekh Consulting. « La question est de savoir si cette information était suffisante ou s’il aurait fallu en faire plus. C’est la première fois qu’une enquête est menée sur la communication d’informations relatives à la cybersécurité à la SEC. Le jugement rendu dans cette affaire servira de principes directeurs aux RSSI pour les futures notifications de cybersécurité au régulateur », a-t-il ajouté.
Alors que Timothy G. Brown est accusé par la SEC d’avoir fait des déclarations publiques et signé des documents de sécurité internes qui, selon l’agence fédérale, ont contribué à tromper les investisseurs, Solarwinds qualifie ces accusations d’« injustifiées » et d’« inexplicables ». « La SEC ne parvient pas à articuler une théorie cohérente de complicité à l’encontre de Monsieur Brown », ajoute le document. Il est « un professionnel expérimenté et respecté qui a simplement fait son travail pendant les événements en question (et l’a bien fait). Les accusations gratuites de la SEC à son encontre doivent être rejetées ». Avant cette demande officielle de rejet des accusations de la SEC, le CEO de Solarwinds, Sudhakar Ramakrishna, avait publié les réponses de l’entreprise le même jour que le dépôt auprès de la SEC, qualifiant les accusations de « peu judicieuses » et représentatives d’un « ensemble régressif de points de vue et d’actions » incompatibles avec la manière dont doit progresser l’industrie.
Soutenu par la Russie, ce groupe connu pour cibler par phishing des comptes gouvernementaux occidentaux mène désormais des actions personnalisées avec un malware propriétaire dénommé Spica.
Selon un rapport du Threat Analysis Group (TAG) de Google, Coldriver, parrainé par l’État russe, améliore ses techniques offensives. Le groupe est connu pour ses attaques de spear phishing contre des entités gouvernementales ou ONG à des fins de cyber-espionnage. Également connue sous les noms de UNC4057, Star Blizzard, Blue Charlie et Callisto, cet APT rajoute dans son arsenal un malware nommé Spica pour voler des informations, exécuter des commandes arbitraires et établir une persistance.
Le Threat Analysis Group « a récemment constaté que Coldriver a fait évoluer ses tactiques d’hameçonnage pour collecter des identifiants et diffuser des logiciels malveillants dans ses campagnes, en utilisant des documents PDF comme appâts ». Ces observations ont été faites après « l’interruption d’une campagne en cours ».
Un leurre PDF pour diffuser des malwares
Dans sa dernière campagne, le TAG a pu voir que Coldriver utilisait des faux comptes pour livrer un fichier PDF chiffré aux systèmes cibles, lequel agissait comme un leurre pour déclencher l’infection. Une technique lancée « dès novembre 2022 », observe les experts de Google. « Coldriver présente ces documents comme un nouvel article d’opinion ou un autre type d’article que le faux compte cherche à publier, en demandant à la cible de donner son avis.
Quand l’utilisateur tente d’ouvrir le PDF, le contenu semble être un texte crypté. Si la cible demande le décryptage, elle reçoit un lien, généralement hébergé sur un site de stockage cloud, vers un utilitaire de « décryptage ». Cet utilitaire, ainsi que l’affichage d’un document « décrypté » leurre, constituent la backdoor de Spica en toute discrétion. Même si Coldriver a déjà utilisé un malware, SPICA est le premier logiciel malveillant personnalisé qui lui est attribué. « En 2015 et 2016, le TAG avait observé que Coldriver utilisait l’implant Scout divulgué lors de l’incident Hacking Team de juillet 2015 ».
Spica, un malware à multiples facettes
L’analyse du binaire Spica par le TAG a révélé qu’il est écrit en Rust, un langage de programmation de bas niveau qui sert à construire des systèmes d’exploitation, des noyaux et des pilotes de périphériques. Le binaire utilise JSON, un format d’échange de données basé sur le texte, par le biais de Websockets pour le serveur de commande et de contrôle (C2). « Une fois exécuté, Spica décode un PDF intégré, l’écrit sur le disque et l’ouvre comme un leurre pour l’utilisateur », a ajouté le groupe d’analyses de Google. « En arrière-plan, il établit la persistance et démarre la boucle C2 principale, en attendant l’exécution des commandes. Spica prend en charge un certain nombre de commandes pour des attaques variées, notamment des commandes shell arbitraires, des téléchargements, le vol de cookies à partir de Chrome, Firefox, Opera et Edge, ainsi que l’énumération de documents et leur exfiltration dans une archive ». Le TAG a aussi remarqué la présence d’une commande « Telegram » dont il n’a pas pu analyser les fonctionnalités spécifiques. La malware établit la persistance en créant une tâche programmée nommée CalendarChecker, à l’aide d’une commande PowerShell obscurcie. Pour sensibiliser les utilisateurs, le Threat Analysis Group a partagé des indicateurs de compromission (IOC) comprenant des hachages de documents pdf, certaines instances Spica et un domaine C2.
Destinée aux développeurs et aux équipes de sécurité, la dernière solution AppRisk de Snyk est dotée de fonctions de découverte et d’analyse du contexte de sécurité applicatif pour mieux déterminer les risques associés.
Baptisée AppRisk, l’offre de gestion de la posture de sécurité des applications (ASPM pour application security posture management) lancée par Snyk, le fournisseur de solutions de sécurité pour les développeurs, vise à aider les équipes de sécurité des applications (AppSec) à mieux surveiller et gérer leurs programmes de cybersécurité. Les développeurs et les équipes de sécurité pourront collaborer et relever les défis de la cybersécurité à travers une interface spécifique axée sur la découverte des actifs et à la hiérarchisation des risques.
« Snyk est un pionnier dans les outils pour développeurs, qu’il aide à mieux intégrer la sécurité dans leurs processus de développement et à accélérer les cycles de développement cloud-natifs en les affranchissant des problèmes de sécurité », a déclaré Melinda Marks, analyste senior chez Enterprise Strategy Group (ESG). « Le fournisseur était surtout connu pour ses capacités d’analyse des composants logiciels et de la chaîne d’approvisionnement des logiciels », a-t-elle rappelé. « Avec cette offre, Snyk se positionne un peu plus largement comme fournisseur de sécurité des applications pour le développement moderne et cloud-natif », a ajouté Melinda Marks. La solution AppRisk sera proposée en deux éditions : Essentials, disponible immédiatement, qui ciblera les clients existants de Snyk et fonctionnera uniquement avec les outils de l’éditeur. Et la version Pro, axée sur les entreprises, qui marchera avec les outils de sécurité des développeurs Synk ou non. Celle-ci sera lancée début 2024.
Automatiser la découverte des actifs, les contrôles de sécurité et la priorisation des risques
AppRisk combine les capacités existantes de la plateforme de sécurité des développeurs Snyk, y compris la télémétrie et les contrôles de sécurité, avec une interface ASPM et un ensemble de capacités pour les équipes devsecops. En automatisant la découverte des actifs applicatifs, AppRisk permet aux équipes de sécurité de configurer l’espace ASPM pour découvrir les actifs applicatifs et les classer au fil de l’eau en fonction du contexte commercial. Cette classification basée sur le contexte, combinée aux contrôles existants de Snyk pour analyser et quantifier les risques, alimente le nouveau moteur de hiérarchisation des risques. En outre, selon Snyk, l’offre permet aux équipes devsecops de définir et de gérer les exigences de sécurité et de conformité appropriées, tout en vérifiant que les applications disposent des contrôles adéquats.
Selon Melinda Marks, Snyk devra se concentrer sur deux domaines clés pour que son offre soit efficace. D’une part, être capable de fournir une visualisation granulaire des actifs de l’application et d’autre part, pouvoir quantifier efficacement les risques en mettant l’accent sur le contexte utilisé. « Avec les applications cloud native, la gestion des vulnérabilités représente un véritable défi, car il y a plusieurs couches à tester et à analyser pour gérer efficacement les risques, y compris l’infrastructure en tant que code, le code personnalisé, les images de conteneurs, le code tiers et d’autres éléments dynamiques et souvent éphémères », a déclaré Melinda Marks. « Le scan est nécessaire pour détecter les problèmes éventuels, mais le nombre d’alertes peut être écrasant pour donner la priorité à une remédiation dans les temps afin de prévenir les incidents ou réduire l’impact d’une violation. Ces solutions qui s’intéressent au contexte des applications, à la façon dont elles sont construites, et scrutent leurs connexions aux ressources qu’elles créent, aident les équipes de sécurité des applications à savoir où regarder en priorité et voir ce qui nécessite une attention urgente afin de travailler efficacement », a-t-elle ajouté. Melinda Marks estime par ailleurs que « la consolidation des contrôles de sécurité des applications par AppRisk permettrait facilement de qualifier l’offre de Snyk de plateforme CNAPP (cloud native application protection platform) plutôt que d’ASPM », ajoutant « qu’avec l’adoption accrue des services cloud, la sécurité des applications pour la gestion globale des risques de sécurité devient toujours plus importante ». De plus, selon elle, « il faut s’attendre à ce que les entreprises consolident leurs outils pour optimiser l’efficacité de leurs équipes de sécurité ».
De multiples vulnérabilités de gravité élevée affectant certaines versions de NetScaler ADC et Gateway peuvent entraîner la divulgation d’informations et permettre des attaques par déni de service. Les mises à jour doivent être effectuées au plus vite.
Citrix a demandé à ses clients de mettre à jour immédiatement les produits de mise en réseau NetScaler ADC et NetScaler Gateway afin d’empêcher l’exploitation active de vulnérabilités qui pourraient conduire à la divulgation d’informations et à des attaques par déni de service. NetScaler ADC (Application Delivery Controller) et NetScaler Gateway améliorent les performances, la sécurité et la disponibilité des applications et des services au sein des réseaux. Le 10 octobre dernier, l’éditeur avait déjà mis en garde contre les vulnérabilités référencées CVE-2023-4966 et CVE-2023-4967 pouvant affecter ces produits, qu’il décrivait alors comme des bogues « liés à la mémoire tampon non authentifiée ». La vulnérabilité CVE-2023-4966, de gravité élevée et de divulgation d’informations critiques, avait reçu un score CVSS de 9,4.
L’entreprise de cybersécurité AssetNote, spécialisée dans l’identification et la gestion des risques de sécurité dans les applications web et les actifs en ligne, a publié sur GitHub un PoC d’exploit de la vulnérabilité baptisée Citrix Bleed. L’entreprise propose également des tests permettant aux clients de vérifier leur exposition à la vulnérabilité. Dans un avis, Citrix a déclaré que « l’exploitation de la vulnérabilité CVE-2023-4966 avait été observée sur des appareils non atténués ». Ajoutant que le « Cloud Software Group recommandait vivement aux clients de NetScaler ADC et NetScaler Gateway d’installer les mises à jour correspondantes dès que possible ». Les exploits actifs pour la vulnérabilité CVE-2023-4967, qui peut permettre à des attaquants de lancer des attaques DoS, n’ont pas été aussi largement observés. Cette faille a été affectée du score CVSS de 8,2.
L’application immédiate des correctifs préconisé
Dans le dernier avis actualisé sur ses trous de sécurité, Citrix a recommandé de mettre à jour sans délai les dispositifs concernés. Plusieurs versions de NetScaler ADC et NetScaler Gateway affectées par les vulnérabilités, sont listées par Citrix dans le dernier bulletin de sécurité. « La version 12.1 de NetScaler ADC et NetScaler Gateway est désormais en fin de vie (End-of-Life, EOL) », a ajouté Citrix dans son avis. « Il est recommandé aux clients de mettre à jour leurs appareils vers l’une des versions prises en charge qui corrigent les vulnérabilités ». AssetNote a fourni de son côté quelques détails techniques sur la vulnérabilité CVE-2023-4966.
L’entreprise de cybersécurité a notamment effectué un patch-diffing, une analyse différentielle qui compare les versions corrigées et non corrigées d’un produit, sur les versions NetScaler 13.1-49.15 (corrigée) et 13.1-48.47 (non corrigée), afin de déterminer les fonctions vulnérables. Le processus de différenciation a consisté à examiner le binaire /NetScaler/nsppe. « Ce moteur de traitement des paquets NetScaler contient une pile réseau TCP/IP complète ainsi que plusieurs services HTTP », a expliqué AssetNote dans un billet de blog. « S’il existe une vulnérabilité dans NetScaler, c’est là que nous regardons en premier ». AssetNote a découvert deux fonctions vulnérables : ns_aaa_oauth_send_openid_config et ns_aaa_oauthrp_send_openid_config. Les correctifs pour ces fonctions, qui permettent un accès non authentifié, ont été réalisés avec la même logique. Outre la mise à jour vers les versions corrigées, le fournisseur recommande de supprimer toutes les sessions actives et persistantes au moyen d’une série de commandes, notamment : kill icaconnection -all ; kill rdp connection -all ; kill pcoipConnection -all ; kill aaa session -all ; et clear lb persistentSessions. Cependant, le fournisseur fait également remarquer que « les clients utilisant les services cloud gérés par Citrix ou l’authentification adaptative gérée par Citrix n’ont pas besoin de prendre de mesures ».
Selon des chercheurs en sécurité d’Oligo Security, les systèmes d’IA des plus grandes entreprises du monde utilisant le paquet open source TorchServe sont à risque. Des mises à jour et solutions alternatives doivent être déployées dès que possible.
Les chercheurs d’Oligo Security ont découvert trois problèmes de sécurité critiques dans le paquet open source TorchServe, utilisé pour desservir et mettre à l’échelle les modèles PyTorch en production. Appelées ShellTorch, ces failles pourraient offrir à un attaquant d’exécuter des codes arbitraires sur les systèmes affectés. Elles sont capables de lui octroyer le privilège de voir, modifier, voler et supprimer des modèles d’intelligence artificielle et des données sensibles sur le serveur TorchServe. « Ces vulnérabilités peuvent entièrement compromettre l’infrastructure d’IA des plus grandes entreprises du monde », explique Oligo Security. « Elles peuvent conduire à une exécution de code à distance en chaîne complète, et exposer des dizaines de milliers de services et d’utilisateurs finaux, y compris certaines des plus grandes entreprises du monde, à l’accès non autorisé et à l’insertion de modèles d’IA malveillants, et potentiellement à une prise de contrôle complète du serveur ». Deux des vulnérabilités découvertes, référencées CVE-2023-43654 et CVE-2023-1471, ont des scores CVSS respectifs de 9,8 et 9,9, tandis que la troisième n’a pas encore d’entrée CVE.
Au moment de servir des modèles en production, TorchServe provisionne la récupération des fichiers de configuration pour les modèles à partir d’une URL distante en utilisant le flux de travail ou l’API d’enregistrement de modèle. Dans l’une des vulnérabilités (CVE-2023-43654), il a été découvert que la logique de l’API pour une liste autorisée de domaines accepte tous les domaines comme URL valides, ce qui entraîne une contrefaçon de requête côté serveur (Server-Side-Request-Forgery, SSRF). « Cette vulnérabilité permet à un attaquant de télécharger un modèle malveillant qui sera exécuté par le serveur, entraînant ainsi une exécution de code arbitraire », a déclaré Oligo Security.
Les principaux environnements de conteneurs aussi affectés
Un autre problème lié à la faille CVE-2023-1471 fait que TorchServe est exposé à une exécution de code à distance critique via la vulnérabilité de désérialisation SnakeYAML, laquelle résulte d’une mauvaise utilisation de la bibliothèque open source (Java) SnakeYAML. « Les modèles d’IA peuvent inclure un fichier YAML pour déclarer leur configuration souhaitée. En téléchargeant un modèle avec un fichier YAML malveillant, nous avons pu déclencher une attaque de désérialisation non sécurisée qui a entraîné l’exécution de code sur la machine », a indiqué Oligo Security. La troisième faille (sans référence CVE à ce jour) est une vulnérabilité de mauvaise configuration dans l’API de gestion de TorchServe, responsable de la gestion des modèles au moment de l’exécution. L’interface API est configurée pour écouter sur le port 0.0.0.0 par défaut, ce qui la rend accessible aux requêtes externes, privées et publiques. L’exploitation des trois vulnérabilités combinées peut permettre l’exécution de code à distance avec des privilèges élevés, et déboucher sur une prise de contrôle complète du serveur.
Selon Oligo Security, le conteneur d’apprentissage profond (Deep Learning Container, DLC) d’Amazon et de Google s’est révélé vulnérable à ShellTorch. Les services managés d’Amazon et de Google comprennent des contrôles compensatoires qui réduisent l’exposition. « AWS a connaissance des vulnérabilités CVE-2023-43654 et CVE-2022-1471 présentes dans les versions 0.3.0 à 0.8.1 de PyTorch TorchServe, qui utilisent une version de la bibliothèque open source SnakeYAML v1.31 », a déclaré Amazon dans un avis du 2 octobre à propos des vulnérabilités. « La version 0.8.2 de TorchServe résout ces problèmes. AWS recommande aux clients qui utilisent le conteneur PyTorch inference Deep Learning Containers (DLC) 1.13.1, 2.0.0, ou 2.0.1 dans EC2, EKS, ou ECS publié avant le 11 septembre 2023, de mettre à jour vers la version 0.8.2 de TorchServe ». Amazon a précisé que les clients utilisant les Deep Learning Containers (DLC) d’inférence PyTorch via SageMaker ne sont pas concernés. Meta, co-mainteneur avec Amazon de la bibliothèque open source TorchServe, a rapidement corrigé l’API de gestion par défaut pour atténuer la troisième vulnérabilité. Oligo Security a déclaré avoir travaillé avec les mainteneurs de PyTorch pour la divulgation responsable de ces failles.