Linux : presser longtemps la touche Entrée permettait de contourner un outil de chiffrement

Linux : presser longtemps la touche Entrée permettait de contourner un outil de chiffrement

Supprimons les claviers

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

15/11/2016 5 minutes
98

Linux : presser longtemps la touche Entrée permettait de contourner un outil de chiffrement

Un bug dans Cryptsetup permet sous Linux de contourner la demande de mot de passe quand l’unité de stockage a été chiffrée. La faille qui en résulte peut être exploitée aussi bien localement qu’à distance. Explications.

C’est un chercheur en sécurité espagnol, Hector Marco, qui a soulevé le lièvre. Celui-ci réside dans l’utilitaire Cryptsetup, très utilisé pour le chiffrement des disques durs et autres SSD, que ce soit sur des machines personnelles, des postes de travail ou des serveurs. Il est exploitable via LUKS (Linux Unified Key Setup), installé par défaut avec Debian et Ubuntu notamment. On le trouve donc sur de très nombreuses machines.

Votre machine est trop lente, réessayez

C’est en inspectant le processus de démarrage que Marco a repéré un souci. Lors de cette phase, un mot de passe est nécessaire pour continuer. Il sert à déverrouiller l’accès aux données chiffrées, la séquence de boot ne l’étant pas. Malheureusement, la gestion de ce mot de passe comporte une faille. Comme expliqué par le chercheur, Cryptsetup s’appuie sur plusieurs scripts de vérification de l’identifiant, et quand le nombre de tentatives dépasse trois (maximum par défaut), la séquence de démarrage relance la procédure d’authentification.

Cette erreur est engendrée par une mauvaise interprétation des actions par les scripts. Cryptsetup considère alors que la machine est lente et qu’elle a besoin d’un peu plus de temps pour laisser l’utilisateur taper son mot de passe en toute tranquillité. En tout, elle peut être relancée jusqu’à 30 fois sur un système de type x86, pour un total donc de 93 tentatives. Le chiffre grimpe même jusqu’à 150 fois sur une machine PowerPC, avec 453 tentatives en tout.

Au bout de la route, un shell et des droits root

Le souci ne serait pas si grave si Cryptsetup n’avait pas été, selon les propres mots du chercheur, « pensé par des développeurs, pour des développeurs », comme un grand nombre de produits du monde Linux. En cas de problème, le développeur trouvera des moyens de s’en sortir, via des outils spécifiques qui n’attendent que lui. Dans le cas de l’utilitaire de chiffrement, il s’agit d'une invite de commande (shell).

Cryptsetup, quand il arrive au bout des tentatives d’authentification, lance un shell Initrd avec des droits root. En d’autres termes, un utilisateur malveillant qui souhaiterait simplement y accéder n’a qu’à contourner les demandes. Pour ce faire, il n’a qu’à laisser la touchée Entrée enfoncée pendant environ 70 secondes. Les tentatives de mots de passe défilent alors et laissent place au shell et à ses commandes.

faille linux Cryptsetup
Crédits : Hector Marco

Localement ou à distance

Toujours selon le chercheur, le pirate qui aurait accès à la machine pourrait réaliser de nombreuses actions. Par exemple, placer un exécutable qui serait alors présent au démarrage pour provoquer plus tard une escalade des privilèges. Il serait même possible de remplacer le kernel.

Les données des partitions, même si elles sont chiffrées, pourraient être copiées vers un périphérique externe en vue d’une attaque par force brute plus tard. Ou plus simplement, le pirate pourrait effacer les données. Il reste que, si l'identification via Cryptsetup peut être contournée, le chiffrement des fichiers en eux-mêmes n'est pas directement affecté.

Cette attaque requiert un accès physique à la machine, mais Hector Marco précise qu’elle peut être exploitée à distance, notamment sur les serveurs cloud, où Linux est monnaie courante. Il ne donne par contre pas d’indication sur ce deuxième cas de figure.

Une faille simple à corriger, des patchs arrivent 

Pour le chercheur, il est évident que ce shell ne devrait pas être présent, ou en tout cas pas dans la configuration par défaut, dans des systèmes conçus pour être exploités tels quels. Les besoins des développeurs ne devraient pas être prioritaires, et rien n’empêcherait une simple option d’être activée plus tard. Sans le shell, le problème de sécurité des mots de passe reste, mais devient nettement moins important, ne laissant finalement « que » 93 ou 452 tentatives selon les cas.

La faille de sécurité, estampillée CVE-2016-4484, est selon lui très facile à corriger. Il a proposé un correctif qui supprime le shell et provoque un blocage du processus de boot tant que le bon de mot de passe n’a pas été entré. On ne sait pas exactement si ce patch a été repris tel quel, mais un correctif a été implémenté dans la version 2:1.7.3-2 de Cryptsetup, même s’il ne s’agit pas encore de la branche stable. Comme l’indique BleepingComputer, le correctif a été diffusé le 7 novembre dans les mises à jour des distributions Debian, mais Canonical a repoussé sa diffusion, pour une raison encore inconnue.

Il faudra donc patienter la diffusion des correctifs. Entre temps, Hector Marco a également découvert que tous les systèmes utilisant Dracut au lieu de initramfs sont également vulnérables, notamment les distributions Fedora.

Même si la faille est très simple à colmater, la simplicité avec laquelle une protection peut être contournée reste surprenante. Elle rappelle largement celle détectée dans Grub2 en fin d’année dernière : on pouvait court-circuiter la demande de mot de passe en pressant 28 fois la touche Retour Arrière (backspace) à cause d’un bug arithmétique. 

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Votre machine est trop lente, réessayez

Au bout de la route, un shell et des droits root

