GitHub bloque un chercheur en sécurité qui a publié des exploits zero-day Windows

• Le compte GitHub de Nightmare-Eclipse a été bloqué, et il affirme avoir déplacé son espace de travail vers GitLab en dénonçant une mesure de rétorsion de Microsoft
• Le conflit a véritablement éclaté début avril avec la publication du zero-day BlueHammer, Eclipse affirmant que Microsoft avait ignoré son signalement et sa demande de récompense
• Microsoft n’a pas révélé la raison ni le déroulement du blocage, laissant planer le doute sur la question de la divulgation non standard ou sur un échec des procédures de signalement et de récompense
• Eclipse a publié six zero-days Windows, dont BlueHammer, RedSun et UnDefend, et certains sont activement exploités en conditions réelles
• Le blocage GitHub ne suffit pas à empêcher l’exploitation d’un code déjà publié et met en lumière les limites des procédures de divulgation et de correctif à l’heure où l’IA accélère la découverte de vulnérabilités

---

Blocage du compte GitHub et migration vers GitLab

• Microsoft a bloqué le compte GitHub du chercheur en sécurité Nightmare-Eclipse (Chaotic Eclipse) pour une raison qui n’a pas encore été rendue publique
• Eclipse a transféré son espace de travail vers GitLab et affirme que le compte Microsoft qu’il utilisait pour signaler les bugs a déjà été supprimé
• Dans un billet de blog, il soutient que cette mesure est de représailles, que Microsoft a refusé de communiquer avec lui et n’a versé aucune récompense
• Le programme de primes MSRC de Microsoft prévoit, selon les conditions, jusqu’à 30 000 à 100 000 dollars pour des zero-days endpoint et jusqu’à 250 000 dollars pour des vulnérabilités Hyper-V
• Eclipse a déjà publié six exploits zero-day et laisse entendre qu’une nouvelle divulgation visant Microsoft pourrait avoir lieu le 14 juillet

Le conflit entre Microsoft et Eclipse

• Le conflit a pris une nouvelle ampleur début avril, lorsque Eclipse a publié le zero-day BlueHammer sans avertissement préalable
• Le blog d’Eclipse critique vivement Microsoft et le MSRC, affirmant que Microsoft a ignoré ou rejeté des signalements de zero-day et n’a pas versé la récompense demandée, ce qui lui aurait causé un préjudice financier
• Eclipse affirme que Microsoft lui a dit qu’ils allaient « ruiner sa vie » et que cela s’est effectivement produit, ajoutant qu’il disposerait d’une sorte de dead man’s switch
• Comme Microsoft n’a pas rendu publics les détails de l’affaire, il est difficile de déterminer s’il s’agit d’un chercheur n’ayant pas suivi la procédure de divulgation standard ou d’une entreprise ayant compliqué les signalements de sécurité

Controverse autour de la procédure MSRC et pression sur les politiques de divulgation

• William Dormann de Tharros, dans un article sur BlueHammer, estime que le MSRC était autrefois agréable pour collaborer, mais qu’il a licencié des profils expérimentés pour réduire les coûts et laissé en place des personnes se contentant de suivre des procédures
• Selon Dormann, le MSRC semble désormais exiger la soumission d’une vidéo de l’exploit, et il est possible que Microsoft ait clôturé le dossier parce que le déclarant n’a pas fourni cette vidéo
• Le silence de Microsoft empêche de savoir clairement si le cœur du conflit tient à la mise en œuvre réelle des procédures de divulgation responsable des vulnérabilités et des programmes de récompense
• Des analyses estiment que la période standard de 90 jours entre divulgation et correctif est devenue de fait un modèle dépassé avec la recherche en sécurité assistée par l’IA
• Dans un contexte où le délai avant exploitation et la quantité d’exploits non utilisés tendent tous deux vers zéro, la nécessité pour Microsoft et les autres éditeurs de logiciels d’ajuster leurs politiques devient plus pressante

Zero-days Windows publiés

