Connexion
Abonnez-vous

Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille

Microsoft « coincée »

Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille

Crédits : JJ Ying (Unsplash)

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

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.

Commentaires (34)

votre avatar
J'ai un mot de passe pour déverrouiller mon Windows à chaque redémarrage, ça devrait être bon non?
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.
votre avatar
Le mot de passe Windows n'a pas de rapport avec le chiffrement du disque :)

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 ^^
votre avatar
Je ne parles pas du mot de passe Windows.
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.
votre avatar
Ah oui ok, j'avais mal compris :)
votre avatar
Le système de fichier NTFS ne permet pas de garder les droits de lecture écriture ? L'ouverture sur Linux d'un système de fichier NTFS fait sauter les droits ?
votre avatar
Tu peux changer le propriétaire des données, si tu es admin de l'OS où se trouve le disque dur, et donc récupérer les droits.
votre avatar
Linux doit en général ignorer les droits, sous Windows, tu peux les faire sauter, te débrouiller pour avoir un accès SYSTEM, utiliser un compte avec des droits "backup", ou encore d'autres trucs (les méthodes d'accès aux fichiers en Kernel ne vérifient pas les permissions par exemple)
votre avatar
Sur les systèmes unix-like, root ("dieu") peut attribuer/modifier les permissions comme bon lui semble.
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.
votre avatar
Le compte root dispose de privilèges bien supérieurs à ceux d'un compte "administrateur" sous Windows.
Tout à fait. La raison est simple : un compte administrateur Windows, c'est l'équivalent d'un compte utilisateur avec droits d'administration (groupe sudo/wheel sous Linux).

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.)
la bonne pratique est de désactiver le compte root et de contrôler les élévations de privilèges des comptes administratifs.
Je vais en faire crier plus d'un, mais Windows le fait de base ^^ :mdr:
votre avatar
un compte administrateur Windows, c'est l'équivalent d'un compte utilisateur avec droits d'administration (groupe sudo/wheel sous Linux).
Windows 10/11 me fait régulièrement suer en me disant que je n'ai pas le droit de faire ci ou ça, quand je me connecte en administrateur.
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.
Je vais en faire crier plus d'un, mais Windows le fait de base ^^
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.
votre avatar
Un droit sudo ne veut rien dire en soit, car les droits accordés vont dépendre de la configuration. Tu peux autoriser toutes les commandes, comme en limiter les usages. C'est un outil très puissant.

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.
votre avatar
Microsoft « coincée »
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 ?
votre avatar
On peut désactiver le réseau sur la partie PXE dans tous les bios moderne (sans couper le réseau tout court :)), avec un mdp UEFI, tu es tranquille je pense :p
votre avatar
Dommage que le PXE soit surtout utile en entreprise, et que c'est plutôt une entreprise/un haut placé qui va subir ce type d'attaque.
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.
votre avatar
La personne qui prépare le PC est "censée" virer le PXE dès qu'il n'y a plus l'utilité.
Du moins c'est ainsi qu'on fonctionnait dans mon administration tant qu'on s'en servait.
votre avatar
Oui, d'ailleurs certains constructeurs permettent de modifier le Bios en postinstall via des scripts pour justement paramétrer tout cela de manière automatique :) (HP par exemple)
votre avatar
Je me demande si on pourrait implementer un effacement des données au démarrage selon des critères prédéfinis : certificat, usb id, mdp, date.
Soyons fous, un court-circuitage du PC comme les bipers. Un kill switch avec de la thermite. :devil:
votre avatar
Ça m'a toujours semblé louche de voir que les boutons "reset" et raccourci clavier du genre ne s'attachent jamais à wiper la mémoire. Même si ici, c'est un peu différent. Ça reste le même principe.

Ça traine depuis les AtariST et les Amigas. C'est un peu beaucoup la non*.
votre avatar
Au niveau physique, la RAM il lui faut du temps pour se réinitialiser. Un clic-clac ne suffit pas.
Encore plus si elle est refroidie. Rechercher "cold boot attack" pour de plus amples renseignements :D
votre avatar
Ça je le sais.

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.
votre avatar
Je ne suis pas sûr de comprendre ce que tu veux faire réellement comme nettoyage de mémoire mais la première faille exploitée est que le bootloader Windows dans un cas d'erreur de supprimait pas la clé en mémoire. Microsoft supprimait donc (à par ce bug) la clé afin qu'elle ne soit pas récupérable.

À 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.
votre avatar
Je vais essayer de re-phraser.

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.
votre avatar
Voilà pourquoi je n'ai confiance qu'en des technologies de chiffrement open source !
votre avatar
Soupir..... Déjà des failles, il y en a partout. Y compris dans l'open source.
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.
votre avatar
Au delà de la faille, on ne peut pas faire confiance à BitLocker ! Non pas parce que c'est du Microsoft mais simplement parce qu'il existe un principe fondamental en cryptographique que l'on nomme le principe de Kerckhoffs, principe qui consiste à dire que la sécurité d'un système crytographique doit reposer uniquement sur sa clé. Et par corollaire, offuscation de l’algorithme eet de son implémentation n'ajoute pas une sécurité supplémentaire. Pis, et a été déjà démontré à mainte reprises que ça finit toujours pas être cracké.

Si Microsoft (mais d'autres) veulent un système de chiffrement sécurisée, le code source doit pouvoir être librement accessible et reproductible.
votre avatar
Wikipédia :
Le principe de Kerckhoffs n'implique pas que le système de chiffrement soit public, mais seulement que sa sécurité ne repose pas sur le secret de celui-ci.
Le principe du chiffrement de Bitlocker est connu, que le code ne soit pas publié est accessoire. C'est d'ailleurs pour cela que la démonstration utilise Linux pour une fois la clé trouvée monter le disque sous Linux et que celui-ci est lisible.
votre avatar
Je cite Wikipedia (version anglaise) : "The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge."

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).
votre avatar
C'est exactement ce que je pense 🙂
votre avatar
De toutes façons tout se pirate.
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.
votre avatar
En effet des failles en a partout, ça reste quand même plus rassurant quand c'est open source.
votre avatar
La faille n'est pas dans la technologie de chiffrement mais dans un bootloader de Windows ancien que l'on peut toujours utiliser en appliquant la technique expliquée au CCC. Elle permet de récupérer la clé de déchiffrement.

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é.
votre avatar
open source c'est encore pire, la disponibilité du code source va faciliter la recherche de failles
votre avatar
Et elles seront corrigées d'autant plus vite. Mais bon, ici, la faille principale est dans du logiciel propriétaire. On voit que l'ont ait accès au code source ou pas ne change pas grand chose.
votre avatar
@fred42 à raison cela permet de corriger les faille très vite, avec la garantie qu'il n'y ait pas de bac d'or.

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

Fermer