Localement ou à distance

Une faille simple à corriger, des patchs arrivent 

Commentaires (98)


Pour une fois qu’une faille est accessible au commun des mortels ! Par contre je me demande si le mec a découvert la faille par hasard en posant un truc sur son clavier ou si il a exploré le code puis a vu que c’était possible et a essayé.


J’ai checké la date pour vérifier qu’on était pas le premier Avril.&nbsp;<img data-src=" />


Le plus probable, c’est que c’est son chat qui a trouvé en s’endormant sur le clavier


À partir du moment où on a accès physique à la machine, si on veut faire tourner un shell dessus, rien de plus simple qu’une clé UBS pour booter dessus. Ce sera plus rapide qu’attendre 70 secondes le doigt sur la touche entrée.








uzak a écrit :



Le plus probable, c’est que c’est son chat qui a trouvé en s’endormant sur le clavier







Clairement! Les félins sont bien plus forts que les humains pour trouver des bugs informatiques <img data-src=" /> Bientot ils vont voler notre job <img data-src=" />



Ça dépends de la séquence de boot. Gérée par le bios, elle doit pouvoir être figée par un mot de passe.


Ca me rappelle le trucmachin Symantec qui met un mot de passe au boot du PC avant de lancer l’OS avec chiffrage du disque dur.

Dans une ancienne vie on avait constaté à l’époque que retirer/remettre la batterie du PC portable suffisait à bypass la “protection” sur la version utilisée par le client… <img data-src=" />








fred42 a écrit :



À partir du moment où on a accès physique à la machine, si on veut faire tourner un shell dessus, rien de plus simple qu’une clé UBS pour booter dessus. Ce sera plus rapide qu’attendre 70 secondes le doigt sur la touche entrée.



Ok mais en l’occurrence dans ce cas-ci cela ne servirait pas des masses.

“quand l’unité de stockage a été chiffrée”



Pour sécuriser une machine rien de plus simple que de commencer par empêcher les curieux de booter sur autre chose que le disque interne (avec secure boot en bonus, tout ça…) et un gros mot de passe sur l’UEFI ! Non… ?


“Et les 150 000 $ de récompenses sont attribués à Félix, magnifique main coon qui a réussi à pirater Chrome ET Edge en moins de 23 secondes ! revoyons au ralenti comment il s’y prend, il roule sur le clavier, s’y frotte bien fort ! Et voilà !!!! il prend le contrôle !!!”













—–[]


Si c’est dans la séquence de boot, ça veut dire que pour le faire à distance il faudrait être en mesure de faire redémarrer la machine ciblée ?


Euh… Et un mot de passe dans GRUB?



C’est complétement stupide comme truc, il suffit de rajouter init=/bin/bash dans grub (mode edition) pour avoir le même accès sur n’importe quel Linux (chiffré ou pas).



Bref, c’est con mais c’est pas une faille car même corrigée, tu peux faire la même chose…








FunnyD a écrit :



“Et les 150 000 $ de récompenses sont attribués à Félix, magnifique main coon qui a réussi à pirater Chrome ET Edge en moins de 23 secondes ! revoyons au ralenti comment il s’y prend, il roule sur le clavier, s’y frotte bien fort ! Et voilà !!!! il prend le contrôle !!!”













—–[]







Totalement crédible ^^



Et quand l’unité de stockage a été chiffrée ça permets toujours d’extraire les partitions chiffrées et de les attaquer ailleurs plus tard…


Pas besoin de cette faille, comme expliqué plus haut, c’est faisable avec n’importe quel bootloader par défaut…



ps: comment je fais moi sinon pour récupérer un serveur dont on a perdu le mot de passe? :)


Me semble que jusqu’à récemment,&nbsp; le mot de passe du grub était contournable quasiment de la même façon à cause du faille du même genre…



EDIT: après vérification, celle de grub était un peux différente c’est sur backspace qu’il fallait appuyerhttp://linuxfr.org/users/vroum/journaux/un-mot-de-passe-ca-s-efface-chez-grub2 <img data-src=" />


Aucun accès aux données n’est autorisé, le gars s’est juste rendu compte que le clair est vulnérable … et PCI ne l’indique pas :-/



Dans la vrai vie, un HIDS pour le clair, de l’alerting, vérif de la signature du noyau au boot etc…



Déçu de PCNXI sur ce coup la.








thomgamer a écrit :



Pour une fois qu’une faille est accessible au commun des mortels ! Par contre je me demande si le mec a découvert la faille par hasard en posant un truc sur son clavier ou si il a exploré le code puis a vu que c’était possible et a essayé.







La légende urbaine des mecs qui lisent le code pour trouver des failles et les corriger alors que ça marche ?

Ben voyons !

<img data-src=" />




Les chats domineront le monde ! Je comprend mieux les poils que je retrouvais dans mon clavier ! Les attaques DDOS c’est pas des machines zombies, c’est juste des chats qui profitent que leurs maitres soient pas là.








FunnyD a écrit :



“Et les 150 000 \( de récompenses sont attribués à Félix, magnifique main coon qui a réussi à pirater Chrome ET Edge en moins de 23 secondes ! revoyons au ralenti comment il s'y prend, il roule sur le clavier, s'y frotte bien fort ! Et voilà !!!! il prend le contrôle !!!"





-----[]





Les organisateurs ont quand même retiré 100\)
de la récompense parce qu’avec son poids il a pété le clavier&nbsp;<img data-src=" />



Bon, donc le gars a trouvé une faille qui permet de lire une partition qui n’est pas chiffrée, mais pas de lire la partition chiffrée. Ça c’est de la faille !



