3 points par GN⁺ 5 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Des dizaines de projets open source hébergés sur GitHub ont été compromis par des hackers, qui ont injecté dans le code un malware voleur de mots de passe, poussant Microsoft à bloquer l’accès à ces projets et à lancer une enquête
  • Une grande partie des projets touchés sont liés à des outils utilisés pour coder avec le service cloud Azure et des apps de développement IA comme Claude Code, Gemini CLI et VS Code
  • Lorsqu’un utilisateur ouvre un outil infecté dans une app de code assisté par IA, le malware agit de manière à voler des mots de passe et des identifiants sensibles
  • Selon GitHub, au moins 70 projets ont été désactivés, et Microsoft a temporairement retiré certains dépôts avant de les restaurer après examen
  • Ce cas est un exemple récent d’attaque de la chaîne d’approvisionnement visant du code open source populaire, et il s’agirait de la deuxième compromission en quelques semaines d’un projet open source de Microsoft

Vue d’ensemble de l’incident et réponse de Microsoft

  • Microsoft enquête sur les circonstances de la compromission après avoir confirmé qu’un hacker a compromis des projets et injecté dans leur code un malware voleur de mots de passe, ce qui a conduit l’entreprise à bloquer l’accès à des dizaines de projets open source sur GitHub
  • Une grande partie des projets touchés sont liés à des outils utilisés pour coder avec le service cloud Azure et des apps de développement IA comme Claude Code, l’interface en ligne de commande de Gemini et VS Code
  • Il n’a pas été immédiatement possible de déterminer combien de personnes ont effectivement téléchargé les outils touchés
  • Microsoft a confirmé avoir retiré les dépôts, une information rapportée pour la première fois par 404 Media
    • Le porte-parole de Microsoft, Ben Hope : « Certains dépôts ont été temporairement retirés pendant que nous enquêtions sur un contenu potentiellement malveillant »
    • Certains dépôts ont été restaurés après examen, tandis que d’autres peuvent rester hors ligne pendant la poursuite des opérations
    • Un petit nombre de clients susceptibles d’avoir téléchargé du contenu depuis les dépôts touchés a été notifié, et Microsoft prévoit de les contacter directement via ses canaux de support habituels si des actions supplémentaires s’avèrent nécessaires
  • En réponse aux questions de TechCrunch, Microsoft n’a pas immédiatement fourni de chiffre précis sur les clients affectés

Fonctionnement du malware

  • L’entreprise de sécurité Cloudsmith et le site communautaire d’analyse de malware OpenSourceMalware ont été parmi les premiers à signaler ce piratage
  • Le malware fonctionne de façon à voler des mots de passe et d’autres identifiants sensibles lorsqu’un utilisateur ouvre l’outil infecté dans une app de code assisté par IA
  • Sur GitHub, le site d’hébergement de code appartenant à Microsoft, au moins 70 projets apparaissent comme « désactivés »
    • Message affiché : « L’accès à ce dépôt a été désactivé par le personnel de GitHub en raison d’une violation des conditions d’utilisation de GitHub »

Le contexte d’une attaque de la chaîne d’approvisionnement

  • Il s’agit du dernier exemple en date d’une série d’incidents survenus ces derniers mois, dans lesquels des projets open source largement utilisés sont compromis afin d’infecter d’un malware de nombreux utilisateurs ayant installé ce code
  • Ces piratages sont appelés attaques de la chaîne d’approvisionnement et visent du code largement utilisé dans de nombreux produits logiciels ou par certaines catégories d’utilisateurs
    • Ces cibles peuvent être avantageuses pour les hackers lorsqu’elles donnent accès à des systèmes cloud et à de grands volumes de données clients
  • Il n’est pas rare que des développeurs uniques de projets open source soient pris pour cible, parfois dans le cadre d’efforts de longue haleine destinés à gagner leur confiance
  • En revanche, le fait qu’une grande entreprise technologique comme Microsoft, qui dispose de ressources pour se défendre contre ce type d’attaque, soit compromise reste inhabituel

Signes de compromissions répétées

  • Selon Ars Technica, il s’agirait du deuxième cas connu en quelques semaines de compromission d’un projet open source de Microsoft
  • À la mi-mai, des chercheurs en sécurité ont indiqué que le projet open source Durable Task de Microsoft, qui aide les développeurs à créer des apps, semblait avoir été piraté
  • OpenSourceMalware a décrit ce dernier incident comme une « re-compromission » du projet Durable Task
    • Cela laisse entendre que Microsoft n’a peut-être pas complètement éliminé les hackers lors de la première tentative, ou qu’il pourrait s’agir d’une nouvelle compromission totalement distincte