• Eclipse a publié plusieurs exploits zero-day Windows
• BlueHammer est une vulnérabilité permettant d’obtenir les privilèges SYSTEM via Defender
• RedSun permet également d’obtenir un accès en tant qu’utilisateur SYSTEM
• UnDefend peut mettre Defender hors ligne
• GreenPlasma permet d’obtenir un accès SYSTEM via le service CTFMon
• MiniPlasma rend possible une élévation de privilèges similaire via une faille du pilote Windows Cloud Filter
• YellowKey est une vulnérabilité BitLocker permettant à un attaquant d’ouvrir des disques chiffrés avec très peu d’effort, sapant ainsi l’objectif fondamental de BitLocker

Exploitation réelle et conséquences de sécurité

• BlueHammer, RedSun et UnDefend seraient activement exploités en environnement réel
• Pour les autres vulnérabilités aussi, des codes de preuve de concept complets ou partiels ont été publiés, ce qui les rend faciles à utiliser pour des attaquants motivés
• Le blocage du compte GitHub ne suffit pas à faire disparaître le code publié ni à empêcher son exploitation, et ne fait qu’aggraver le conflit entre le chercheur et l’entreprise propriétaire de la plateforme
• La combinaison de divulgations de zero-day, de litiges sur les primes, de blocages de comptes et de découverte accélérée de vulnérabilités par l’IA met encore davantage en évidence les limites des processus traditionnels de signalement, de vérification et de correctif de sécurité

[GN⁺]

Réactions sur Hacker News

• Même si je découvre un bug de sécurité dans une application web, je ne le signalerai plus. La première fois, j’ai failli être arrêté par la police ; la deuxième, ils ne m’ont même pas répondu et ont contacté directement mon employeur pour dire que mon signalement les avait contrariés et que je voulais écrire un article après le correctif
  Depuis, j’ai jugé que ça ne valait pas la peine de subir ce genre d’ennuis, et si je laisse tomber, moi aussi je peux passer une journée tranquille

  • Si on le souhaite, on peut signaler la vulnérabilité au Finnish Cyber Security Centre, qui se charge ensuite du signalement et de la médiation avec les parties concernées
    C’est même possible de manière totalement anonyme, donc pas besoin de craindre qu’une entreprise trop susceptible vous gâche la vie. Le FCSC de Traficom est une ressource précieuse pour permettre aux chercheurs white hat de continuer à contribuer à l’intérêt public
  • Une fois, une ligne ferroviaire a publié sur les réseaux sociaux une photo disant qu’elle avait « fait une bonne action pour quelqu’un », et sur le mur du bureau visible sur la photo, il y avait une feuille A4 avec les noms d’utilisateur et informations de connexion de plusieurs systèmes
    Je l’ai signalé à trois contacts trouvables, mais un seul a répondu, en demandant à quoi servaient ces systèmes et quels étaient les risques. Je n’en savais absolument rien, et je n’allais certainement pas me connecter à des systèmes inconnus pour vérifier, donc j’ai répondu qu’il fallait transmettre ça à l’IT interne pour qu’elle voie s’il fallait les modifier ou les remplacer
    Au final, on m’a remercié pour mon sérieux et répondu que la photo avait été supprimée, donc que le problème était réglé. J’espère que quelqu’un de compétent a réellement examiné la question, mais j’ai décidé de ne pas m’impliquer davantage
  • Mieux vaut ne pas s’en mêler
    J’ai travaillé pendant un temps comme white hat à titre professionnel, mais je suis d’accord pour dire qu’aujourd’hui, essayer d’être honnête et utile est devenu risqué. Même si quelqu’un décide de vendre des vulnérabilités, je peux le comprendre
  • Certains critiqueront peut-être la réglementation, mais la Cyber Resilience Act (CRA) rendue obligatoire par l’UE a forcé les entreprises à mettre en place un point de contact clair pour recevoir les signalements de vulnérabilités et à réellement y répondre
  • On peut aussi essayer de signaler anonymement l’exploit à une agence gouvernementale