Je ne comprends même pas ce qu’il imagine ? Qu’à partir du moment où on a une partition chiffrée, le système ne doit pas autoriser le boot sur la partition en clair tant qu’on n’a pas déverrouillé la partition chiffrée ?&nbsp;<img data-src=" />


J’ai l’impression que tu as lu un peu vite


WTF !


Second degré ?&nbsp; Je pense pas que le mec (chercheur en sécurité en l’occurrence) s’est dit : tiens je vais rester appuyer sur entrée pendant 70secondes et voir ce qu’il se passe. Mais vu la faille on peut pas être sur que c’est pas un hasard.


Faut écraser les puces, c’est normale. Difficile de se gratter le dos quand on à pas d’esclave humain sous le coussinets.<img data-src=" />

https://assets-auto.rbl.ms/335783d1cfc6665751c02636c9bcea1114981fbcfd716cdecd1d3…








alex.d. a écrit :



Bon, donc le gars a trouvé une faille qui permet de lire une partition qui n’est pas chiffrée, mais pas de lire la partition chiffrée. Ça c’est de la faille !



Je ne comprends même pas ce qu’il imagine ? Qu’à partir du moment où on a une partition chiffrée, le système ne doit pas autoriser le boot sur la partition en clair tant qu’on n’a pas déverrouillé la partition chiffrée ? <img data-src=" />





La partie qui gère le boot est en clair. Donc avec un accès root sur cette partie, tu peux laisser traîner un script/serveur/virus/ce que tu veux, qui sera exécuté au prochain boot, et qui te donnera accès aux données une fois qu’elles ont été déchiffrées par l’utilisateur légitime.









lpoujol a écrit :



Ça dépends de la séquence de boot. Gérée par le bios, elle doit pouvoir être figée par un mot de passe.







Dans ce cas, on démonte le disque et on le le copie.







nick_t a écrit :



Ok mais en l’occurrence dans ce cas-ci cela ne servirait pas des masses.

“quand l’unité de stockage a été chiffrée”





Ça sert autant que le shell (busybox) auquel on arrive. C’est même mieux, on peut arriver avec les outils dont on a besoin.







fouquetp a écrit :



Pour sécuriser une machine rien de plus simple que de commencer par empêcher les curieux de booter sur autre chose que le disque interne (avec secure boot en bonus, tout ça…) et un gros mot de passe sur l’UEFI ! Non… ?







Pas si sûr. En plus il faut mettre un gros cadenas sur le boîtier, sinon, on extrait le disque et on le copie.









eliumnick a écrit :



Clairement! Les félins sont bien plus forts que les humains pour trouver des bugs informatiques <img data-src=" /> Bientot ils vont voler notre job <img data-src=" />





Ca fait déjà 20 ans que Geobreeders existe.









jpaul a écrit :



La partie qui gère le boot est en clair. Donc avec un accès root sur cette partie, tu peux laisser traîner un script/serveur/virus/ce que tu veux, qui sera exécuté au prochain boot, et qui te donnera accès aux données une fois qu’elles ont été déchiffrées par l’utilisateur légitime.



Je comprends bien, mais si tu ne chiffres pas tout le disque, c’est bien que tu acceptes que cette partie soit en clair.

Si tu veux verrouiller le boot, alors tu chiffres aussi /boot (grub le gère).

&nbsp;



Pas forcément aller à l’opposé. C’était aussi le ressenti d’un vétéran d’AIX contre Linux que j’ai connu dans une ancienne vie.



C’est un peu le revers de produits “communautaires” contre les produits pensés à destination du monde professionnel. Comme le fait d’utiliser la version communautaire d’un produit open source pour faire des économies de bout de chandelle et couiner au moindre pépin que la seule forme de support, c’est un forum et un moteur de recherche.


&lt;TROLL&gt;Finalement les dev de systemd on bien fait de réimplémenter cryptsetup.&lt;/TROLL&gt;


Même principe que pour contourner violemment le verrouillage MdP: On démonte le disque et on va le lire ailleurs.

(et on trouve des systèmes qui préfèrent perdre le contenu du disque si on démonte le boitier)


“Pour le chercheur, il est évident que ce shell ne devrait pas

être présent, ou en tout cas pas dans la configuration par défaut, dans

des systèmes conçus pour être exploités tels quels. Les besoins des

développeurs ne devraient pas être prioritaires, et rien n’empêcherait

une simple option d’être activée plus tard. Sans le shell, le problème de sécurité des mots de passe reste, mais devient nettement moins important, ne laissant finalement « que&nbsp;» 93 ou 452 tentatives selon les cas.”



C’est plus un choix des distributions ça. Cela n’a plus rien à voir avec cryptsetup.








thomgamer a écrit :



Pour une fois qu’une faille est accessible au commun des mortels ! Par contre je me demande si le mec a découvert la faille par hasard en posant un truc sur son clavier ou si il a exploré le code puis a vu que c’était possible et a essayé.





Je suis sur que le mec à une saloperie de chat. <img data-src=" />



edit: grillé.









alex.d. a écrit :



Je comprends bien, mais si tu ne chiffres pas tout le disque, c’est bien que tu acceptes que cette partie soit en clair.

Si tu veux verrouiller le boot, alors tu chiffres aussi /boot (grub le gère).

&nbsp;





+1. Il est tout à fait possible de chiffrer le boot, et même de la placer sur une clé usb ou un CD, microSD etc… Bon courage pour déchiffrer.



Ou alors il a fait comme moi, s’est trompé de mot de passe et a été droppé sur le shell de secours :-’


Bon, moi qui chiffre rien…



…je ne sais pas si je vais m’y mettre un jour, du coup.


Se tromper 93 ou 453 fois, faut être bien persévérant quand même !