2 commentaires

 
brainer 1 시간 전

Est-ce que cela pourrait être la raison pour laquelle je continue à recevoir des tentatives de connexion à mon compte Microsoft, même après avoir changé mon mot de passe ?

 
GN⁺ 5 시간 전
Commentaires sur Hacker News
  • Ce n’est qu’une supposition et une observation personnelle, mais l’ancien modèle RBAC semblait déjà presque en ruine, et maintenant il paraît complètement cassé
    J’ai l’impression que le risque de chaîne d’approvisionnement a fortement augmenté dans les entreprises, car les assistants de code et les ingénieurs touchent simultanément à plusieurs projets sans lien entre eux, et mènent même des expérimentations qu’ils n’avaient auparavant pas le temps de faire
    Je ne dis pas que c’est directement lié, mais je pense qu’il y a un impact, et le fait que, dans beaucoup d’endroits aujourd’hui, des développeurs et des managers encouragent à faire à la va-vite du codage IA sur des machines personnelles risque aussi de devenir un problème
    Il est difficile de croire qu’il n’y a pas de tendance commune entre les récents incidents de chaîne d’approvisionnement, et s’il existe des groupes de pirates spécialisés dans ce type d’attaque, c’est aussi parce que la récompense est élevée

    • Pour être clair, le commentaire d’origine ne disait pas que c’était lié avec certitude, mais cela n’a absolument rien à voir avec l’IA ou le vibe coding
      C’est dans la continuité de l’absence de sécurité lors de l’installation des dépendances côté développeur, un problème ancien, ainsi que du ver Shai Halud
      Les pirates ont compris qu’il est facile de pousser les développeurs à installer quelque chose, et que les postes des développeurs sont des cibles idéales parce qu’ils contiennent beaucoup d’informations sensibles comme des identifiants, des CLI cloud ou MCP
    • C’est pareil dans notre entreprise. Il y a une sorte de doctrine du type « si on n’en fait pas un maximum avec l’IA, on va se faire distancer »
      On a l’impression de rejouer exactement la précédente surchauffe autour de l’IoT, en voulant courir devant tout le monde sans se soucier de la sécurité
    • Cela fait des années que je dis que nous avons beaucoup trop peu de personnel par rapport au nombre total de projets, mais la direction répondait que la plupart des projets étaient inactifs, donc qu’il était acceptable d’en confier beaucoup à chaque personne
      Voilà le résultat
    • Je me demande si cela signifie qu’il faut remplacer le contrôle d’accès basé sur les rôles, c’est-à-dire RBAC, par autre chose, ou si cela veut dire que certains modèles RBAC actuellement utilisés sont cassés
      Personnellement, même si je trouve le nom un peu trompeur, je pense que le modèle de sécurité fondé sur les capacités représente l’avenir
  • Dès le titre, la formulation est biaisée, et le corps de l’article donne aussi l’impression que c’est la faute de l’open source
    Et c’est encore plus absurde parce qu’il semble ensuite faire porter à Microsoft la responsabilité de cette tentative d’attaque de chaîne d’approvisionnement
    Il dit Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch., mais TechCrunch n’explique pas que c’est ainsi que l’open source fonctionne à l’origine
    J’aime bien critiquer Microsoft quand c’est mérité, mais dans ce cas je pense que Microsoft a pris des mesures sûres et appropriées
    L’article est écrit comme si tout était de la faute de Microsoft et comme si le fait d’avoir limité l’ampleur de la compromission était presque honteux
    L’expression steal passwords of AI developers laisse aussi une ambiguïté étrange : s’agit-il de « développeurs IA » ou de « développeurs qui utilisent l’IA » ?
    L’explication de l’attaque de chaîne d’approvisionnement ne décrit pas vraiment ce que cela signifie, elle ne parle que du résultat et des raisons liées à la surface d’attaque, donc je trouve cette couverture très mauvaise

    • TechCrunch est très négligent et difficile à considérer comme fiable
      Je les ai déjà vus inventer des faits à des fins d’optimisation pour les moteurs de recherche en couvrant un sujet sur lequel j’avais directement travaillé, et il n’y avait aucun moyen de les faire corriger
    • Je ne vois pas ce qui pose problème dans cette phrase
      Microsoft a un problème organisationnel de sécurité, et le fait de ne pas avoir correctement verrouillé GitHub Actions et d’avoir laissé des demandes de fusion contourner le CI/CD a aidé à cela, ou l’a mis en lumière
      C’est un problème propre à Microsoft qui existait déjà avant l’IA, et ce n’est même pas un sujet de débat : https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
      À l’ère de l’IA, ce problème est devenu endémique et se retrouve militarisé
    • Dans ce cas, je suis curieux de savoir comment tu interprètes l’analyse post-mortem
      Qu’est-ce qui s’est réellement passé, et comment faudrait-il lire cela ?
  • Voici des articles qui semblent liés
    https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
    https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
    https://news.ycombinator.com/item?id=48416155
    https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)

    • Ils ont créé un outil d’atténuation capable de corriger ou supprimer le ver dans tous les dépôts infectés, et ont aussi écrit un billet à ce sujet
      Lundi, la campagne Hades a ajouté la prise en charge de Composer, Go et Pip. Avant cela, elle ne prenait en charge que NPM et les éditeurs assistants IA, avec aussi Ruby, mais il semble qu’aujourd’hui presque plus personne n’utilise Rubygems
      Ce que même Microsoft rate, c’est qu’il s’agit du premier ver à s’exécuter sur toutes les plateformes de l’écosystème logiciel. Il tourne sur les machines des développeurs, les serveurs et les runners CI/CD, et propage le ver à tous les dépôts auxquels ces machines ont accès
      Pour vaincre ce ver, il faudrait éteindre simultanément à 100 % tous les ordinateurs, ainsi qu’AWS EC2, Google Cloud Platform, Azure et les clusters Kubernetes. Il se propage littéralement à travers toute l’infrastructure
      Comme toujours avec les malwares d’APT28, le kill switch consiste à définir la langue de l’hôte sur ru_RU.KOI8-R, c’est-à-dire à régler la variable d’environnement LANG. Cela désactive le mécanisme de propagation
      Outil d’atténuation : https://github.com/cookiengineer/antimiasma
      Billet de blog : https://cookie.engineer/weblog/articles/malware-insights-mia...
  • Je soupçonne fortement qu’il s’agisse d’un cas d’utilisation désordonnée de personal access tokens traditionnels
    Si vous comptez transmettre des tokens à des agents IA sur un dispositif openclaw douteux, il faut utiliser des tokens à granularité fine
    Mon compte GitHub s’étend sur trois organisations aux politiques complètement différentes, et je trouve encore un peu surprenant que les tokens classic soient toujours autorisés
    À minima, il faudrait imposer une autorisation manuelle pour chaque organisation

    • Je pense que les agents IA devraient constituer des principaux de sécurité distincts, et recevoir des tokens d’accès dédiés uniquement pour les dépôts ou organisations nécessaires
      Transmettre à des agents IA des tokens d’accès “frappés” pour des comptes humains donne l’impression d’une nouvelle version du « mot de passe noté sur un Post-it »
    • C’est vrai, mais la gestion des permissions des tokens à granularité fine relève presque du cauchemar
      Il n’est pas facile de déterminer exactement ce qui est nécessaire et correct pour telle ou telle tâche
      En plus, les développeurs ont souvent tendance à considérer qu’il est plus important de se concentrer sur le code que sur les permissions, et que les permissions relèvent de la responsabilité de quelqu’un d’autre
    • Si la cause est bien un classic PAT, cela ne veut-il pas dire que, au-delà des dépôts GitHub récents, d’autres dépôts privés pourraient être en danger ?
    • J’utilise un token classic d’un compte à faibles privilèges pour le scraping de dépôts publics
      Des permissions au niveau de l’organisation conviendraient probablement très bien à mon usage
  • Hier, j’ai dû réinitialiser le mot de passe de mon compte Microsoft personnel. J’avais reçu une alerte d’authentification à deux facteurs à cause d’une tentative de connexion depuis la Roumanie
    Je ne sais pas comment ils ont obtenu le mot de passe. Le seul produit Microsoft que j’ai, c’est une Xbox
    Même avant l’IA, Microsoft donnait déjà l’impression d’être une passoire, et j’aimerais bien que mon entreprise se détache de Microsoft, mais elle est déjà pieds et poings liés

    • Il est presque impossible de configurer un compte Microsoft personnel pour ne pas autoriser la connexion sans mot de passe
      Donc, en pratique, votre compte est probablement configuré ainsi, et la requête MFA que vous avez reçue n’était sans doute pas une authentification à deux facteurs, mais simplement une tentative d’accès au compte
      J’en recevais aussi plusieurs fois par jour, et j’ai découvert que si l’on configure l’application Microsoft Authenticator sur son téléphone, le fait d’avoir un verrouillage comme la reconnaissance faciale, l’empreinte ou un PIN force le basculement vers le mode sans mot de passe
      Pour contourner cela, il faut désactiver tous ces verrouillages pendant la configuration du compte dans l’application Authenticator
      J’utilise peu mon compte Microsoft, donc j’ai fini par revenir à une vérification par e-mail séparé au lieu d’Authenticator
      Le simple fait que cela fonctionne de cette manière est délirant, mais j’imagine que quelqu’un chez Microsoft doit être en train de remplir ses KPI de connexion sans mot de passe
    • Dans certaines organisations où j’ai travaillé, on faisait apparaître des invites d’authentification multifacteur indépendamment du fait que le mot de passe soit correct ou non. Le but était de faire perdre encore plus de temps à l’attaquant
      Je ne sais pas si Microsoft fait la même chose
  • J’aimerais que quelqu’un m’explique comment il est possible d’ajouter des fichiers obfusqués à autant de dépôts. Il n’y a donc aucune revue de code ?
    Le titre est aussi trompeur. Le setup consiste à ajouter une configuration qui sera exécutée automatiquement par les personnes travaillant sur le dépôt, et ces personnes doivent utiliser VSCode, Cursor, Claude ou Gemini
    Ceux qui utilisent Codex, opencode ou d’autres harnais d’exécution devraient sans doute être en sécurité
    Détails : https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

    • J’ai un ami proche qui travaille dans une grande entreprise. Je ne peux pas dire laquelle, mais c’est une société du S&P 500
      Il y travaille depuis assez longtemps et pourtant il n’a jamais vu à quoi ressemble réellement le projet dont il a la charge ; il a cloné le dépôt et connaît le langage utilisé, mais pas grand-chose de plus
      Tout est grossièrement assemblé à l’IA. Ce projet est le système d’authentification et d’autorisation de l’ensemble des produits de l’entreprise
      Selon lui : « Je passe mes journées à appuyer sur Tab et, dans les revues, j’écris “comportement intentionnel”. Les revues aussi sont entièrement faites par l’IA, sans intervention humaine. Le CEO et le CTO demandent sérieusement de travailler comme ça. Quand quelque chose casse, personne ne sait comment ça fonctionne, parce que personne n’a réellement lu le code. L’évaluation des performances se fait non pas sur ce qu’on a produit, mais sur le nombre de tokens utilisés. »
      Il n’est pas absurde de penser que beaucoup d’entreprises fonctionnent aujourd’hui comme ça et qu’il n’y a pas de vraie revue de code
    • Un grand nombre des commits malveillants apparaissent avec l’auteur github-actions
      Cela signifie qu’ils s’authentifient du côté de la CI/CD interne de GitHub, et il y en a tellement qu’il est difficile pour n’importe quel outil d’automatisation de repérer le poison dans une montagne de paille
      C’est pourquoi cela est lié à la compromission de sécurité de GitHub de septembre 2025
      « Les étoiles GitHub des cinq dépôts totalisent 1 459, et mantine-datatable à lui seul en représente 1 225. Les étoiles sont un indicateur de substitution très grossier du nombre de développeurs ayant checkouté le code source en local, et c’est le public visé par cette attaque. »
      « Tous les commits n’étaient pas signés, utilisaient l’identité github-actions, avaient des messages du type chore: update dependencies [skip ci] et laissaient la même empreinte de six fichiers. Le fait de balayer cinq dépôts en 49 secondes montre qu’il ne s’agit pas de commits humains mais d’automatisation. Cela correspond à l’auto-propagation de Shai-Hulud, qui collecte des tokens GitHub dotés de droits d’écriture lors d’une infection précédente, puis injecte une charge persistante dans tous les dépôts accessibles par ces tokens. »
      https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
      Fonctionnement réel : https://safedep.io/config-files-that-run-code/
      Je n’ai aucun lien avec ces gens, mais c’est l’explication la plus simple et la plus détaillée que j’aie trouvée de ce qui se passe actuellement
    • Un collègue a sérieusement demandé : « Maintenant qu’on génère l’essentiel du code, qui est-ce qui lit vraiment tout ce code ? »
      C’est une petite entreprise, mais chez certaines personnes, l’impulsion de faire confiance à l’IA comme à un oracle semble presque religieuse
      Moi, je lis plus de 90 % du code que je génère comme si je faisais la revue du code d’un développeur junior
      En ce moment, je fais du vibe coding assez intensif sur une nouvelle fonctionnalité, mais dès que les PR GitHub refonctionneront, je lirai tout à fond
    • Si un compte capable de pousser sur le dépôt a été compromis, une revue de PR n’aurait probablement pas été nécessaire
  • C’est à ce genre de personnes qu’on confie les certificats CA racine de Secure Boot ?

    • Vous parlez de cette entreprise qui a échoué à l’examen de sécurité de 2023 ? [0]
      « Chacune des failles décrites ci-dessus peut, prise isolément, sembler explicable. Mais mises bout à bout, elles révèlent une défaillance des contrôles organisationnels, de la gouvernance et de la culture d’entreprise de Microsoft en matière de sécurité. »
      Les produits et services de Microsoft sont partout. C’est l’une des entreprises technologiques les plus importantes au monde, peut-être même la plus importante. Une telle position implique une responsabilité mondiale de tout premier ordre. Il faut une culture d’entreprise responsable et centrée sur la sécurité, portée depuis le CEO, afin que des considérations financières ou de mise sur le marché ne viennent pas affaiblir la cybersécurité ni la protection des clients de Microsoft.
      « Malheureusement, tout au long de cet examen, la commission a identifié une série de décisions opérationnelles et stratégiques qui témoignent d’une culture d’entreprise chez Microsoft où les investissements en sécurité et la gestion rigoureuse des risques étaient tous deux relégués à un faible niveau de priorité. Ces décisions ont causé des coûts et des dommages importants aux clients de Microsoft à travers le monde. »
      « La commission est convaincue que Microsoft doit corriger sa culture de la sécurité. »
      [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
    • La racine de confiance de Secure Boot est en général non pas un certificat Microsoft mais un certificat OEM, ce qui est peut-être encore pire : https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
      Quoi qu’il en soit, vous êtes libre de supprimer les certificats Microsoft et d’enregistrer le vôtre
    • Ce n’est pas tant une question de « confiance » que d’« être obligé de l’accepter »
      Cet incident ne fait que prolonger les antécédents de Microsoft, qui relèvent moins d’une entreprise sérieuse sur la sécurité que d’un problème de sécurité en soi
    • Faire confiance à Microsoft sur les sujets de sécurité, c’est de la naïveté
      Ils ont montré à de nombreuses reprises au cours des 40 dernières années qu’ils s’en moquent
  • J’ai peut-être mis du temps à m’en rendre compte, mais même si vous ne voulez pas utiliser l’IA pour des raisons du genre « le code est mauvais », je dis depuis un moment qu’il faut au moins envisager de l’utiliser pour les audits de sécurité
    Il faut au minimum utiliser des outils qui analysent le code à la recherche de vulnérabilités
    Le vecteur d’attaque ne se limite pas aux plugins qui volent des données : il inclut aussi les vulnérabilités 0-day de presque tous les logiciels que vous utilisez, ainsi que des script kiddies armés de LLM qui attaquent vos services web
    Les piratages vont augmenter et empirer, donc il faut reconsidérer toute organisation qui n’investit pas dans les audits de cybersécurité et les outils d’audit

  • Personne ne devrait faire npm install ou pip install sur sa propre machine
    Utiliser systématiquement un sandboxing adapté (https://github.com/ashishb/amazing-sandbox) peut fortement réduire l’ampleur des dégâts de ce type d’attaque

    • Le backend Docker exécute-t-il les commandes dans des conteneurs rootless ?
      J’ai parcouru le code, mais je n’ai rien vu qui permette de le confirmer
    • Docker n’est pas une véritable stratégie de sandboxing
    • Si l’idée est de ne pas faire npm install ou pip install sur sa propre machine, quelle alternative propose-t-on ?
      Cela veut-il dire qu’il ne faut jamais les installer en dehors d’un sandbox ?
    • Y a-t-il aussi ici un composant de détection ?
      Développer dans un sandbox, c’est bien, mais l’étape suivante reste le déploiement en production
      Comment savoir si un comportement malveillant s’est produit dans le sandbox, afin d’éviter de déployer plus loin ce code malveillant ?
  • Le fait que GitHub de Microsoft ait suspendu l’accès de Microsoft Azure et de tous les autres utilisateurs à la base de code Microsoft pour violation des conditions d’utilisation est excessivement drôle
    Ça permet de vraiment prendre la mesure de cet organigramme : https://www.businessinsider.com/big-tech-org-charts-2011-6