• Je ne sais pas exactement ce qui se passe ici, mais la règle numéro un des grands programmes de bug bounty est que toutes les personnes concernées côté fournisseur sont fortement incitées à verser les récompenses
  Dans bien des cas, les métriques internes de certains responsables dépendent des montants versés, et dans ce genre de programme, payer est quelque chose qu’on célèbre. Il est donc presque certainement difficile de soutenir que Microsoft harcèle les demandeurs de bounty pour économiser de l’argent
  Ça ne s’applique peut-être pas aux petites entreprises, ce qui est d’ailleurs une raison pour laquelle elles ne devraient pas opérer de bug bounty, mais cela vaut clairement pour des sociétés de la taille des FAANG/MAG7. Cela ne veut pas dire que ces programmes penchent toujours généreusement vers le paiement ni qu’ils ne prennent jamais de décisions frustrantes. En revanche, cela ne colle pas avec l’idée qu’un paiement serait retenu par rancune
  Cela dit, ça fait un moment que je n’ai pas parlé avec des gens de chez Microsoft, donc je garde une petite réserve

  • À lire le billet de YellowKey, on dirait qu’au moins dans certains cas, il a révélé ce qui ressemble à une porte dérobée officielle de Microsoft utilisée par des agences de renseignement américaines et d’autres. L’idée est que BitLocker n’est pas sûr et qu’il contient une backdoor
    Après la fermeture soudaine de TrueCrypt, qui avait supprimé tous ses téléchargements et recommandé à tout le monde de passer à Microsoft BitLocker, ce n’était pas non plus totalement inimaginable
    [1] - https://www.tomshardware.com/tech-industry/cyber-security/mi...
  • Toute cette affaire a commencé parce que la bureaucratie a refusé ne serait-ce que d’examiner Bluehammer après avoir échoué à convaincre le déclarant de publier une vidéo
    Et au lieu de corriger la bureaucratie, ils ont aggravé la situation en bannissant le compte, ce qui donne vraiment une mauvaise image. Je ne vois pas bien pourquoi on devrait interpréter cela comme un geste de bonne foi de Microsoft
  • Le bug soulevé par cette personne ressemble très clairement à une backdoor BitLocker et soulève des questions extrêmement sérieuses sur ce que Microsoft fait en matière de chiffrement
    Il semble tout à fait possible de déchiffrer un volume sans la clé de l’utilisateur, ce qui est extrêmement préoccupant. Ils semblent vouloir faire comme si rien ne s’était passé, mais c’est déjà public
  • S’ils avaient été malins après le bannissement, ils l’auraient embauché pour très cher. Ces grandes entreprises peuvent être tendues, mais si elles ne sont pas stupides, elles paient
    Microsoft n’est peut-être pas l’entreprise la plus progressiste sur ce genre de sujet, donc je ne sais pas s’ils l’ont compris
  • Quand je travaillais sur l’évaluation des bug bounties, je n’ai jamais vu de preuve d’une réticence à payer. Le pire comportement que j’ai vu côté entreprise, c’est demander dans une preuve de concept « évitez X », puis accorder finalement une somme plus élevée à un chercheur qui avait ignoré cette instruction
    C’était simplement parce que le risque démontré était plus élevé. À l’inverse, dans un grand programme, un chercheur avait réussi il y a longtemps à convaincre qu’un exploit XSS banal pouvait produire un effet relevant d’un niveau de rémunération supérieur ; ensuite, chaque fois qu’il trouvait une XSS, il joignait une preuve de concept produisant ce même effet et obtenait ainsi en continu une classification indûment plus élevée. Les XSS des autres chercheurs, elles, étaient payées selon le niveau XSS indiqué dans le barème
    En fait, un contre-exemple me revient. Quelqu’un avait réussi le Graal, à savoir installer un webshell sur un serveur de l’entreprise, ce qui vaudrait aujourd’hui plus de 10 000 dollars. Mais il avait laissé le webshell en place et s’était contenté de soumettre le rapport. Le responsable du programme était furieux et a explicitement dit que, pour cette raison, il ne voulait pas verser la bounty. Je ne me souviens plus si elle a finalement été payée

• Microsoft va probablement regretter cette affaire
  Si quelqu’un trouve un zero-day, il n’obtient aucune récompense et se fait seulement bannir. Du coup, il ira vendre ce zero-day ailleurs

  • Mais cette histoire ne dit-elle pas qu’il ne l’a pas vendu, mais rendu public ? C’est aussi ce que dit le titre
    Et il a aussi été banni sur GitLab, qui n’a rien à voir avec Microsoft
  • D’autres personnes cherchent aussi des zero-day. La réputation compte énormément
  • Vendre des zero-day ailleurs ne semble pas vraiment poser problème. La CIA peut distribuer des millions de dollars en lingots d’or sur simple demande d’un haut responsable, donc pour acheter des exploits, ils n’ont probablement même pas besoin d’un bon de commande