Je pense pas que ce soit si grave. Ca demande un accès physique (ou équivalent, console série, kvm…) pour exploiter cette faille et au final, les partitions chiffrées ne sont pas lisibles, et les partitions en clair sont modifiables.



On pourrait sortir le disque du laptop (15 secondes sur un lenovo dans le petit slot latéral), le brancher sur un adaptateur USB et modifier /boot et ce serait plus rapide que d’exploiter cette faille.

A mon avis, le seul moyen sérieux de se protéger contre les accès physiques, c’est d’utiliser des Self Encrypted Disk… Mais tant que ça n’est pas possible, cryptsetup reste une alternative solide…


Sur mon Ubuntu j’ai chiffré mon disque (1 mdp à mettre avant d’ariver à l’ouverture de la session). C’est ça qui utilise Cryptsetup ou pas ? <img data-src=" />








Ricard a écrit :



Je suis sur que le mec à une saloperie de chat. <img data-src=" />



edit: grillé.





On a tous pensé à la même chose en même temps, t’inquiète.

Les felins sont en train de développer une armée de robot qui nous exterminera et nous remplacera comme esclave du chat. Ce que le scénario de Terminator n’a jamais révélé, c’est que derrière les robots c’est des chats qui contrôlent skynet.









fred42 a écrit :



Pas si sûr. En plus il faut mettre un gros cadenas sur le boîtier, sinon, on extrait le disque et on le copie.





Et encore, un coup de dremel (sur le boîtier c’est même plus facile que sur le cadenas) et hop…



A priori, oui.



Vérifie quand tu as entré ton mot de passe, si c’est le cas, il y a un message avec le mot Cryptsetup.


Ok je vérifie demain matin <img data-src=" />



Ou alors je maintiens la touche Entrée pendant 70 secondes <img data-src=" />


Sous Debian j’ai eu la mise à jour.








fouquetp a écrit :



Et quand l’unité de stockage a été chiffrée ça permets toujours d’extraire les partitions chiffrées et de les attaquer ailleurs plus tard…







Ouais ‘fin stadire que le principe du chiffrement de partition, c’est d’être difficilement ou pas du tout déchiffrable. Quand tu chiffres, c’est justement pour t’assurer de ne pas te reposer sur un simple “if mdp != [truc-rentré-au-clavier] { nerienfaire(); }. Tu peux bien extraire la partition chiffrée si ça te chante, et l’attaquer ailleurs, si c’est de l’AES256 avec un mot de passe suffisamment indevinable, ça va t’occuper un moment (quelques milliards de milliards d’années a priori).



lol, vous êtes sérieux ?

&nbsp;

Elle est où la faille ? Il n’y a pas d’accès aux données chiffrées, et heureusement.

Comme cela a déjà été dit, a partir du moment où on a un accès physique à la machine il suffit d’un LiveUSB ou d’extraire le disque pour le brancher ailleurs afin d’obtenir le même résultat (avec un simple chroot).



Cette nouvelle “faille” est en train de faire le buzz sur la toile mais c’est totalement ridicule, c’est plus un “bug” du prompt qu’une faille.


La faille de sécurité qui n’en ai pas vraiment une… Avec un accès physique à la machine on peut faire tellement pire qu’avoir un prompt en root… Si on veut vraiment bien sécuriser la chose cela commence à devenir “technique” : Verrouiller le BIOS, le chargeur de démarrage, rendre impossible le boot sur tout autre media, et bien sûr rendre impossible d’ouvrir physiquement la machine.








fred42 a écrit :



À partir du moment où on a accès physique à la machine, si on veut faire tourner un shell dessus, rien de plus simple qu’une clé UBS pour booter dessus. Ce sera plus rapide qu’attendre 70 secondes le doigt sur la touche entrée.





Si c’était comme ça les utilisateurs auraient déjà semer le chaos à certains endroits où je bosse.

La machine ne démarre que sur le disque interne via un .efi précis



C’est + le “a distance” le vrai soucis de la faille , tomber en root sur un serveur, même si t’as pas accès aux donnée, tu as de quoi t’amuser ….


Oui, enfin si tu as un accès physique à la machine, on s’en fout que la machine boot pas un autre disque dur. Ce sont les données présentes sur le disque du qui est présent dedans initiallement qui sont intéressantes et qu’on peut potentiellement lire sur une autre machine.


C’est exploitable à distance, cf l’article.









benjarobin a écrit :



La faille de sécurité qui n’en ai pas vraiment une… Avec un accès physique à la machine on peut faire tellement pire qu’avoir un prompt en root… Si on veut vraiment bien sécuriser la chose cela commence à devenir “technique” : Verrouiller le BIOS, le chargeur de démarrage, rendre impossible le boot sur tout autre media, et bien sûr rendre impossible d’ouvrir physiquement la machine.







DomabaZ a écrit :



Oui, enfin si tu as un accès physique à la machine, on s’en fout que la machine boot pas un autre disque dur. Ce sont les données présentes sur le disque du qui est présent dedans initiallement qui sont intéressantes et qu’on peut potentiellement lire sur une autre machine.






Oui, si ce n’est que à part via des systèmes dans le genre intel ILO, je ne vois pas en quoi cette faille serait exploitable à distance. Je pense que le défaut de sécurisation de l’accès est plus important encore. Ceci dit, une fois cet accès disponible sur une machine éteinte, on peut toujours mettre en place une backdoor.


j’espère que vous ne le prendrez pas mal mais du coup le titre fait un peu putaclick par rapport à la faille réelle, non ? <img data-src=" />


exactement, même si le bios ou GRUB est verrouillé par mot de passe il suffit de sortir le disque et de le brancher sur une autre machine.

