Une campagne coordonnée d’une soixantaine de paquets npm malveillants a été découverte. La charge utile identique est destinée à l’espionnage des données sensibles sur les systèmes des développeurs.
Dans le cadre d’une campagne coordonnée étalée sur un peu moins de deux semaines et impliquant 60 paquets npm malveillants, des pirates ont probablement réussi à s’emparer d’informations sensibles sur l’hôte et le réseau des systèmes des développeurs. Selon Socket, à l’origine de la découverte, ces paquets ont été distribués via trois comptes npm différents afin d’exécuter des scripts post-installation furtifs pendant les opérations « npm install ».
« Le script cible les systèmes Windows, macOS ou Linux et inclut des vérifications courantes de contournement de la sandbox, si bien que chaque poste de travail ou nœud d’intégration continue (CI) infecté est une source potentielle de reconnaissance précieuse », a déclaré Kirill Boychenko, chercheur chez Socket, dans un billet de blog. Les scripts collectaient les noms d’hôtes, les adresses IP internes et externes, les configurations DNS et les chemins d’accès aux répertoires des utilisateurs avant de transmettre ces informations à un webhook Discord contrôlé par l’acteur malveillant.
Une campagne de reconnaissance
L’extrait de code du payload partagé par Socket révèle que l’accent est mis sur la reconnaissance plutôt que sur les dommages immédiats. Le script vise essentiellement à relever les empreintes numériques de chaque système qui installe le paquet infecté. « En recueillant les adresses IP internes et externes, les serveurs DNS, les noms d’utilisateur et les chemins d’accès aux projets, l’acteur de la menace peut cartographier le réseau et identifier des cibles de grande valeur pour de futures campagnes », a ajouté M. Boychenko. Le script de la charge utile exploite des tactiques légères d’évasion du bac à sable pour éviter d’être détecté. Il a notamment recherché des indicateurs de virtualisation tels que « systemd-detect-virt » et des noms d’utilisateur connus tels que « sandbox ».
Le script semble identique dans les 60 paquets malveillants, ce qui laisse penser que la campagne est coordonnée. M. Boychenko alerte sur le fait que sur les serveurs à intégration continue (CI), la fuite a pu révéler certaines informations spécifiques comme les URL de registres privés et les chemins de construction internes, ce qui pourrait accélérer une attaque de la chaîne d’approvisionnement. Socket Security a indiqué qu’elle avait demandé la suppression de tous les paquets npm.
Suppression de comptes
Les trois premiers paquets malveillants, « e-learning-garena », « seatalk-rn-leave-calendar » et « coral-web-be », ont été publiés sous les comptes npm bbbb335656, cdsfdfafd1232436437 et sdsds656565, respectivement. Depuis, ces trois comptes ont publié chacun vingt paquets malveillants. Selon Socket, le premier paquet est apparu il y a onze jours, et le plus récent est apparu quelques heures seulement avant la divulgation, ce qui confirme que l’opération était toujours en cours à ce moment-là.
Cependant, une recherche sur npm au moment de la rédaction de cet article a révélé que les comptes ont probablement été retirés de npm. Aucun des paquets signalés dans la recherche de Socket n’a pu être retracé par la recherche non plus. Alors qu’ils étaient en ligne sur npm, les téléchargements combinés auraient dépassé les 3 000, ce qui, selon Socket, aurait fourni aux pirates une « carte extensive des réseaux de développeurs et d’entreprises » en vue d’intrusions futures.
De multiples abus de npm découverts en quelques jours
npm, le gestionnaire de paquets par défaut pour JavaScript, est devenu une cible privilégiée des attaquants du fait de son utilisation inégalée dans les flux de travail des développeurs et de sa capacité à servir de puissant vecteur pour les attaques de la chaîne d’approvisionnement à grande échelle. En début de semaine, Socket a également découvert une série de paquets npm malveillants, passés inaperçus dans npm depuis plus de deux ans, qui déploient des attaques contre des frameworks JavaScript particulièrement répandus, notamment React, Vue.js, Vite, Node.js et l’éditeur open-source Quill. Les paquets malveillants, qui se faisaient passer pour des plugins et des utilitaires inoffensifs, contenaient des charges utiles destructrices destinées à corrompre les données, à effacer les fichiers critiques et à faire planter les systèmes. Depuis leur mise en ligne, ils ont été téléchargés plus de 6 200 fois, échappant ainsi à la détection et se glissant dans des environnements de développement peu vigilants.
« L’acteur de la menace à l’origine de cette campagne, utilisant l’alias npm xuxingfeng avec un email d’enregistrement 1634389031@qq[.]com, a publié huit paquets destinés à causer des dommages étendus à travers l’écosystème JavaScript », a expliqué le chercheur de Socket, Kush Pandya, dans un billet de blog. « Le même compte a également publié plusieurs paquets légitimes et non malveillants qui fonctionnent comme annoncé ». Début mai, des pirates ont abusé de npm pour cibler des développeurs multilingues avec des paquets exploitant la technique dite du typosquattage, avec des infostealers et des capacités d’exécution de code à distance (RCE). M. Boychenko conseille d’appliquer une hygiène standard pour gérer les dépendances de npm. Il recommande d’utiliser des outils d’analyse des dépendances pour repérer les crochets de post-installation, les URL codées en dur et les archives tar anormalement petites. Il conseille aussi de renforcer le pipeline de développement avec des contrôles de sécurité automatisés.
Une campagne coordonnée d’une soixantaine de paquets npm malveillants a été découverte. La charge utile identique est destinée à l’espionnage des données sensibles sur les systèmes des développeurs.
Dans le cadre d’une campagne coordonnée étalée sur un peu moins de deux semaines et impliquant 60 paquets npm malveillants, des pirates ont probablement réussi à s’emparer d’informations sensibles sur l’hôte et le réseau des systèmes des développeurs. Selon Socket, à l’origine de la découverte, ces paquets ont été distribués via trois comptes npm différents afin d’exécuter des scripts post-installation furtifs pendant les opérations « npm install ».
« Le script cible les systèmes Windows, macOS ou Linux et inclut des vérifications courantes de contournement de la sandbox, si bien que chaque poste de travail ou nœud d’intégration continue (CI) infecté est une source potentielle de reconnaissance précieuse », a déclaré Kirill Boychenko, chercheur chez Socket, dans un billet de blog. Les scripts collectaient les noms d’hôtes, les adresses IP internes et externes, les configurations DNS et les chemins d’accès aux répertoires des utilisateurs avant de transmettre ces informations à un webhook Discord contrôlé par l’acteur malveillant.
Une campagne de reconnaissance
L’extrait de code du payload partagé par Socket révèle que l’accent est mis sur la reconnaissance plutôt que sur les dommages immédiats. Le script vise essentiellement à relever les empreintes numériques de chaque système qui installe le paquet infecté. « En recueillant les adresses IP internes et externes, les serveurs DNS, les noms d’utilisateur et les chemins d’accès aux projets, l’acteur de la menace peut cartographier le réseau et identifier des cibles de grande valeur pour de futures campagnes », a ajouté M. Boychenko. Le script de la charge utile exploite des tactiques légères d’évasion du bac à sable pour éviter d’être détecté. Il a notamment recherché des indicateurs de virtualisation tels que « systemd-detect-virt » et des noms d’utilisateur connus tels que « sandbox ».
Le script semble identique dans les 60 paquets malveillants, ce qui laisse penser que la campagne est coordonnée. M. Boychenko alerte sur le fait que sur les serveurs à intégration continue (CI), la fuite a pu révéler certaines informations spécifiques comme les URL de registres privés et les chemins de construction internes, ce qui pourrait accélérer une attaque de la chaîne d’approvisionnement. Socket Security a indiqué qu’elle avait demandé la suppression de tous les paquets npm.
Suppression de comptes
Les trois premiers paquets malveillants, « e-learning-garena », « seatalk-rn-leave-calendar » et « coral-web-be », ont été publiés sous les comptes npm bbbb335656, cdsfdfafd1232436437 et sdsds656565, respectivement. Depuis, ces trois comptes ont publié chacun vingt paquets malveillants. Selon Socket, le premier paquet est apparu il y a onze jours, et le plus récent est apparu quelques heures seulement avant la divulgation, ce qui confirme que l’opération était toujours en cours à ce moment-là.
Cependant, une recherche sur npm au moment de la rédaction de cet article a révélé que les comptes ont probablement été retirés de npm. Aucun des paquets signalés dans la recherche de Socket n’a pu être retracé par la recherche non plus. Alors qu’ils étaient en ligne sur npm, les téléchargements combinés auraient dépassé les 3 000, ce qui, selon Socket, aurait fourni aux pirates une « carte extensive des réseaux de développeurs et d’entreprises » en vue d’intrusions futures.
De multiples abus de npm découverts en quelques jours
npm, le gestionnaire de paquets par défaut pour JavaScript, est devenu une cible privilégiée des attaquants du fait de son utilisation inégalée dans les flux de travail des développeurs et de sa capacité à servir de puissant vecteur pour les attaques de la chaîne d’approvisionnement à grande échelle. En début de semaine, Socket a également découvert une série de paquets npm malveillants, passés inaperçus dans npm depuis plus de deux ans, qui déploient des attaques contre des frameworks JavaScript particulièrement répandus, notamment React, Vue.js, Vite, Node.js et l’éditeur open-source Quill. Les paquets malveillants, qui se faisaient passer pour des plugins et des utilitaires inoffensifs, contenaient des charges utiles destructrices destinées à corrompre les données, à effacer les fichiers critiques et à faire planter les systèmes. Depuis leur mise en ligne, ils ont été téléchargés plus de 6 200 fois, échappant ainsi à la détection et se glissant dans des environnements de développement peu vigilants.
« L’acteur de la menace à l’origine de cette campagne, utilisant l’alias npm xuxingfeng avec un email d’enregistrement 1634389031@qq[.]com, a publié huit paquets destinés à causer des dommages étendus à travers l’écosystème JavaScript », a expliqué le chercheur de Socket, Kush Pandya, dans un billet de blog. « Le même compte a également publié plusieurs paquets légitimes et non malveillants qui fonctionnent comme annoncé ». Début mai, des pirates ont abusé de npm pour cibler des développeurs multilingues avec des paquets exploitant la technique dite du typosquattage, avec des infostealers et des capacités d’exécution de code à distance (RCE). M. Boychenko conseille d’appliquer une hygiène standard pour gérer les dépendances de npm. Il recommande d’utiliser des outils d’analyse des dépendances pour repérer les crochets de post-installation, les URL codées en dur et les archives tar anormalement petites. Il conseille aussi de renforcer le pipeline de développement avec des contrôles de sécurité automatisés.
Les développeurs pourront utiliser Serverless MCP Server d’AWS pour demander à leurs agents de codage IA de concevoir, déployer et dépanner leurs applications.
Amazon Web Services a lancé Serverless MCP Server pour permettre aux entreprises de développer plus rapidement, et presque sans intervention manuelle, des applications gérées à l’aide d’agents d’IA. Cette solution fournit aux assistants de codage pilotés par l’IA, tels qu’Amazon Q, Cline ou Cursor, utilisés par les développeurs, la connaissance de l’architecture serverless des modèles, des schémas et des meilleures pratiques. Tout cela se fait essentiellement à partir de Lambda, le service géré d’AWS qui exécute les applications et prend en charge la complexité de la gestion des serveurs ou du traitement. « Ce serveur MCP agit comme un compagnon intelligent, guidant les développeurs tout au long du cycle de vie du développement d’applications, de la conception initiale au déploiement, en offrant une assistance contextuelle à chaque étape », a écrit dans un billet de blog le fournisseur de services cloud.
MCP, abréviation de Model Context Protocol, est un protocole ouvert développé par Anthropic qui permet aux agents d’IA au sein des applications d’accéder à des outils et des données externes pour répondre à une demande de l’utilisateur via un mécanisme client-serveur, où le client est l’agent d’intelligence artificielle ou l’interface par agent et le serveur fournit les outils et les données. « Pour les applications basées sur le web, le serveur AWS MCP fournira également un support spécialisé pour les applications back-end, front-end ou full-stack, et la configuration de domaines personnalisés », a ajouté le fournisseur.
Lambda Tool Server Vs Serverless MCP Server
Il ne faut pas confondre Serverless MCP Server avec l’actuel Lambda Tool Server d’AWS, qui aide les développeurs à utiliser les fonctions Lambda via des agents. Ce dernier permet essentiellement aux grands modèles de langage d’interagir directement avec les fonctions Lambda existantes en tant qu’outils MCP sans aucune modification du code, c’est-à-dire qu’il agit comme un pont entre les clients MCP et les fonctions Lambda. Cependant, cette offre peut être utilisée pour compléter Lambda Tool Server existant ou en combinaison pour développer des applications pouvant servir à des cas d’usage plus variés, ou pour maintenir davantage de processus ou de flux de travail. Outre la gestion du cycle de vie des applications sans serveur et le développement et le déploiement d’applications web, Serverless MCP Server peut être utilisé pour l’observabilité et donner des indications sur certains sujets. « Par exemple, savoir à quel moment utiliser Lambda pour des exécutions et des cas d’usage spécifiques ou quel outil infrastructure-as-code utiliser pour déployer une application », a déclaré AWS.
Les développeurs peuvent utiliser n’importe quel assistant de codage via son MCP Client pour utiliser AWS Serverless MCP Server, et ils peuvent commencer par télécharger le serveur depuis GitHub ou Python Package Index (PyPi). Une fois le serveur téléchargé et installé, les développeurs doivent insérer un morceau de code dans la configuration du client MCP pour configurer le profil AWS qu’ils souhaitent utiliser. Après cette étape, ils peuvent commencer à chercher des conseils, à concevoir, à tester, à déployer et à dépanner des applications sans serveur en sollicitant leur assistant IA qui, en fonction de ce qui est demandé, recherchera des outils dans le nouveau Serveur et présentera des informations ou accomplira des tâches. Les exemples d’outils pour le développement et le déploiement d’applications comprennent sam_init_tool, sam_build_tool, sam_deploy_tool sam_local_invoke_tool, deployment_help_tool, et deploy_serverless_app_help_tool.
La sécurité pas négligée
AWS suggère aux entreprises, lorsqu’elles créent des applications, de commencer par utiliser sa fonction d’accompagnement assistée par l’IA pour les décisions architecturales et, tout au long du processus de développement, d’utiliser l’outil d’accompagnement pour prendre des décisions éclairées, car il suit les meilleures pratiques. De plus, le fournisseur de services cloud affirme que son offre répond également aux préoccupations de sécurité, courantes avec MCP. « Par défaut, le serveur MCP fonctionne en mode lecture seule, autorisant uniquement les actions non mutantes », a indiqué AWS, ajoutant que le serveur restreint aussi l’accès aux journaux Amazon CloudWatch par défaut, protégeant ainsi les données opérationnelles sensibles de l’exposition aux assistants d’IA. Cependant, les développeurs ont la possibilité d’outrepasser les paramètres de sécurité de manière sélective : ils peuvent utiliser l’indicateur allow-write pour autoriser les opérations de mutation pour des tâches de déploiements et de mises à jour par exemple, et allow-sensitive-data-access pour autoriser l’accès aux journaux CloudWatch à des fins de débogage et de dépannage.
Selon une récente étude de Google Quantum AI, il faut moins de qubits pour casser le chiffrement RSA par rapport aux dernières estimations de 2019. Une alerte pour forcer les entreprises à réfléchir sur le chiffrement post-quantique.
« Depuis des décennies, les communautés quantiques et de la sécurité savent aussi que les ordinateurs quantiques à grande échelle seront probablement capables, à un moment donné, de casser de nombreux algorithmes de cryptographie à clé publique sécurisés d’aujourd’hui », ont écrit Craig Gidney et Sophie Schmieg, chercheurs chez Google, dans un billet de blog. Ces découvertes interviennent à un moment où l’informatique quantique progresse rapidement. Alors que les systèmes actuels ne fonctionnent encore qu’avec des centaines de qubits, les recherches de la firme de Mountain View montrent que trois avancées techniques – des algorithmes plus efficaces, une correction d’erreur avancée et des opérations quantiques optimisées – abaissent considérablement le seuil des menaces cryptographiques dans le monde réel.
Passer d’un milliard de qubits en 2012 à 1 million aujourd’hui
Plus précisément, l’équipe du fournisseur a adopté une méthode 2024 pour l’exponentiation modulaire approximative, ce qui a permis de réduire le nombre de portes quantiques de 1 000 CNOT (controlled-NOT) à seulement 2 CNOT. Elle a également triplé la densité des qubits logiques grâce à la correction d’erreurs en couches et a introduit la procédure appelée « magic state cultivation » pour rationaliser le traitement quantique. Narayan Gokhale, vice-président et analyste principal du QKS Group, a qualifié ces résultats de « signal d’alarme pour agir dans une urgence mesurée, sans panique », affirmant qu’ils confirment les calendriers existants du chiffrement post quantique mais soulignent la nécessité d’accélérer les transitions pour les systèmes cryptographiques à longue durée de vie ou à haut risque. Le rythme des progrès marque une forte accélération. Depuis que Peter Shor a révélé en 1994 que les ordinateurs quantiques pouvaient théoriquement casser le RSA, les estimations des ressources ont chuté, passant d’un milliard de qubits en 2012 à seulement un million aujourd’hui.
Bart Willemsen, analyste vice-président de Gartner, a averti que « l’informatique quantique affaiblira la cryptographie asymétrique d’ici à 2029 ». Étant donné que les mises à jour de chiffrement s’étalent souvent sur plusieurs années, il a exhorté les entreprises à commencer leur planification stratégique dès maintenant, en particulier pour les infrastructures dont les dépendances cryptographiques sont codées en dur. « De nombreux développeurs ne connaissent pas très bien les bibliothèques cryptographiques et les fonctions de hachage, de sorte qu’un inventaire précoce, des tests de performance et une cartographie du système sont essentiels à toute feuille de route réaliste en matière de CQP », a-t-il fait remarquer.
Implications pour la sécurité des entreprises
Pour les responsables de la sécurité, la recherche met en évidence deux priorités immédiates. Tout d’abord, les communications cryptées utilisant le chiffrement RSA ou des algorithmes similaires sont confrontées au risque sérieux du « récolter maintenant, décrypter plus tard », car les données interceptées pourraient être décryptées une fois que les ordinateurs quantiques auront atteint une échelle suffisante. Google a mis en œuvre le ML-KEM approuvé par le NIST dans Chrome et dans ses systèmes internes, établissant ainsi une référence pour la sécurisation du trafic web, des VPN et des plateformes de messagerie. Selon les analystes de la sécurité, la mise en œuvre des signatures numériques présente un défi plus complexe. « La mise en place d’une véritable résilience quantique exige plus que des mises à jour techniques », a estimé M. Gokhale. « Elle implique une planification opérationnelle complète qui intègre la cartographie des actifs cryptographiques à des initiatives plus larges de transformation numérique. » La durée de vie prolongée des clés de signature, souvent intégrées dans des modules de sécurité matériels ou conçues pour une utilisation pluriannuelle, crée des obstacles uniques à la migration qui nécessitent une planification précoce.
Le calendrier recommandé par le NIST, à savoir la suppression des algorithmes vulnérables d’ici 2030 et leur élimination complète d’ici à 2035, semble de plus en plus ferme. M. Willemsen met en garde contre toute complaisance : « Un grand nombre d’entreprises sous-estiment l’impact de la menace quantique parce qu’elle paraît lointaine. Cependant, le délai de plusieurs années, nécessaire à une migration adéquate, signifie que la préparation ne peut pas attendre. » Les équipes de sécurité devraient prendre plusieurs mesures concrètes, notamment des audits cryptographiques, qui permettront d’identifier les systèmes les plus vulnérables, tandis que les plans de transition prioritaires devraient se concentrer en premier lieu sur les actifs de grande valeur contenant des données sensibles à long terme. Il est tout aussi important d’interroger les fournisseurs de technologies sur leurs feuilles de route en matière d’implémentation post-quantique, et de tester les algorithmes résistants au quantum pour s’assurer de leur compatibilité opérationnelle avec l’infrastructure existante.
Les attaques quantiques pratiques n’auront peut-être pas lieu avant des années. Mais la transition du chiffrement prendra tout autant de temps, si ce n’est plus, pour être bien exécutée. « Les entreprises qui agissent maintenant auront le temps et la flexibilité de construire des systèmes durables et sécurisés », concluent les analystes.
Ryan Dahl, fondateur de Deno, est monté au créneau pour rassurer sur la pérennité du runtime open source. Des rumeurs évoquaient une prochaine disparition de ce concurrent de Node.js.
Non, Deno ne va pas disparaître. Dans un blog, Ryan Dahl, créateur de Deno (et de Node.js) a réagi aux rumeurs parlant de la fin de ce runtime open source en estimant qu’elles étaient « largement exagérées ». Par ailleurs, le co-fondateur de Deno Land (une organisation supportant Deno) a répondu aux critiques concernant Deploy, le service d’hébergement en mode edge, KV la base de données clé-valeur et Fresh le framework web, ainsi qu’aux questions concernant la dynamique de Deno.
Il estime que certaines de ces critiques sont fondées. « En fait, je pense qu’il est juste de dire que nous avons contribué à créer une certaine peur et une certaine incertitude en restant trop discrets sur nos projets et sur l’orientation future de notre entreprise et de nos produits. C’est notre faute », glisse le dirigeant. Il ajoute « mais l’accusation selon laquelle Deno est en déclin ou en voie de disparition est tout à fait fausse ». Il précise, « depuis la sortie de Deno 2 en octobre dernier – il y a à peine plus de six mois ! – l’adoption de Deno a plus que doublé selon nos statistiques mensuelles d’utilisateurs actifs… La plateforme est devenue plus rapide, plus simple et plus performante. Deno est désormais utilisé plus largement – et plus sérieusement – que jamais. »
Un développeur et consultant à l’origine des critiques
Dans son blog, Ryan Dahl ne donne pas les sources des critiques. Mais le développeur et consultant britannique David Bushell avait annoncé le 28 avril dernier le déclin de Deno. « L’avenir de Deno Land Inc. ne s’annonce pas brillant », écrivait-il. Tout en soulignant, « leur produit commercial Deploy se présente comme un hébergement edge à « l’échelle mondiale »…Sauf que, pour être honnête, c’est un peu tiré par les cheveux ». David Bushell précise que Deploy était passé de 35 régions à seulement 12 en janvier 2024 et a ensuite déploré le ralentissement du développement de Fresh, le blocage de Deno KV, le chaos du packaging de Deno et le fait que les versions de Deno ne sont « que des correctifs de compatibilité Node » et « une course-poursuite sans fin. ». « Oui, Deno est terminé », a averti M. Bushell.
Mais Ryan Dahl a défendu Deno et ses technologies associées. « La solide compatibilité Node de Deno 2 a efficacement levé un obstacle majeur à l’adoption, débloquant un large éventail de cas d’utilisation sérieux », explique-t-il. Concernant la réduction du nombre de régions de Deploy, Dahl a déclaré que la plupart des applications n’ont pas besoin d’être exécutées partout. « Ils doivent être rapides, proches de leurs données, faciles à déboguer et conformes aux réglementations locales. Nous optimisons cela », justifie le dirigeant. Deploy a démarré en 2021 dans 25 régions, puis a été étendu à 35, et est désormais déployé dans six, a-t-il précisé. La réduction du nombre de régions est due à la fois au coût et à l’utilisation. Quant à KV, décrit par Ryan Dahl comme « un référentiel clé-valeur global et sans configuration, doté d’une API simple et de fonctionnalités temps réel », Dahl a reconnu qu’il ne résout pas tout. « Ce n’est pas une base de données polyvalente et elle ne remplace pas les systèmes relationnels pour la plupart des applications », a-t-il ajouté. « Les développeurs l’apprécient pour ce qu’il est : un référentiel global sans configuration, fonctionnel et simple.» Le responsable a indiqué que des efforts sont en cours pour répondre à des besoins plus larges en matière de gestion d’état, et que KV restera en version bêta le temps de corriger les bugs critiques et les problèmes de sécurité.
D’autres projets à venir pour Deno
Ryan Dahl a déclaré que Deno n’est plus seulement un environnement d’exécution, mais une plateforme complète. En cela elle offre des fonctionnalités telles que la prise en charge de TypeScript et JSX, des autorisations granulaires et un environnement sandbox pour une exécution sécurisée, un protocole de serveur de langage complet, une compatibilité Node/NPM renforcée et l’intégration de blocs-notes Jupyter. Deno a été fondamentalement construit sur des modules ECMAScript et des standards web, observe le co-fondateur.
Fresh, quant à lui, « se porte bien », constate-t-il. Des améliorations significatives seront apportées à Fresh 2, avec une version stable prévue pour la fin de l’année. La deuxième itération serait plus rapide, plus facile à utiliser et plus extensible. « Nous développons d’autres produits basés sur tout ce que nous avons appris de Deploy et de KV, qui ne sont pas encore disponibles. Ils visent à simplifier les applications persistantes et distribuées. Plus d’informations à ce sujet très prochainement », promet le dirigeant. « Nous reconnaissons que notre silence a parfois été source d’incertitude, et nous nous engageons à améliorer notre communication à mesure que nous progressons dans ces développements passionnants », a-t-il ajouté.
Ryan Dahl, fondateur de Deno, est monté au créneau pour rassurer sur la pérennité du runtime open source. Des rumeurs évoquaient une prochaine disparition de ce concurrent de Node.js.
Non, Deno ne va pas disparaître. Dans un blog, Ryan Dahl, créateur de Deno (et de Node.js) a réagi aux rumeurs parlant de la fin de ce runtime open source en estimant qu’elles étaient « largement exagérées ». Par ailleurs, le co-fondateur de Deno Land (une organisation supportant Deno) a répondu aux critiques concernant Deploy, le service d’hébergement en mode edge, KV la base de données clé-valeur et Fresh le framework web, ainsi qu’aux questions concernant la dynamique de Deno.
Il estime que certaines de ces critiques sont fondées. « En fait, je pense qu’il est juste de dire que nous avons contribué à créer une certaine peur et une certaine incertitude en restant trop discrets sur nos projets et sur l’orientation future de notre entreprise et de nos produits. C’est notre faute », glisse le dirigeant. Il ajoute « mais l’accusation selon laquelle Deno est en déclin ou en voie de disparition est tout à fait fausse ». Il précise, « depuis la sortie de Deno 2 en octobre dernier – il y a à peine plus de six mois ! – l’adoption de Deno a plus que doublé selon nos statistiques mensuelles d’utilisateurs actifs… La plateforme est devenue plus rapide, plus simple et plus performante. Deno est désormais utilisé plus largement – et plus sérieusement – que jamais. »
Un développeur et consultant à l’origine des critiques
Dans son blog, Ryan Dahl ne donne pas les sources des critiques. Mais le développeur et consultant britannique David Bushell avait annoncé le 28 avril dernier le déclin de Deno. « L’avenir de Deno Land Inc. ne s’annonce pas brillant », écrivait-il. Tout en soulignant, « leur produit commercial Deploy se présente comme un hébergement edge à « l’échelle mondiale »…Sauf que, pour être honnête, c’est un peu tiré par les cheveux ». David Bushell précise que Deploy était passé de 35 régions à seulement 12 en janvier 2024 et a ensuite déploré le ralentissement du développement de Fresh, le blocage de Deno KV, le chaos du packaging de Deno et le fait que les versions de Deno ne sont « que des correctifs de compatibilité Node » et « une course-poursuite sans fin. ». « Oui, Deno est terminé », a averti M. Bushell.
Mais Ryan Dahl a défendu Deno et ses technologies associées. « La solide compatibilité Node de Deno 2 a efficacement levé un obstacle majeur à l’adoption, débloquant un large éventail de cas d’utilisation sérieux », explique-t-il. Concernant la réduction du nombre de régions de Deploy, Dahl a déclaré que la plupart des applications n’ont pas besoin d’être exécutées partout. « Ils doivent être rapides, proches de leurs données, faciles à déboguer et conformes aux réglementations locales. Nous optimisons cela », justifie le dirigeant. Deploy a démarré en 2021 dans 25 régions, puis a été étendu à 35, et est désormais déployé dans six, a-t-il précisé. La réduction du nombre de régions est due à la fois au coût et à l’utilisation. Quant à KV, décrit par Ryan Dahl comme « un référentiel clé-valeur global et sans configuration, doté d’une API simple et de fonctionnalités temps réel », Dahl a reconnu qu’il ne résout pas tout. « Ce n’est pas une base de données polyvalente et elle ne remplace pas les systèmes relationnels pour la plupart des applications », a-t-il ajouté. « Les développeurs l’apprécient pour ce qu’il est : un référentiel global sans configuration, fonctionnel et simple.» Le responsable a indiqué que des efforts sont en cours pour répondre à des besoins plus larges en matière de gestion d’état, et que KV restera en version bêta le temps de corriger les bugs critiques et les problèmes de sécurité.
D’autres projets à venir pour Deno
Ryan Dahl a déclaré que Deno n’est plus seulement un environnement d’exécution, mais une plateforme complète. En cela elle offre des fonctionnalités telles que la prise en charge de TypeScript et JSX, des autorisations granulaires et un environnement sandbox pour une exécution sécurisée, un protocole de serveur de langage complet, une compatibilité Node/NPM renforcée et l’intégration de blocs-notes Jupyter. Deno a été fondamentalement construit sur des modules ECMAScript et des standards web, observe le co-fondateur.
Fresh, quant à lui, « se porte bien », constate-t-il. Des améliorations significatives seront apportées à Fresh 2, avec une version stable prévue pour la fin de l’année. La deuxième itération serait plus rapide, plus facile à utiliser et plus extensible. « Nous développons d’autres produits basés sur tout ce que nous avons appris de Deploy et de KV, qui ne sont pas encore disponibles. Ils visent à simplifier les applications persistantes et distribuées. Plus d’informations à ce sujet très prochainement », promet le dirigeant. « Nous reconnaissons que notre silence a parfois été source d’incertitude, et nous nous engageons à améliorer notre communication à mesure que nous progressons dans ces développements passionnants », a-t-il ajouté.
Une mauvaise implémentation d’OAuth dans la fonction File Picker de OneDrive donne un accès complet à l’ensemble des fichiers d’un ordinateur.
Rien de plus anodin que de passer par OneDrive pour télécharger un fichier sur ChatGPT, Slack ou Zoom. Enfin presque : plusieurs experts en sécurité ont alerté que les applications utilisant le sélecteur de fichiers (File Picker) du service de stockage cloud de Microsoft peuvent, dans certaines circonstances, obtenir un accès complet en lecture à un compte, en plus d’un accès en écriture.
« Le problème principal est lié au sélecteur de fichiers OneDrive de Microsoft, qui demande un accès étendu à l’ensemble du compte d’un utilisateur, même lorsque ce dernier essaie simplement de télécharger un seul fichier », explique Vijay Dilwale, consultant principal en matière de sécurité chez Black Duck. « L’expérience utilisateur donne l’impression que seul le fichier sélectionné est partagé, mais en réalité, l’application obtient souvent un accès complet en lecture (et parfois en écriture) à l’ensemble du contenu ». File Picker est un outil fourni par Microsoft qui propose aux sites web et aux applications web de s’intégrer au compte OneDrive d’un utilisateur pour lui permettre de télécharger, de parcourir et de sélectionner des fichiers de cette solution directement à partir de l’application.
Un piège OAuth aux privilèges trop élevés
Cet accès étendu découle d’une limitation de l’implémentation OAuth de Microsoft dans File Picker, que les chercheurs décrivent comme « un manque d’étendue des permissions à granularité fine ». Jason Soroko, senior fellow chez Sectigo, qualifie cet oubli de piège OAuth à privilèges excessifs. « Le sélecteur de fichiers OneDrive de Microsoft encourage les applications web tierces à demander des fichiers de grande taille », a-t-il déclaré. « Une fois émis, ces jetons à longue durée de vie sont souvent mis en cache dans localStorage ou dans des bases de données dorsales sans aucun chiffrement, ce qui permet potentiellement aux attaquants de parcourir les données d’une instance entière. » L’implémentation OAuth de OneDrive File Picker n’est pas assez fines au niveau des fichiers, ne permettant pas aux utilisateurs et aux développeurs de restreindre l’accès aux seuls fichiers explicitement sélectionnés.
Selon une étude menée par Oasis Security, toutes les versions de File Picker demandent des autorisations qui lisent l’intégralité du OneDrive de l’utilisateur pour le processus de téléchargement et écrivent n’importe où sur l’espace de stockage pour ce processus. Cependant, la version 7.0 du sélecteur de fichiers demande des autorisations de lecture et d’écriture pour le processus de téléchargement. « Le manque de précision des champs d’application pour le cas d’utilisation du sélecteur de fichiers empêche les utilisateurs de faire la distinction entre les applications malveillantes qui ciblent tous vos fichiers et les applications légitimes qui demandent des autorisations excessives simplement parce qu’il n’y a pas d’autre option sécurisée », ont prévenu les chercheurs d’Oasis Security dans un billet de blog.
Les fournisseurs d’applications web pas tirés d’affaire
Selon Eric Schwake, directeur de la stratégie de cybersécurité chez Salt Security, cela pourrait être une mauvaise nouvelle pour les équipes de sécurité. « Les secrets sensibles requis pour cet accès sont souvent stockés par défaut de manière non sécurisée », explique-t-il. Tout en ajoutant, « cette situation représente un défi majeur en matière de sécurité des API pour les équipes de sécurité, et avec des services tels que ChatGPT qui dépendent fortement des API pour accéder aux données des utilisateurs et les traiter, le risque est encore plus grand. » Une application web tierce qui se retrouve avec des données utilisateur « involontaires » à cause de cette situation devient une cible pour les acteurs de la menace et pourrait potentiellement enfreindre les règles de conformité rien qu’en ayant ce niveau d’accès.
Oasis Security note que des applications telles que ChatGPT (qui utilise File Picker v8.0), ClickUp, Trello, Zoom et Slack sont potentiellement concernées. Même des applications comme Phenome, un outil de recrutement, pourraient involontairement exposer des fichiers confidentiels si les utilisateurs téléchargent des CV à partir de comptes d’entreprise. « Les fournisseurs qui développent des applications Web sont en danger, car les incidents de sécurité pourraient avoir de graves conséquences, en faisant fuir un grand nombre de fichiers d’un grand nombre de leurs utilisateurs », notent les chercheurs d’Oasis qui ont prévenu Microsoft.
En attendant la réponse de Microsoft, remonter la vigilance
La firme de Redmond a reconnu le problème et indiqué qu’il pourrait envisager d’apporter des améliorations à l’avenir. Dans l’intervalle, Oasis Security a recommandé quelques mesures d’atténuation pour les applications web, notamment la suppression de l’option de téléchargement de fichiers à l’aide de OneDrive via OAuth jusqu’à ce que Microsoft corrige le bug, et l’exploration de solutions de contournement plus simples, comme la prise en charge des liens de fichiers partagés « en mode lecture uniquement » à partir de OneDrive.
Oasis Security a également noté que les solutions File Picker sur d’autres services d’hébergement de fichiers tels que Google Drive et Dropbox peuvent être utilisées comme alternative car elles ne souffrent pas de ce problème. « Les utilisateurs doivent partir du principe que chaque plug-in SaaS qu’ils autorisent possède les clés de leurs joyaux personnels ou de l’entreprise, sauf preuve du contraire », a déclaré M. Soroko. Les équipes de sécurité doivent appliquer le « consentement de l’administrateur » ou des politiques d’accès conditionnel qui bloquent les applications demandant tout ce qui va au-delà de Files.Read. M. Schwake a ajouté qu’une gouvernance plus forte des API pour s’assurer que toutes les permissions des API sont gérées méticuleusement, ce qui inclut le respect du moindre privilège et la gestion sécurisée des jetons, est nécessaire pour éviter une exposition importante des données.
La fonctionnalité Recall dans Windows 11 ne satisfait pas tout le monde. L’application Signal a ainsi décidé de bloquer les captures d’écran de l’application pour garantir la protection des conversations.
Malgré avoir revu sa copie plusieurs fois, l’application Recall de Microsoft basée sur l’IA continue à faire parler d’elle. En effet, l’éditeur de la messagerie sécurisée Signal a décidé de bloquer les captures d’écran de Recall dans son application dekstop. Pour mémoire, Recall est accessible sur les PC Copilot+ (comprenant un NPU performant) sous Windows 11 version 24H2 et prend continuellement des instantanées de l’écran pour créer une chronologie consultable par les utilisateurs. Des actions qui ont suscité la controverse sur le plan de la protection de la vie privée et la firme de Redmond a considérablement modifié l’architecture de l’application.
Déjà, la fonction est dorénavant facultative, elle nécessite l’authentification biométrique Windows Hello, chiffre tous les clichés localement, filtre les données sensibles telles que les numéros de carte de crédit, et permet aux utilisateurs d’exclure de la capture des applications ou des sites web spécifiques.
Un paramètre supplémentaire dans Signal
De son côté, Signal a été plus proactif en introduisant un paramètre « Sécurité de l’écran » dans son application de bureau. Il est spécialement conçu pour protéger ses utilisateurs contre Recall. Activée par défaut sur Windows 11, cette fonction utilise un indicateur de gestion des droits numériques (DRM) pour empêcher toute application, y compris Windows Recall, de réaliser des captures d’écran des discussions sur Signal. Lorsque Recall ou d’autres outils tentent de capturer la fenêtre de Signal, ils produisent une image vide.
Dans un billet de blog, Signal explique la raison de ce blocage : « même si Microsoft a procédé à plusieurs ajustements au cours des douze derniers mois en réponse à des commentaires critiques, la version remaniée de Recall met toujours en danger tout contenu affiché dans des applications de protection de la vie privée telles que Signal. Par conséquent, nous activons par défaut une couche de protection supplémentaire sur Windows 11 afin de préserver la sécurité de Signal Desktop sur cette plateforme, même si cela implique des compromis en termes de convivialité. Microsoft ne nous a tout simplement pas laissé d’autre choix ». En fait, il existe bien une autre option : Desktop Linux.
L’agence de cybersécurité américaine s’inquiète de la capacité des pirates à tirer parti d’une vulnérabilité sévère affectant Commvault pour voler des secrets d’environnements applicatifs SaaS dont Microsoft 365. La CISA enjoint les entreprises à appliquer les correctifs disponibles.
Régulièrement, la CISA lance des avertissement sur des failles exploitées. Selon un avis de l’agence de cybersécurité américaine, des acteurs malveillants pourraient avoir accédé à des secrets de clients à partir de la solution de sauvegarde Metallic Microsoft 365 de Commvault hébergée dans Azure. L’accès non autorisé à ces secrets a été réalisé grâce à un exploit zero day. En février, Microsoft a averti Commvault de l’existence d’une grave faille non spécifiée (répertoriée en tant que CVE-2025-3928) affectant sa solution Web Server. Par ailleurs, un acteur bénéficiant d’un soutien étatique l’exploitait activement pour accéder aux environnements Azure. Thomas Richards, directeur de la pratique de sécurité des infrastructures chez Black Duck, a déclaré que les flux SaaS sont intrinsèquement vulnérables. « Si les solutions SaaS déchargent les entreprises des tâches administratives liées à l’hébergement et à l’infrastructure, le revers de la médaille est que les sociétés n’ont aucun moyen de sécuriser ou de contrôler ces environnements », a-t-il déclaré. « Lorsque Commvault a été compromis, les victimes n’étaient même pas conscientes de l’existence d’une faille. »
Une CVE-2023-3928 sévère
Dans son avis, la CISA indique qu’elle soupçonne l’exploitation de CVE-2025-3928 de faire partie d’une campagne plus large visant les applications SaaS avec des paramètres par défaut et des autorisations de haut niveau. Commentant la note de la CISA, James Maude, Field CTO chez BeyondTrust, a déclaré : « Cela met en évidence les risques liés au fait de permettre à des tiers d’accéder de manière privilégiée à votre environnement, leur violation devenant votre violation […] Alors que de nombreuses entreprises disposent de contrôles solides pour émettre et gérer l’accès aux comptes humains utilisés par les entrepreneurs et les tiers, l’histoire est souvent très différente lorsqu’il s’agit d’identités non humaines et de secrets qui permettent des interactions machine-machine. » D’après l’enquête de Commvault, les acteurs étatiques ont obtenu, par le biais d’un abus zero-day de CVE-2025-3928, un sous-ensemble d’identifiants d’applications que certains clients de Commvault utilisaient pour authentifier leurs environnements M365.
La faille de haute sévérité (CVSS 8.7/10) affectant Commvault Web Server donnait aux pirates la capacité de créer et d’exécuter des webshells dans des environnements compromis. Le 28 avril 2025, la CISA a ajouté les trois vulnérabilités à son catalogue des vulnérabilités exploitées connues (KEV), donnant aux agences du FCEB [federal vivilian executive branch] jusqu’au 19 mai 2025 pour corriger leurs systèmes dans le cadre de la directive visant à remédier aux vulnérabilités dangereuses dans les agences civiles. L’entreprise a corrigé la faille rapidement après avoir été signalée par Microsoft en février. Les correctifs ont été déployés dans les versions 11.36.46, 11.32.89, 11.28.141 et 11.20.217 de Commvault.
La CISA demande l’application des correctifs
La CISA a recommandé aux entreprises d’appliquer immédiatement les correctifs ainsi que d’autres mesures d’atténuation, notamment la surveillance et l’examen des journaux d’audit de Microsoft Entra (ex Azure AD), de l’ouverture de session Entra et des journaux d’audit unifiés, la mise en œuvre d’une politique d’accès conditionnel pour limiter l’authentification au sein des applications à locataire unique, et la rotation des secrets d’application et des informations d’identification sur les applications Commvault Metallic. Omri Weinberg, CEO de DoControl, associe cet incident à une tendance plus large. « Les attaquants passent d’attaques basées sur les points d’extrémité et le réseau à l’exploitation d’environnements SaaS sur-autorisés et d’applications cloud mal configurées », a déclaré le dirigeant. Il ajoute,« les équipes de sécurité doivent traiter les SaaS avec la même rigueur que l’infrastructure traditionnelle, en commençant par une solide gouvernance des accès, une surveillance continue des intégrations d’applications tierces et une limitation du rayon d’action grâce à un accès à moindre privilège. »
L’enquête interne n’a pas révélé d’accès non autorisé aux données de sauvegarde des clients que Commvault stocke et protège, a déclaré l’entreprise dans un communiqué début mai, ajoutant qu’elle ne s’attendait à aucun impact matériel sur les opérations commerciales de Commvault ou sur sa capacité à fournir des produits et des services.
Alors que les pertes liées à la cyberattaque atteignent 360 M€, l’enseigne de distribution britannique réagit en affirmant sa volonté de comprimer en six mois le programme de mise à niveau de ses SI, qui devait à l’origine durer deux ans.
Quelques semaines après avoir subi l’une des cyberattaques les plus perturbatrices de l’histoire du Royaume-Uni, la chaîne de magasins Marks & Spencer (M&S) a expliqué que sa réaction consisterait à accélérer la refonte de son IT, un programme à l’origine prévu sur deux ans, afin de l’achever en six mois seulement.Étant donné que l’entreprise s’attend à ce que les séquelles de l’attaque, notamment l’arrêt des achats en ligne, se poursuivent jusqu’en juillet, le fait de comprimer les nouvelles dépenses en matière d’informatique et d’infrastructure numérique en quelques mois pourrait sembler ambitieux aux investisseurs. Mais cela permet à M&S de donner une tournure positive à la dernière communication financière de la société, qui a été obligée de reconnaître que la cyberattaque, qui a frappé la société à partir du 19 avril, amputera ses bénéfices de 300 millions de livres sterling (plus de 350 M€) pour l’année à venir. La chaine de retail a réalisé un chiffre d’affaires de 16,5 Md€ lors de son dernier exercice fiscal, pour un bénéfice avant impôts de 609 M€.Rassurer les actionnaires« Nous cherchons à tirer le meilleur parti de l’opportunité d’accélérer le rythme de notre transformation technologique et avons trouvé de nouvelles méthodes de travail innovantes », a assuré le PDG de M&S, Stuart Machin, sans toutefois détailler plus avant ni les attendus de cette transformation, ni la nature de ces nouvelles méthodes de travail. « Nous nous concentrons sur le rétablissement, la restauration de nos systèmes, de nos opérations et de notre offre à la clientèle pendant le reste du premier semestre, dans le but de sortir de cette période avec une entreprise beaucoup plus forte », a ajouté le dirigeant.Malgré l’impact stupéfiant de l’attaque sur les bénéfices, de loin la somme la plus importante jamais admise publiquement par une entreprise britannique à la suite de ce type d’événement, les actionnaires seront rassurés par le fait que Stuart Machin pense que le coût final de l’incident « sera réduit grâce à la gestion des coûts, à l’assurance et à d’autres actions commerciales ». Il a ajouté que ces coûts seront « présentés séparément en tant qu’élément d’ajustement ».Bien entendu, ces déclarations du PDG de Marks & Spencer ne tiennent pas compte des coûts liés à une éventuelle action en justice concernant la violation des données des clients que l’entreprise a admis avoir subie lors de l’attaque.Fermeture applicative quasi complèteDans les jours qui ont suivi l’attaque qui s’est déroulée lors du week-end de Pâques, l’entreprise a fermé l’ensemble de ses applications internes et en ligne, à l’exception des terminaux de point de vente en magasins.Ce shutdown a notamment touché son système de commande en ligne (web et app), son système « click-and-collect », des applications utilisées en interne par le personnel et celles exploitées par les approvisionnements et la logistique. Ce dernier point a conduit, dans certains magasins, à quelques étagères vides.L’attaque était un ransomware classique, de type « big game » (ciblant donc de grandes organisations), dont certains pensent qu’il est lié au groupe « Scattered Spider », qui utilise la plateforme DragonForce de ransomware-as-a-service (RaaS). Rien de tout cela n’a toutefois été confirmé et on ne sait pas si M&S a versé une rançon.Attaque par ingénierie sociale sur un prestataireLa récente communication de la chaine britannique a révélé un détail important : les attaquants ont compromis M&S après une attaque d’ingénierie sociale sur les employés d’un fournisseur tiers, dont le nom n’a pas été précisé. Selon Stuart Machin, l’attaque trouverait son origine dans une « erreur humaine », ce qui pourrait donner une idée de l’orientation des futurs investissements.Sur la base d’une source unique, Reuters a suggéré que ce fournisseur pourrait être l’ESN indienne Tata Consulting Services (TCS), qui est également le prestataire d’un autre retailer britannique, le Co-operative Group. Or, la Co-op a été touchée par une attaque de ransomware similaire, quoique moins grave, au cours de la même semaine. Là encore, l’information n’a pas été confirmée.Au début du mois de mai, le National Cyber Security Centre (NCSC) britannique a averti les commerçants que les attaquants exploitaient de nouveaux moyens de compromission de leurs cibles, notamment par l’intermédiaire des équipes d’assistance et des appels à ces services.Investir, mais dans quoi ?M&S semble avoir décidé de profiter de cette crise pour mener à bien sa stratégie de transformation plus rapidement que prévu. Le PDG Stuart Machin n’a pas donné de détails sur ces plans, mais au cours des dernières années, M&S a annoncé une série d’initiatives, y compris une utilisation accrue des systèmes cloud et, évidemment, de l’IA.Du point de vue de l’efficacité, cette stratégie est logique. Cependant, ce que les PDG entendent généralement par transformation numérique se traduit par une expansion des technologies conçues pour engager les clients. L’inconvénient ? Cela risque d’augmenter la surface d’attaque d’une organisation et sa vulnérabilité aux perturbations futures.Cette stratégie – d’aucuns diraient cette pirouette – est-elle donc pertinente ? Pour Jordan Avnaim, RSSI du fournisseur de solutions de sécurité Entrust, « si l’expansion numérique peut élargir la surface d’attaque, elle offre également l’occasion de moderniser les systèmes existants, de mettre en oeuvre le Zero Trust et de faire de la cybersécurité une priorité du conseil d’administration ».