Un chercheur en sécurité affirme que Microsoft a créé une porte dérobée dans BitLocker et publie un exploit
(techspot.com)- Le chercheur en sécurité Nightmare-Eclipse a publié YellowKey, affirmant qu’il permet de contourner sans mot de passe le chiffrement intégral de volume de BitLocker
- YellowKey peut être reproduit en copiant le dossier FsTx sur une clé USB utilisant un système de fichiers compatible Windows, puis en suivant une séquence précise dans WinRE
- Une fois la procédure terminée, un shell de commande s’ouvre, permettant d’explorer des volumes protégés par BitLocker, de copier des fichiers et d’effectuer d’autres opérations sur les fichiers
- Nightmare-Eclipse affirme que le contournement n’apparaît que dans les images WinRE officielles, soulevant la possibilité d’une porte dérobée intentionnelle
- Les systèmes concernés seraient Windows 11, Server 2022 et Server 2025, tandis que Windows 10 ne serait pas affecté
Conditions de fonctionnement de YellowKey
- Le chercheur en sécurité Nightmare-Eclipse a publié YellowKey, affirmant qu’il permet de contourner complètement le chiffrement intégral de volume de BitLocker
- YellowKey peut être reproduit en copiant le dossier FsTx fourni sur une clé USB formatée avec un système de fichiers compatible Windows comme NTFS, FAT32 ou exFAT
- Il serait également possible de le faire fonctionner sans clé USB en copiant les fichiers FsTx sur la partition EFI de Windows puis en déconnectant temporairement le disque chiffré du système
- Il faut ensuite redémarrer le système protégé par BitLocker, entrer dans le Windows Recovery Environment (WinRE), puis suivre une séquence d’entrées spécifique
- Si la procédure est exécutée correctement, un shell de commande apparaît, permettant d’explorer ou de copier des volumes protégés par BitLocker sans mot de passe, ainsi que d’effectuer d’autres opérations sur les fichiers
Éléments à l’origine des soupçons de porte dérobée
- Selon Nightmare-Eclipse, YellowKey présente des caractéristiques trop inhabituelles pour être considéré comme une faille de sécurité jusque-là inconnue, et il avance la possibilité que Microsoft ait intégré une porte dérobée légitime au système de protection des données de BitLocker
- L’argument avancé est que les composants à l’origine du problème ne sont présents que dans les images WinRE officielles
- Les mêmes composants existent aussi dans les images d’installation standard de Windows, mais le comportement de contournement de BitLocker observé sur des systèmes réels ne s’y manifesterait pas
- Nightmare-Eclipse a déclaré qu’« il ne voit aucune autre explication que le fait que cela ait été intentionnel », ajoutant que Windows 10 n’est pas affecté, et que seuls Windows 11, Server 2022 et Server 2025 le sont
Vérifications externes et publication supplémentaire
- Des chercheurs tiers auraient confirmé que YellowKey fonctionne comme décrit dans les documents GitHub de Nightmare-Eclipse
- Nightmare-Eclipse a également publié un second exploit, GreenPlasma, présenté comme permettant une élévation de privilèges
- GreenPlasma ne publie pas l’intégralité du code de preuve de concept permettant d’obtenir un accès au niveau SYSTEM, mais laisse entendre que davantage de détails pourraient être dévoilés avant le Patch Tuesday du mois prochain
Pistes d’atténuation
- Il est indiqué que l’atténuation face aux soupçons de comportement assimilable à une porte dérobée dans YellowKey est relativement simple
- Les experts en sécurité recommandent de ne pas dépendre d’un seul système de chiffrement et d’évaluer aussi des alternatives de chiffrement complet du disque ayant fait l’objet d’un examen approfondi
- VeraCrypt est cité comme exemple
1 commentaires
Commentaires sur Hacker News
À lire le billet du chercheur Nightmare-Eclipse qui a découvert cette vulnérabilité, on dirait que cela dure depuis presque une semaine
Le mardi 12 mai 2026, il écrivait : « cette fois, il y a deux vulnérabilités [YellowKey] [GreenPlasma] [...] Microsoft va avoir une sacrée surprise au prochain Patch Tuesday », puis le mercredi 13 mai : « quand je pourrai raconter toute l’histoire, les gens verront que mon explosion était plutôt rationnelle, et que cela ne donnera absolument pas une bonne image de Microsoft »
Blog de l’auteur : https://deadeclipse666.blogspot.com/
Dans un premier billet de mars 2026, il disait en substance : « quelqu’un a rompu notre accord, je n’ai plus un sou et j’ai perdu mon logement. Ils m’ont poignardé dans le dos en sachant que cela arriverait. Ce n’est pas ma décision, c’est la leur »
Je ne sais pas trop comment l’interpréter, mais on dirait presque qu’un initié est en train de « fuiter » des informations, et d’autres semblent pouvoir reproduire les résultats
Que ce soit ou non une porte dérobée dépend au fond de la manière dont on voit d’ordinaire la distinction « bug ou backdoor », et ce n’est pas la version simpliste du genre « Microsoft = 1, BitLocker piraté » qu’aime la presse tech
Le cœur du problème est un bug dans la fonctionnalité de relecture du journal de transactions NTFS de Windows Recovery Environment WinRE, qui permet de lire le journal de transactions NTFS d’un volume externe et de l’appliquer au système de fichiers monté. Cela permet à un attaquant de contourner l’authentification de WinRE
Avec BitLocker sans PIN ni mot de passe, tout contournement d’authentification revient à contourner le chiffrement du disque, puisque le bootloader a déjà déscellé le disque, et ce « défaut » structurel existe aussi sur Linux avec la même configuration. Par exemple, c’est également le cas si l’on utilise la case Hardware Disk Encryption ajoutée assez récemment dans l’installateur Ubuntu
Sans élément supplémentaire, considérer le problème du journal de transactions NTFS comme une backdoor délibérément implantée ou comme un simple bug d’énumération relève du niveau habituel de théorie du complot qu’on voit souvent dans le développement d’exploits. Personnellement, cela me paraît être un bug plausible, et la faiblesse du déscellement au démarrage est connue et évidente, donc je n’y vois pas une révélation qui va bouleverser le monde, même si cela reste un bug intéressant
Meilleur récapitulatif : https://infosec.exchange/@wdormann/116565129854382214
L’exploit publié n’affecte pas BitLocker avec PIN. Sans PIN, BitLocker n’est de toute façon pas vraiment sûr
L’auteur initial affirme avoir un exploit qui fonctionne même avec un PIN, mais il n’en a encore fourni aucune preuve
Je n’ai jamais vu d’entreprise imposer un PIN pour BitLocker
Source : https://infosec.exchange/@wdormann/116565129854382214
« Une session WinRE typique contient le répertoire X:\Windows\System32 avec un fichier winpeshl.ini dedans »
« Mais dans l’exploit YellowKey, il semble que des fragments Transactional NTFS provenant d’une clé USB puissent supprimer le fichier winpeshl.ini d’un autre lecteur »
Intéressant. Je connais mal cet environnement, mais est-ce qu’il pourrait s’agir naïvement d’un problème de création ou de transmission de handles de fichier ? Si oui, pourquoi faudrait-il une saisie clavier pendant le redémarrage WinRE ?
Je me demande aussi dans quelle mesure un correctif est possible. On ne pourra pas toucher à l’innombrable quantité de clés USB WinRE existantes, donc peut-être que l’on pourrait mettre à jour les autorisations côté BitLocker ? Faudra-t-il déchiffrer puis rechiffrer ? Il semble qu’il y ait encore beaucoup à venir
Cette attaque nécessite donc WinRE, pas simplement de démarrer sur quelque chose comme un live CD Ubuntu
Et il n’est pas nécessaire de corriger toutes les anciennes clés USB WinRE. Il suffit de révoquer leur signature Secure Boot : elles ne passeront alors plus la validation TPM et ne pourront donc déchiffrer aucun disque
« Les experts en sécurité recommandent généralement de ne pas dépendre d’un seul système de chiffrement et d’évaluer des alternatives de chiffrement complet du disque bien auditées comme VeraCrypt »
S’ils avaient mis une backdoor dans le FDE, il serait plus logique de dire aux gens d’arrêter complètement d’utiliser Windows et de passer à Linux
S’ils ont mis une backdoor dans le FDE, il faut supposer que le système d’exploitation lui-même n’a pas qu’une seule backdoor. Il ne faut faire aucune confiance aux logiciels propriétaires, ni même à l’open source mal audité
Cela ressemble moins à un problème propre à BitLocker qu’à un contournement de connexion. Sans PIN, si l’on s’appuie sur le TPM, le déchiffrement se fait automatiquement
Normalement, l’attaquant devrait rester bloqué à l’écran de connexion, donc cela devrait aller, mais cet exploit semble montrer comment obtenir un shell sans restriction dans l’environnement de récupération
Le chercheur affirme aussi avoir un moyen de contourner le PIN, mais ne l’a pas encore publié
À quel moment les experts en sécurité vont-ils commencer à refuser les postes liés à la « sécurité des produits Microsoft » ? Pour ma part, j’en suis déjà là
La sécurité des produits Microsoft n’est qu’un travail de Sisyphe jusqu’à ce qu’elle s’effondre de nouveau sous la prochaine vague de dette technique délirante et d’avidité de MS. Maintenant, il y a même des backdoors
On a satisfait à toutes les règles de conformité et suivi les « bonnes pratiques » influencées par MS ; ainsi, quoi qu’il arrive, on ne pourra pas leur en faire porter la responsabilité
On peut activer l’ADP pour des sauvegardes chiffrées de bout en bout, mais cela n’aide pas forcément beaucoup si vos interlocuteurs ne l’ont pas activé eux non plus
Ce n’est pas pour défendre Microsoft, c’est pour rappeler que toutes ces entreprises faisaient partie de PRISM
On peut reparler du fait que, lorsqu’une ancienne version de Windows NT a été publiée par erreur avec les symboles de débogage activés, le nom de la clé que Microsoft prétendait être une « clé auxiliaire » était ..._NSAKEY
Une seule fois, vraiment une seule fois, Windows a été publié avec les symboles de débogage activés, et comme par hasard le nom de la clé de chiffrement était « NSAKEY »
Bien sûr, ceux qui ferment systématiquement les yeux sur les fautes de l’État diront que c’était parfaitement normal et répéteront mot pour mot la justification soigneusement élaborée par Microsoft à l’époque : « ce n’est pas une backdoor »
En creusant un peu plus l’exploit, il vise BitLocker en mode TPM seul, c’est-à-dire sans authentification avant démarrage
Si Secure Boot valide la chaîne de démarrage, le TPM fournit de lui-même la clé de chiffrement. En cas d’accès physique, la différence n’est pas énorme
On peut soit démarrer sur une clé USB contenant l’exploit pour obtenir un shell d’urgence, soit acheter un microcontrôleur à 5 dollars et le souder sur certaines broches de la carte mère pour espionner la clé TPM
Microsoft vend globalement quelque chose de peu sûr en le présentant comme du chiffrement complet du disque. Quiconque est capable de mettre un exploit sur une clé USB, d’obtenir un shell et de fouiller puis copier les fichiers peut aussi acheter un microcontrôleur et suivre une vidéo YouTube de soudure
Donc le problème n’est pas tant l’« exploit » lui-même que le faux sentiment de sécurité vendu par Microsoft
Espionner la clé TPM avec un microcontrôleur à 5 dollars soudé sur certaines broches n’est possible qu’avec un dTPM. Un fTPM n’est pas vulnérable à cela et est bien plus largement utilisé que le dTPM
Taper une passphrase au démarrage est déjà un automatisme musculaire et offre une sécurité simple en laquelle on peut avoir confiance
On peut récupérer les données même sans la carte mère
Pour un usage quotidien, un hybride pourrait convenir : un slot combinant Secure Boot + TPM + passphrase pour se protéger des attaques de type evil maid, plus un second slot de secours avec une passphrase de sauvegarde
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
Cela ressemble moins à une attaque contre BitLocker qu’à une attaque contre la chaîne Secure Boot
L’intérêt d’un déverrouillage sans PIN existe lorsque le modèle de menace se limite à la mise au rebut du disque, au retrait du disque ou à la séparation entre le TPM et le disque
Si l’appareil est utilisé régulièrement par plusieurs personnes, saisir un PIN peut être peu pratique, voire impossible. On en arrive donc à une architecture qui délègue le contrôle de validation d’accès à des composants approuvés du système d’exploitation
Quelqu’un se souvient de la mention « L’utilisation de TrueCrypt n’est pas sûre et peut comporter des problèmes de sécurité non corrigés » ? ;)