• Ces derniers mois, j’ai souvent eu affaire à des réactions numériques étranges dans plusieurs situations liées, et c’était frustrant de ne pas réussir à identifier exactement ce que je faisais de travers. Puis j’ai lu cette phrase dans l’article
  « Mais pour réduire les coûts, Microsoft a licencié les personnes compétentes et n’a laissé que des suiveurs de logigrammes. »
  Cette expression, suiveurs de logigrammes, mérite d’être retenue. Ce sont des gens qu’on paie non pas pour réfléchir, mais pour suivre une procédure prédéfinie. J’ai l’impression que, dans un avenir proche, on aura affaire à bien plus de ces suiveurs de logigrammes, qu’ils soient numériques ou humains

  • La plupart des cabinets de conseil en sécurité d’entreprise auxquels j’ai eu affaire autrefois fonctionnaient à la checklist
  • Dans de nombreux métiers manuels comme mécanicien, électricien ou artisan du bâtiment, suivre le flowchart est pratiquement une obligation légale, et les procédures sont écrites avec du sang et de la responsabilité
    À l’inverse, en IT, dans l’ops et chez les développeurs, on se voit comme des artisans et des travailleurs du savoir capables de penser librement. On associe davantage la compétence aux raccourcis, aux hacks et à la pensée hors cadre qu’au simple respect des procédures

• Y a-t-il une position publique sur ce qui se passe chez Microsoft ? Pourquoi Microsoft et GitLab ont-ils tous deux banni cet utilisateur ?
  Je croyais que les deux plateformes autorisaient l’hébergement d’exploits et de recherches en sécurité, à condition que ce soit clairement indiqué dès le départ, donc il a sans doute enfreint une règle

  • S’il s’agit d’un exploit de chiffrement complet du disque qui nécessite encore un accès physique au matériel, il a peut-être été conçu pour une agence gouvernementale en trois lettres ou un organisme du même genre

• Tirer sur le messager devrait régler le problème

  • Peut-être veulent-ils inciter à vendre à des agences étatiques plutôt qu’à corriger la faille

• Microsoft s’est-il créé à lui-même une responsabilité éditoriale de retirer les zero-days de GitHub ?
  Si un zero-day visant mon logiciel apparaît sur GitHub, Microsoft supprimera-t-il aussi ce compte ?

  • Je ne vois pas pourquoi cette mesure impliquerait désormais une obligation d’agir aussi contre d’autres comptes à l’avenir

• Cette situation illustre bien le conflit d’intérêts structurel créé par le fait que Microsoft possède GitHub
  GitHub a des conditions d’utilisation explicites concernant l’hébergement d’exploits activement militarisés, mais bannir un chercheur qui cible Windows, même s’il existe une raison légitime, donnera inévitablement l’impression d’une mesure de rétorsion

• Information très importante :
  https://www.theregister.com/security/2026/05/28/microsoft-0-...
  Le billet de blog Microsoft lié dit ceci
  « Les détails de ces vulnérabilités n’ont pas été partagés avec Microsoft avant leur divulgation, et cette publication a exposé inutilement les clients à un risque. »
  Donc, Microsoft ment-il ? Sinon, pourquoi Nightmare-Eclipse ne l’a-t-il pas signalé ? La situation est assez étrange

  • La formule « cette publication a exposé inutilement les clients à un risque » me dérange
    Qu’il s’agisse ou non d’une divulgation responsable, ce n’est pas le chercheur qui a mis les clients en danger, mais Microsoft lui-même
  • Si Nightmare-Eclipse n’a rien signalé, c’est peut-être parce qu’il s’agit d’une organisation écran d’un service de renseignement étranger se faisant passer pour un chercheur mécontent
  • Les clients dont il est question ici ne sont peut-être pas les particuliers ou les entreprises qui ont payé une licence, mais l’entité qui a demandé cette porte dérobée