Le correction de ce bug ne changera pas grand chose à ce niveau là: un accès physique permet d’introduire dans la partition de boot ce qu’on veut… logiciels espions inclus.



La seule solution c’est d’utiliser un boot signé style “secure boot”








psn00ps a écrit :



C’est exploitable à distance, cf l’article.







Ouais ‘fin… c’est exploitable à distance quand t’as un accès “physique virtuel” à distance (style kvm ip) quoi, ni plus ni moins que n’importe quelle faille locale.



quelqu’un qui a un accès kvm ip style “iDrac” ou “IPMI” peut de toute façon généralement faire booter ce qu’il veut. Donc ça ne change rien pour lui, il pouvait déjà écrire ce qu’il voulait dans la partition de boot, même sans cette faille.








psn00ps a écrit :



C’est exploitable à distance, cf l’article.





Bullshit, c’est pas expliqué comment.

En général, t’as pas encore le réseau sur la machine avant de débloquer les partitions systèmes, donc à distance, c’est via un moyen détourné (console série, kvm en ligne, etc).









psn00ps a écrit :



C’est exploitable à distance, cf l’article.



Bah moi je veux voir le usecase à distance. Si c’est avec ipmi, une faille qui demande un accès ipmi, ça n’est pas vraiment une faille. Si c’est du “cloud” comme indiqué, alors en cloud le seul truc que tu bootes à distance, c’est ta vm où de toute façon tu es déjà root.

Je ne vois pas dans quel scénario, en cloud, tu as accès à la console de boot sur une machine distante (virtuelle ou non) sur laquelle tu n’es pas déjà l’admin.

&nbsp;

Mais de toute façon, on revient toujours au problème initial : si ton /boot n’est pas chiffré, tu acceptes implicitement que quelqu’un avec accès physique puisse aller le bidouiller (mais n’accède pas à tes données sur la partition chiffrée) ; si tu veux te protéger de ça, tu chiffres aussi /boot, et pour ça, les solutions techniques existent.

&nbsp;

Cette faille, c’est juste : si tu laisses ton /boot en clair, alors il n’est pas chiffré. Quel découverte !

&nbsp;









lpoujol a écrit :



Ça dépends de la séquence de boot. Gérée par le bios, elle doit pouvoir être figée par un mot de passe.











fouquetp a écrit :



Pour sécuriser une machine rien de plus simple que de commencer par empêcher les curieux de booter sur autre chose que le disque interne (avec secure boot en bonus, tout ça…) et un gros mot de passe sur l’UEFI ! Non… ?





Dans les deux cas ci-dessus : si accès à la machine physiquement : game over. Au pire démontage en règle du disque pour l’analyse une fois mis dans un boitier USB. &nbsp;Seule option : SSD soudé à la CM. Et encore…. si les connectiques sont accessibles…

&nbsp;







fouquetp a écrit :



Et quand l’unité de stockage a été chiffrée ça permets toujours d’extraire les partitions chiffrées et de les attaquer ailleurs plus tard…





il suffit de croiser les chiffrement et d’utiliser une machine virtuelle : &nbsp;partition chiffrée contenant une vm elle même chiffrée et des fichiers de données chiffrés différement. Triple chiffrement avec des méthodes et des mots de passe différents.&nbsp;



&nbsp;Comment ça parano ?<img data-src=" /><img data-src=" />









alex.d. a écrit :



B

Mais de toute façon, on revient toujours au problème initial : si ton /boot n’est pas chiffré, tu acceptes implicitement que quelqu’un avec accès physique puisse aller le bidouiller (mais n’accède pas à tes données sur la partition chiffrée) ; si tu veux te protéger de ça, tu chiffres aussi /boot, et pour ça, les solutions techniques existent.

 

Cette faille, c’est juste : si tu laisses ton /boot en clair, alors il n’est pas chiffré. Quel découverte !





techniquement une signature suffit, c’est à dire vérifier que la partition n’a pas été modifiée par quelqu’un de non habilité. <img data-src=" />



Avouons tout de même que “contourner un outil de chiffrement” c’est un peu racoleur comme titre.



Ca contourne l’authentification par mot de passe, et c’est déjà assez grave en soi.

Le chiffrement n’est pas contourné… puisque les données sont toujours chiffrées.


Ce doit être pour cette raison qu’ Apple soude ses SSD sur certains de ses portables…&nbsp;&nbsp; <img data-src=" />


Ne t’en fait pas, il suffit de passer un argument au noyau pour arrivé sur le même shell que le chercheur (qui a l’air d’autant connaitre Linux que ma grand mère).








127.0.0.1 a écrit :



Avouons tout de même que “contourner un outil de chiffrement” c’est un peu racoleur comme titre.





Je trouve aussi. Quand on lit ce titre on pense qu’on peut contourner le chiffrement du disque et accéder aux données sans la clef, ce qui est faux.



En plus « un outil de chiffrement » : Je sais bien qu’on n’est pas sur un site spécialisé, mais Cryptsetup c’est suffisamment connu et répandu sous Linux pour qu’on le cite par son nom. C’est comme dire « Un outil de chiffrement pour Windows contient deux failles, dont une critique » au lieu de citer TrueCrypt.



Bref, je ne sais pas si ça se fait habituellement sur NXI, mais une correction du titre pour une version plus correcte et moins racoleuse serait la bienvenue.



roh le titre putaclick …. en aucun cas ca permet de contourner le chiffrement, les disques restent inaccessible …

ca craint la de faire ca.


