Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille
Microsoft « coincée »
Un hacker a prouvé qu’il était possible de contourner la protection BitLocker de Windows en utilisant une ancienne faille insuffisamment corrigée par Microsoft. L’exploitation réclame un accès physique, mais reste valable dans le cadre d’une attaque ciblée.
Le 03 janvier à 15h05
6 min
Sécurité
Sécurité
BitLocker est un mécanisme apparu avec Windows Vista proposant un chiffrement intégral du disque. S’il était initialement réservé aux éditions Pro, il est maintenant disponible dans toutes les éditions de Windows 11. Sur les machines les plus récentes, il est même activé par défaut, une décision de Microsoft qui avait communiqué à ce sujet en mai dernier. Cette bascule s’est produite avec les installations neuves de Windows 11 équipées de la dernière mise à jour majeure 24H2.
Le chiffrement est basé sur XTS-AES 128 ou 256 bits. Il permet en théorie de protéger les informations stockées sur le disque en imposant la possession d’une clé pour les déchiffrer. Cette clé est stockée dans la puce TPM (version 1.2 minimum). Elle doit faire l’objet d’un soin particulier dans le cas d’une réinstallation de Windows, pour ne pas perdre ses documents et autres fichiers personnels, comme nous l’indiquions l’année dernière.
Cette protection n’est cependant pas absolue. En février 2024, un youtubeur – Stacksmasher – avait montré comment il avait pu contourner BitLocker avec moins de 10 dollars de matériel. La démonstration était impressionnante, mais tablait sur une configuration spécifique. Il fallait en effet que l’ordinateur dispose d’un connecteur LPC (Low Pin Count) disponible, ce qui était le cas sur d’anciens portables de Lenovo. Le problème était également connu et documenté par Microsoft.
Le hacker Thomas Lambertz a cependant montré il y a quelques jours que l’on pouvait accéder aux informations sans cette technique, même si l’accès physique reste obligatoire.
Une vieille faille remise au goût du jour
Le 28 décembre, Thomas Lambertz a montré sa méthode lors du Chaos Communication Congress qui s'est tenu récemment au Chaos Computer Club (CCC), souvent présenté comme le plus grand club de hackers en Europe.
Sa technique se base sur une ancienne faille, CVE-2023-21563, également surnommée « bitpixie ». Dans la fiche de Microsoft, elle apparait comme corrigée en janvier 2023. Accompagnée d’un score CVSS (3.1) de 6.8, sa dangerosité était réglée sur « importante ». Exploitée, elle aurait permis un contournement de BitLocker et donc un accès aux données, même si elle réclamait un accès physique.
Dans sa démonstration, Lambertz explique que cette faille pouvait toujours être exploitée, la correction n’ayant pas couvert tous les angles. Pour cela, le hacker a réorienté le mécanisme Secure Boot pour lui faire lancer un chargeur d’amorçage (bootloader) obsolète pour Windows. Le chargeur a pour mission d’extraire la clé de chiffrement en mémoire, permettant à un système Linux installé de la récupérer.
La procédure est la suivante :
- Créer une clé USB bootable, dont l’espace de stockage est supérieur à la quantité de RAM sur l’ordinateur ciblé
- Redémarrer brutalement l’ordinateur pendant le démarrage de Windows, avant que l’écran de connexion ne s’affiche, afin que la clé de chiffrement soit chargée en mémoire
- Démarrer depuis la clé USB puis charger un shell UEFI personnalisé, afin de pouvoir exécuter des outils qui réaliseront des dumps (fichier de vidage) de la mémoire
- Analyser les dumps avec des outils comme xxd et searchMem pour localiser la clé de chiffrement dans des zones spécifiques
L’exploitation de cette faille n’est possible que parce qu’une correction complète exige une modification de l’UEFI. Microsoft aurait été « coincée » par les limitations de l’espace de stockage dans ce composant crucial.
Dangerosité variable
Toute la question est de savoir à quel point la technique utilisée par Thomas Lambertz est dangereuse. Dans l’absolu, elle l’est : BitLocker est contourné et les informations auparavant chiffrées peuvent être lues. Il y a cependant deux conditions importantes. D’une part, un accès physique à la machine, ce qui est loin d’être une garantie, d’autant qu’il faut disposer du temps pour réaliser les manipulations. D’autre part, un accès au réseau, via un adaptateur USB autorisant le démarrage PXE.
Il est probable que les utilisateurs classiques ne soient pas en danger. En revanche, les entreprises, les administrations et les gouvernements – particulièrement les membres haut placés – devraient y voir un risque. Si l’opération ne peut pas être réalisée discrètement, le vol de l’appareil reste envisageable. Dérober l’ordinateur portable d’une personnalité peut amener à des informations sensibles, voire classifiées.
La correction complète n’est pas simple
Pour corriger le problème, il faut attendre une solution plus durable que le correctif proposé par Microsoft il y a maintenant deux ans. Malheureusement, cette correction complète requiert un remplacement des certificats de sécurité, dont la révocation n’est pas possible de manière simple.
Selon Thomas Lambertz, l’éditeur est conscient du problème, mais est dans une position délicate, puisque « chaque mise à jour de micrologiciel qu'il ne prévoit pas correctement pourrait casser BitLocker. C'est pourquoi ils ne le font pas ».
Que faire pour se protéger ? Il y a peu de méthodes réellement fiables. Si les PC Windows exploitant BitLocker sont gérés par un administrateur, l’activation de la règle ajoutant un code PIN pour déverrouiller BitLocker est une étape importante. Mais pour le hacker, il n’existe qu’une seule façon de bloquer le problème à la racine : « La seule chose que vous puissiez faire pour empêcher cette attaque est de désactiver la pile réseau complète dans le BIOS. De cette manière, le démarrage PXE n'est pas possible, quel que soit l'appareil branché ».
En attendant, la technique du hacker est efficace sur toute machine Windows 11 à jour. Microsoft n'a pas réagi pour l'instant à ces découvertes, mais a été tenue au courant des avancées par Thomas Lambertz.
Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille
-
Une vieille faille remise au goût du jour
-
Dangerosité variable
-
La correction complète n’est pas simple
Commentaires (34)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 03/01/2025 à 15h18
Et le démarrage PXE n'est de toute façon pas possible.
J'ai aussi un mot de passe à mon UEFI, il faut clear pour y avoir accès, et donc effacer la clef du TPM.
Je devrais être safe, je pense.
Modifié le 03/01/2025 à 15h31
Si on branche ton disque dans une autre machine, même avec ton mdp on accède aux fichiers (si pas chiffré bien sûr).
Après, je pense que le particulier est plutôt tranquille avec cette faille ^^
Le 03/01/2025 à 16h15
J'ai fais en sorte que Bitlocker me réclame un mot de passe avant de déchiffrer l'OS.
Comme avec le PIN, mais en mot de passe.
Le 03/01/2025 à 16h19
Le 03/01/2025 à 16h17
Le 03/01/2025 à 16h19
Le 04/01/2025 à 10h04
Modifié le 04/01/2025 à 15h40
Le compte root dispose de privilèges bien supérieurs à ceux d'un compte "administrateur" sous Windows.
Certaines techniques permettent, dans une certaine mesure, de limiter ce qu'il est possible de faire avec les privilèges root/wheel (notamment pour lutter contre les 0-day), et la bonne pratique est de désactiver le compte root et de contrôler les élévations de privilèges des comptes administratifs.
TL;DR : avec les bons privilèges, tu fais ce que tu veux avec un Linux, y compris saborder le système lui-même. C'est une des raisons pour lesquelles c'est fun.
Hier à 09h03
Le compte root de Windows, c'est l'utilisateur SYSTEM. Et il est "désactivé" (dans le sens, impossible de s'authentifier directement sous cet utilisateur.)
Je vais en faire crier plus d'un, mais Windows le fait de base ^^
Hier à 14h26
Avec sudo ou su sous linux, je fait tout ce que je veux et j'en assume pleinement les conséquences potentielles.
Un compte administrateur n'est pas l'égal d'un compte avec les droits sudo, et de loin.
Les deux concepts sont donc proches mais pas équivalents.
Cette pratique est généralisée depuis bien longtemps sur tous les OS desktop et même serveur. Même raspbian le fait depuis ses débuts. A part te dire « c'est cool », je ne vois pas matière à régir.
Hier à 19h55
Au contraire de su, qui lui te donne véritable le droit root en ouvrant un shell.
Pour les os dektop et serveur qui font ça de base, ce n'est pas ce que je constate de mon côté. C'est une bonne pratique, je suis entierement d'accord, mais elle n'est pas généralisée.
Le 03/01/2025 à 15h18
Ils ont failli de corriger correctement la faille
pour empêcher cette attaque est de désactiver la pile réseau complète dans le BIOS. De cette manière, le démarrage PXE n'est pas possible, quel que soit l'appareil branché
Et mettre un mot de passe pour empêcher l’accès à l'UEFI sinon la pile réseau peut être réactivité en accédant à l'UEFI ?
Le 03/01/2025 à 15h33
Le 03/01/2025 à 17h46
Mais effectivement pour un poste de particulier, je ne vois pas l'intérêt d'avoir un boot PXE/Réseau activé par défaut.
Le 03/01/2025 à 20h29
Du moins c'est ainsi qu'on fonctionnait dans mon administration tant qu'on s'en servait.
Le 04/01/2025 à 08h44
Le 03/01/2025 à 15h38
Soyons fous, un court-circuitage du PC comme les bipers. Un kill switch avec de la thermite.
Le 04/01/2025 à 09h46
Ça traine depuis les AtariST et les Amigas. C'est un peu beaucoup la non*.
Le 04/01/2025 à 12h13
Encore plus si elle est refroidie. Rechercher "cold boot attack" pour de plus amples renseignements
Le 04/01/2025 à 17h11
Simplement ce genre de chose à part sur une coupure de courant pourrait être faite.
* Soit par l'OS lors de la séquence d'extinction. Kill du process et formatage de la plage mémoire concernée. Si le gestionnaire de tâche peut compter les octets, c'est qu'il sait où ils sont.
* Soit par l'UEFI au boot (ou même POST). Tu boot avec un slip propre en résumé.
On s'amusait déjà à l'époque à "détourner" le bouton reset des AtariST et Amiga pour le faire. C'est une "routine" par très compliquée à faire.
Le 04/01/2025 à 19h03
À partir de là, ce qui est décrit ici est l'utilisation du chargement par PXE d'un bootloader toujours buggé alors que la "correction" de Microsoft a seulement consisté à faire un nouveau bootloader qui lui effaçait bien la clé mais sans que tout le processus du "secure" boot ne puisse empêcher de charger l'ancien bootloader.
Ensuite, il finit par charger un Linux lui-même avec une faille permettant de lire toute la mémoire physique et donc de retrouver la clé. Celle-ci étant précédée d'une chaîne de caractères précise et donc facile à trouver.
Hier à 17h53
Pour moi (mon opinion), un ordinateur qui démarre doit le faire avec une mémoire propre.
Donc pour éviter toutes éventualités de quoi que ce soit. Au moment où le dispositif sait accéder à la RAM, il devrait écrire du zéro partout (hors zones protégées bien sur!). Pour ainsi dire.
Idem pour un ordinateur qui arrive en fin de la séquence d'extinction. L'OS devrait faire le ménage.
Il fut un temps où le BIOS testait la mémoire. Un bon vieux "write/read" des familles. Tout le monde désactivait la fonction parce que c'était un peu lent. Aujourd'hui, nous n'avons plus ce problème. C'est très rapide quand bien même les volumes de RAM ont explosé. Techniquement parlant, je ne vois pas ce qui empêcherait une mise à blanc de la RAM.
J'ajouterai que les programmeurs et les développeurs devraient faire un peu mieux le ménage aussi. Et sans oublier les langages informatiques eux-mêmes. Ce n'est pas comme si c'était automatique. On saluera quand même le "Garbage Collector" qu'on trouve en POO.
Rien que "faire le ménage" simplement, permet d'éviter une sacrée tonne de problème du genre "left over exploits".
Il faut le visualiser comme la réalité. Si le chat a lâché une poire sur le tapis, cela se voit. La RAM c'est pareil à une maison... Bon là, ce sera une vision d'horreur. Disons que le chat a le volume d'un mammouth. Mais au moins, on en prend conscience.
Hier à 01h10
Hier à 05h08
Ensuite pour la faille en question, déjà il faut un accès physique au pc,et il faut certaines connaissances.
Et si tu ne travailles pas pour une agence de contre espionnage ou dans le nucléaire, tu peux dormir tranquille.
C'est pas cette news qui me fera remplacer bitlocker par autre chose.
Hier à 16h49
Si Microsoft (mais d'autres) veulent un système de chiffrement sécurisée, le code source doit pouvoir être librement accessible et reproductible.
Hier à 17h09
Hier à 22h34
Ce qui, selon moi, implique que même si je dérobe le code source de BitLocker et le publie ouverte, la sécurité de celui-ci ne sera pas comprise car il repose sur la clé. Par conséquent, pourquoi Microsoft ne le rend-t-il pas publique ? Le chiffrement est connu c'est de l'AES. Le Cipher block, de l'XTS et la taille de la clé est connu (mais si à cette égard j'ignore si la taille de la clé donnée est avant ou après application de l'XTS).
J'ignore la citation original de Kerckhoffs, et de fait quelle page wiki est correct. En revanche, l'évolution des conflits et le role de la cryptographique a évolué depuis Kerckhoffs.
Et je pense que la version "moderne" formulée par Shannon (celui de l'entropie de l'information) : "The ennemy knows the system" est plus approprié (non pas parce qu'elle appuie mon argument, mais parce qu'elle se trouve plus réaliste de nos conflits modernes).
Hier à 17h32
Aujourd'hui à 02h41
Après bitlocker existe depuis... 15 ans ?
Et jusqu'ici personne ne s'est fait pirater un pc avec bitocker. Les 2 ou 3 failles que j'ai vu passé depuis 15 ans, il faut un accès physique au pc et avoir les connaissances nécessaires.
Hier à 17h29
Hier à 09h53
Une fois une clé de déchiffrement récupérée, n'importe quel système de chiffrement est vulnérable.
S'il y a une technologie à critiquer ici, c'est le secure boot et sa complexité ainsi que le fait qu'il ne puisse pas invalider le bootloader avec la faille faute d'assez d'espace de stockage. On peut aussi critiquer Linux, logiciel open source s'il en est dont certaines versions signées par MIcrosoft permettent à cause d'une faille de récupérer la clé en lisant toute la mémoire physique, mais l'auteur de la présentation répond à une question en indiquant qu'il est aussi possible d'utiliser des outils Windows pour récupérer la clé.
Hier à 18h01
Hier à 18h58
Hier à 21h42