Ca me rappelle une vielle histoire de Mandrake le magicien dans le Journal de Mickey (vers 1984-1988 <img data-src=" />) …

Les chats sont en réalité des extra-terrestres qui avaient leur serviteurs robots donnés des millions d’années plus tôt par d’autres entités. Un jour ils ont rencontré leur homologues chiens : les robots se sont entretués jusqu’au dernier et ont détruits leur planète mutuelle. Ils se sont exilés sur la terre depuis l’âge du feu et ils se servent de nous comme serviteurs … sauf qu’ils ont découvert là aussi des chiens préhistoriques (mais arriérés) qui étaient déjà les copains des humains.

Bref, en sous-main, la société secrète des chats domine le monde.








Vincent_H a écrit :



J’ai l’impression que tu as lu un peu vite







Je pense que c’est une référence à cela : “Il reste que,&nbsp;si l’identification via Cryptsetup peut être contournée,

le chiffrement des fichiers en eux-mêmes n’est pas directement affecté.”



On pourrait argumenter sur le choix du verbe “contourner” dans ce contexte, ou ce que veut dire “n’est pas directement affecté”.

Même la tête de chapitre “localement ou à distance” est de trop. Pour que ce soit accessible à distance, il faudrait un pilote réseau chargé avant le déchiffrement de la partition système, ce qui extrêmement peu courant et hautement improbable, ou un accès style KVM sur IP qui est effectivement fourni par les services de Cloud et qui est pratiquement identique à un accès physique au clavier de la machine.

Quand bien même ils auraient alors accès à un shell root, ils l’auraient de toute manière eu avec le shell de secours de Grub ou simplement en redirigeant le boot de la machine sur un ISO ou une autre image quelconque.

Au final cette faille ne me

paraît guère inquiétante, et le titre est bien trop sensationnaliste

pour ce que c’est.



En outre, chez Next INpact vous devez bien vous douter que beaucoup de lecteurs n’auront lu que le titre, ou les têtes de paragraphe, ou la moitié des phrases ou paragraphe. Il serait de mauvaise foi de prétendre que ce genre de lecteur ne va pas repartir avec l’impression que les données chiffrées sont accessibles.



À mon avis, le non-accès aux données chiffrées aurait mérité au minimum une mention dans une tête de paragraphe.









Firefly’ a écrit :



C’est + le “a distance” le vrai soucis de la faille , tomber en root sur un serveur, même si t’as pas accès aux donnée, tu as de quoi t’amuser ….





Pas de détails donnés sur l’aspect à distance.

&nbsp;

Comme beaucoup j’imagine que cela fait référence aux consoles iDrac, IPMI ou iLO. Et j’ai envie de dire que si un attaquant à accès à ce genre de console, il peut déjà faire ce qu’il veut (arrêter le serveur, sortir ses logs, charger une iso pour booter dessus…).



Quand on s’appelle Marco, on est forcément un chercheur hors pair.





<img data-src=" /><img data-src=" />








fouquetp a écrit :



Et quand l’unité de stockage a été chiffrée ça permets toujours d’extraire les partitions chiffrées et de les attaquer ailleurs plus tard…



Bah oui, c’est vrai que c’est tellement simple&nbsp;<img data-src=" />



Pour moi ce n’est pas une « faille ». Une faille (ou vulnérabilité), c’est un bug non prévu par les développeurs, qui permet à une personne malveillante d’avoir des droits qu’il ne devrait pas avoir (accès root, accès à certains fichiers, etc.). Si la faille est prévue par les développeurs, alors on n’appelle plus ça une faille mais une backdoor…



Là, c’est plutôt un programme qui a été mal conçu. On est typiquement dans le defective by design. Cryptsetup est censé chiffrer les partitions et les protéger. Mais un développeur a volontairement fait en sorte qu’au bout d’un certain nombre de tentatives, le programme laisse tomber et donne un shell avec accès root. Comment cela peut-il sembler être une bonne idée ? Personne ne s’est aperçu que ça va complètement à l’encontre de ce que l’outil est censé faire ? <img data-src=" />



Bref, pas un bug ni une faille, mais une mauvaise décision des programmeurs…








Konrad a écrit :



Là, c’est plutôt un programme qui a été mal conçu. On est typiquement dans le defective by design. Cryptsetup est censé chiffrer les partitions et les protéger. Mais un développeur a volontairement fait en sorte qu’au bout d’un certain nombre de tentatives, le programme laisse tomber et donne un shell avec accès root. Comment cela peut-il sembler être une bonne idée ? Personne ne s’est aperçu que ça va complètement à l’encontre de ce que l’outil est censé faire ? <img data-src=" />



Ce n’est pas un shell root, c’est un shell initrd, le système chiffré n’est pas encore monté.

Tu as la même chose en passant un paramètre via grub. Mais ta partition chiffrée reste chiffrée.

&nbsp;

&nbsp;Au bout d’un certain nombre de tentatives sans réussir à trouver le bon mot de passe, il en reste avec ce qu’il a en l’état, le shell initrd, c’est-à-dire qu’il ne poursuit pas l’init, il reste dans le shell qui sert à configurer l’init.









benjarobin a écrit :



La faille de sécurité qui n’en ai pas vraiment une… Avec un accès physique à la machine on peut faire tellement pire qu’avoir un prompt en root… Si on veut vraiment bien sécuriser la chose cela commence à devenir “technique” : Verrouiller le BIOS, le chargeur de démarrage, rendre impossible le boot sur tout autre media, et bien sûr rendre impossible d’ouvrir physiquement la machine.





Donc tu dois bien comprendre le problème … puisque dans ce cas précis, et avec toutes les précautions que tu as pris, bah justement la faille te permet quand même d’avoir un accès root.



C’est bien sûr vrai que si on a un accès physique on a accès potentiellement à tout. Sauf qu’il y a différents niveaux d’accès physique, qui vont de “j’ai accès seulement à un clavier/souris (machine sous clé) et je ne suis pas seul dans la pièce, à j’ai la possibilité de tout démonter parce que personne n’est dans les environs.



Ici la faille me permet de booter en shell sur l’os installé, y mettre un script qui m’y donnera accès plus tard (et toujours en root) quand le disque sera déchiffré, et ceci seulement en ~1-2min avec seulement un accès clavier. Après intervention, il n’y a quasi aucune trace de mon passage, le disque dur est toujours là. Et si je suis vraiment motivé et que j’ai un accès USB, je peux même automatiser ça avec un device qui tape à ma place.



Je veux bien que la faille ne s’applique pas à beaucoup de cas mais ça me parrait raisonable de penser qu’un véritable attaquant dans la vraie vie qui souhaite agir discrètement ne va pas désosser une machine et se barrer avec le disque sous le bras. D’autant qu’il n’aura pas accès aux données chiffrées hors bruteforce.



<img data-src=" />


En fait, la vrai “faille” c’est qu’il manque le moyen d’empêcher le script de fallback sur la console d’initrd. Un flag “debug” ou “interactive” et le tour est joué… <img data-src=" />



Enfin je pense que tout est dit dans les commentaires. L’article lui est pauvre et sans intérêt. Je m’inscris sur la liste des déçus ici.








ZoZo a écrit :



Au final cette faille ne me

paraît guère inquiétante, et le titre est bien trop sensationnaliste

pour ce que c’est.





Ca te donne un shell root, tu peux remplacer le kernel, et le tout à distance.

Guère inquiétant.<img data-src=" />









psn00ps a écrit :



Ca te donne un shell root, tu peux remplacer le kernel, et le tout à distance.

Guère inquiétant.<img data-src=" />





“A distance” faut le dire vite.

Il faut un accès physique (ou même virtuellement physique) ce qui n’est pas si évident à avoir à la base… à distance.

Si tu laisses ton kvm ip ou ta console cloud ouverte, pas besoin de cette “faille” pour foutre la merde <img data-src=" />









Firefly’ a écrit :



<img data-src=" />







C’est gentil merci. <img data-src=" />







<img data-src=" /><img data-src=" />



Attention, rien n’indique que l’argument init soit géré par l’initramfs avant la partie déchiffrement, et du coup tu drop sur le shell par défaut. et pas sur ton /bin/bash. Fonctionnellement c’est identique mais l’origine du shell est différente.



A vérifier dans les implémentations modernes des initramfs des distri.


Dans la très très grande majorité des cas, avec cette “faille” tu ne peux à peu près rien faire de plus que ce que tu pourrais faire avec un accès physique au clavier et au bouton démarrer du PC, ce dont tu as besoin de toute manière pour l’exploiter (cf plus bas pour l’accès distant).

&nbsp;

Le seul cas que je vois où cela change quelque chose est si le BIOS est verrouillé, et l’accès au shell de secours du boot manager (Grub) n’est pas possible, et soit tu ne peux pas faire de reset du CMOS sur la carte mère soit le BIOS protège le disque dur et le rend inutilisable en cas de reset du CMOS. Alors, et seulement alors, l’attaquant obtient une surface d’attaque supplémentaire via le shell initrd. Ce qu’il peut en faire dépend de ses connaissances, il n’a aucun accès réseau, aucune source de données externe accessible (en supposant que les ports USB soient désactivés dans le BIOS auquel il n’a pas accès dans ce scénario), n’a que la saisie par clavier comme possibilité, et un temps limité car le serveur est en phase de démarrage donc forcément down donc ce n’est pas discret.

&nbsp;

L’accès à distance n’est possible que via IPMI ou KVM sur IP. Si l’attaquant a accès à cela, alors déjà il y avait une faille dans la protection de l’accès à l’IPMI ou du KVM sur IP, et ensuite, il se retrouve exactement dans le cas de l’accès physique au bouton démarrer et au clavier.

Autrement dit, c’est comme si un complice avait pu entrer par infraction pour s’assoir en face du PC, qu’il était capable de voir l’écran, de taper au clavier, et d’appuyer sur le bouton d’allumage du PC, que tu l’appelais par téléphone pour lui donner des instructions, et que t’appelais ça un accès à distance.



Bref, soit ça n’apporte aucune surface d’attaque supplémentaire, soit il faut réunir un grand nombre de conditions pour que cela en apporte une, et de toute manière elle est très difficilement exploitable. Donc en effet, cela devrait être guère inquiétant pour une très grande majorité des gens.


c’est pour ça que la signature du boot est une excellente solution technique (mais complexe à mettre en place). Car même avec ce genre de bug il serait impossible de modifier la partition de boot si on n’a pas les clés de signature. <img data-src=" />








Lodd a écrit :



Seule option : SSD soudé à la CM.





ce placement produit dégueulasse pour Apple… <img data-src=" />

<img data-src=" /> <img data-src=" />









psn00ps a écrit :



Ca te donne un shell root, tu peux remplacer le kernel, et le tout à distance.

Guère inquiétant.<img data-src=" />



Relis bien les commentaires depuis le début :

– à distance : rien n’est prouvé, c’est plus que douteux ;

– un shell root : non, un shell initrd. Le système de fichier racine n’est pas encore monté, tu n’as que l’initrd.

– tu peux remplacer le kernel : techniquement oui, mais tu es dans un environnement sans outil (rootfs pas monté, encore moins /usr), sans réseau, sans accès disque. Bref, tu patches le noyau avec ton shell (même pas sûr que tu aies ed). Balèze.

Et le tout n’est valable que si /boot n’est pas chiffré. Si tu ne chiffres pas /boot, tu es bien conscient qu’il y a ce genre de limite. Si tu veux être sûr, tu chiffres /boot, et cette “faille” tombe à l’eau.

Or un sysadmin qui veut vraiment verrouiller son système contre une attaque menée depuis la console chiffre forcément /boot, sinon c’est un charlot et mérite Paul Emploi.









Konrad a écrit :



Personne ne s’est aperçu que ça va complètement à l’encontre de ce que l’outil est censé faire ? <img data-src=" />







Non, parce que ce n’est pas le cas. Les partitions restent chiffrées et protégées. Seule la partie non-chiffrée est accessible. Par définition, un outil de chiffrement n’a pas vocation à protéger ce que tu décides de ne pas chiffrer.



Exactement.

A noter que le probleme ne vient pas de cryptsetup lui même et que cette ‘faille’ reste accessible même si cryptsetup de renvoie pas vers un shell.



Faire du chiffrement ‘integral’ avec cryptsetup est juste la pour empecher des personnes d’acceder au contenu des disques en cas d’acces physique et de vol des disques. Il n’a pas vocation a faire de la détection d’intrusion.



Il faut coupler le chiffrement des données avec une detection d’intrusion (à l’ouverture du boitier par exemple) ainsi que l’utilisation d’un TPM (par exemple) et de secure boot pour:




  1. valider qu le matériel n’a pas changé entre deux redemarrages

  2. Valider que le noyau et ce qui va être chargé au demarrage (et qui n’est pas chiffré) a bien été signé par une autorité de confiance et n’a pas été modifié par une autre personne. Il faut bien évidemment garder la clé privée qui a servi à la signature dans un endroit sécurisé…


Des données chiffrées








WereWindle a écrit :



ce placement produit dégueulasse pour Apple… <img data-src=" />

<img data-src=" /> <img data-src=" />





Ça aurait pu mais même pas, mon asus eeebook a un ssd soudé à la cm aussi (32 Go) une plaie à passer sous GNU/Linux.&nbsp;



Sinon ça devient urgent de se protéger un chouia au vu des lois à la con votées…



Comme tu dis !



Je me demande bien en quoi c’est une faille… On parle d’un boot chiffré avec LUKS là, et d’accès à la machine (le gars prétend que c’est possible en accès distant, sans donner de preuve).



Et effectivement, à partir du moment où on a accès à la machine, la belle affaire de contourner un boot avec LUKS : DVD, clé USB, netboot, etc… tout fait l’affaire, et on a tout autant les droits root.



Par ailleurs, la soit disant “faille” ne remet absolument pas en cause la sécurité des données chiffrées, elle débouche sur sur shell root (car on est en root à cette phase du démarrage), lequel shell root on peut obtenir de multiples autres façons avec un accès physique.



Quant à recopier les données chiffrées pour les brute-forcer ailleurs : qu’est-ce que ça change cette “faille” si on a un accès physique ? On peut même démonter le disque, le mettre sur on PC à soi pour le copier physiquement bit à bit et remettre le disque en place.



Bref, c’est en réalité juste une fonctionnalité maladroite qu’il convient effectivement de retirer, mais difficile de penser que c’est une faille grave malgré le sensationnalisme journalistique (sur ce coup c’est pire chez The Reg !)


Et donc est-ce qu’on aura droit à une news pour corriger le tir ou au moins à un update de celle-ci histoire de faire un minimum sérieux ?








Konrad a écrit :



Mais un développeur a volontairement fait en sorte qu’au bout d’un certain nombre de tentatives, le programme laisse tomber et donne un shell avec accès root. Comment cela peut-il sembler être une bonne idée ? Personne ne s’est aperçu que ça va complètement à l’encontre de ce que l’outil est censé faire ? <img data-src=" />





En faite cryptsetup ne fait que abandonnée. le initrd ne peut alors pas monter la partition root.

&nbsp;

Ce qui se passe ensuite dépend de comment la distribution a configuré initrd.



Sous Debian quand on arrive pas à monter la partition root, par défaut un shell est ouvert (sauf si le kernel parameter panic est passé). Mais il me semble qu’il demande tout de même le mot de root.



Pour les distributions qui utilise dracut (Fedora,Red Hat, CentOS…) cela dépend de la config de dracut. Mais quand on utilise cryptsetup dans toutes les distributions que j’ai testé cela désactive le shell.



Et puis quoi encore ?

Tu n’aurais pas voulu une analyse critique dans l’article non plus ?

Quelqu’un annonce ce qu’il appelle une faille, on ne va quand même pas remettre en cause ce qu’il dit.


N’importe quoi !!!



“Cette attaque requiert un accès physique à la machine, mais Hector Marco précise qu’elle peut être exploitée à distance, notamment sur les serveurs cloud, où Linux est monnaie courante. Il ne donne par contre pas d’indication sur ce deuxième cas de figure.”



elle n’est pas faisable à distance, le gars qui a appuyé comme un boeuf sur ENTER , ment !!!!

il faut un accès physique pour accéder à la séquence de boot !



Le mec parle de cloud .. ben oui une machine virtuel si tu peux la rebooté , via une console on a accés à la séquence de boot … donc c’est commeun accés physique !



bref une faille qui n’est qu’une faille de cryptsetup … donc aucunement LINUX


+1


… yep, cela occupe l’humain, on dira !


Et ce n’est meme pas un problème dans cryptsetup :



This is problem in intramfs scripts only (these are not part of cryptsetup project), it is neiter bug in cryptsetup nor in LUKS. Some distributions could add these scripts to distributed package, please check your distro updates for more info.



https://gitlab.com/cryptsetup/cryptsetup/