Bootkitty : Linux a son premier bootkit UEFI
C'est mal fait, mais ça fonctionne
Des chercheurs ont découvert un premier bootkit pour Linux capable de contourner la chaine de sécurité de l’UEFI. Une exploitation de l’une des failles LogoFAIL, alors qu’elles étaient considérées jusqu’à maintenant comme théoriques.
Le 02 décembre à 13h37
6 min
Sécurité
Sécurité
Linux est considéré comme plus à l'abri que Windows face aux menaces informatiques. Si l’on se penche sur les bootkits, c’est effectivement le cas. Un premier PoC est arrivé en 2012 sur un bootkit capable de contourner la chaine de sécurité de l’UEFI. Les premiers activement exploités sur Windows ont été ESPecter, découvert par ESET, et FinSpy, trouvé par Kaspersky, tous deux en 2021. Puis BlackLotus est apparu l’année dernière : le premier bootkit Windows capable de contourner intégralement Secure Boot.
Linux a maintenant le sien. Ou plutôt, Linux a désormais un proof of concept (PoC), parfaitement fonctionnel, trouvé sur un serveur et apparemment inexploité. Caractéristique principale de Bootkitty – puisque c’est le nom donné par ses auteurs – il se sert de l’une des failles LogoFAIL, découvertes il y a un an. Or, on pensait ces failles toutes théoriques. Bootkitty rebat les cartes.
À la racine de l’attaque, les failles LogoFAIL
LogoFAIL désigne un lot de douze failles qui ont fait parler d’elles à la fin de l’année dernière. Le nom annonce la couleur : il est possible d’utiliser l’image bitmap servant à afficher un logo au démarrage du PC pour intégrer un code shell malveillant. Difficile à exploiter, les chercheurs n’avaient trouvé aucun cas d’utilisation de LogoFAIL jusqu’à ce jour. En outre, Intel et AMD avaient corrigé ces failles en décembre 2023. Mais comme toujours avec les firmwares des cartes mères, les mises à jour n’ont pas été installées partout.
Dans le cas de Bootkitty, le code shell a pour mission d'installer une clé cryptographique, explique ESET. Celle-ci sert à signer numériquement un fichier GRUB (un gestionnaire de démarrage pour Linux) et un noyau Linux spécifique, qui sera exécuté plus tard dans la chaine de démarrage du système. Ces composants, puisqu’ils sont signés, sont traités comme des éléments de confiance par l’UEFI. La porte dérobée est ainsi ouverte avant que d’autres processus de sécurité n’entrent en piste.
S’il s’agit bien d’un bootkit, il se fait en quelque sorte à la périphérie, car le code malveillant appelle d’autres composants pour réaliser des actions. Le firmware UEFI se retourne contre lui-même, en validant l’authenticité de composants tiers, mais ne contient pas lui-même le code malveillant.
Un code de mauvaise qualité
Selon les découvertes d’ESET, Bootkitty a été développé par un certain BlackCat, sans que l’on sache s’il s’agit d’une personne ou d’un groupe. Il n’y aurait pas de lien avec le groupe BlackCat déjà connu pour ses ransomwares, ceux-ci étant exclusivement écrits en Rust, quand Bootkitty est écrit en C. Plusieurs noms sont indiqués dans l’un des fichiers, et l’un d’eux renvoie vers un dépôt GitHub, mais sans dépôt public mentionnant Bootkitty.
Les chercheurs se sont également rendu compte qu’en l’état, Bootkitty est surtout capable de n’infecter qu’Ubuntu. Le code malveillant cherche en effet à identifier des séries d’octets spécifiques en mémoire pour en changer les valeurs à la volée. Or, ces séries sont codées en dur et sont donc intimement liées au système.
Le code en C comporte aussi de nombreuses erreurs, toujours selon ESET. Par exemple, Bootkitty est capable de patcher le noyau Linux pour y installer des instructions. Problème, il ne cherche pas à détecter la zone à modifier, il intègre ses lignes de code à des positions fixes, qui parfois ne sont pas les bonnes. Le noyau, au lieu d’être patché, ne fonctionne alors plus, faisant planter tout le système.
En outre, de lui-même, Bootkitty ne peut pas contourner Secure Boot, car il est accompagné d’un certificat autosigné. Pour y parvenir, il doit réussir l’exploitation de LogoFAIL. Si la faille a été corrigée, le bootkit n’a plus aucun moyen d’agir.
Pour une poignée de bitmaps
Si ESET a bien découvert Bootkitty, le lien avec LogoFAIL a été établi par une autre entreprise de sécurité : Binarly. Celle-ci est spécialisée justement dans la sécurité des firmwares et la gestion de la chaine d’approvisionnement.
Dans un article publié vendredi soir, la société explique avoir immédiatement repéré deux images au format bmp sur le serveur sur lequel était stocké Bootkitty, présent sous la forme d’un fichier bootkit.efi. Or, les noms de ces images ne leur étaient pas inconnus : logofail.bmp et logofail_fake.bpm. Il s’agissait des noms utilisés par Binarly lors de sa présentation sur le sujet à la conférence BlackHat EU de l’année dernière.
La découverte de ces deux fichiers – l’un de 16 Mo, l’autre de 7,7 ko – dans le même dossier qu’un firmware a fait se poser la question aux chercheurs : quelqu’un avait-il trouvé le moyen d’exploiter LogoFAIL ? On connait la réponse, confirmée après analyse du fichier de 16 Mo, dans lequel du code shell a été trouvé au sein d’une structure jugée « inhabituelle ».
Un PoC « seulement »
Faut-il s’inquiéter ? Pas encore, mais la vigilance s’impose. La découverte de Bootkitty signale que des acteurs malveillants travaillent activement sur la question. D’un autre côté, ESET signale que le code de Bootkitty est encore assez rudimentaire, comparé à ceux existant pour Windows, et que certaines fonctions sont inopérantes. En outre, il ne sait apparemment infecter qu’Ubuntu et ne peut pas contourner Secure Boot sans exploiter une faille dont les correctifs sont disponibles depuis un an.
Sur la base de ces observations, les chercheurs ESET en ont déduit que Bootkitty est probablement une version de démonstration, un PoC parfaitement fonctionnel mais n’assurant que le minimum, le code comportant de nombreuses « imperfections ». Même son de cloche chez Binarly, qui a complété les découvertes d’ESET. Cette dernière dit n’avoir trouvé aucune exploitation active de Bootkitty, mais cela ne présage en rien de l’avenir.
« Qu'il s'agisse d'une preuve de concept ou non, Bootkitty marque une avancée intéressante dans le paysage des menaces UEFI, brisant la croyance selon laquelle les bootkits UEFI modernes sont des menaces exclusives à Windows », indique ainsi ESET.
Pour l’instant, la seule solution efficace pour se prémunir de Bootkitty et de ses éventuelles évolutions est d’installer le dernier firmware disponible pour la carte mère de l’ordinateur.
Bootkitty : Linux a son premier bootkit UEFI
-
À la racine de l’attaque, les failles LogoFAIL
-
Un code de mauvaise qualité
-
Pour une poignée de bitmaps
-
Un PoC « seulement »
Commentaires (20)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 02/12/2024 à 14h00
Deuxième vraie question : quelles sont les marques principalement touchées ?
Le 02/12/2024 à 14h15
Il faut dire qu'ils utilisent tous la même bibliothèque trouée qui alloue de la mémoire pour la bitmap sans contrôler la taille demandée (utilisation de la largeur et de la hauteur de l'image contenue dans le fichier bitmap).
Le 02/12/2024 à 14h26
J'ai appris a paré ça en DUT pendant mon stage, y'a 20 ans ...
Encore des sachants qui codent avec les pieds gauches avec des ongles incarnés c'est pas possible de laisser ce genre de trou béant. (je code plus depuis des années).
Le 02/12/2024 à 15h48
Le 02/12/2024 à 15h49
Le 02/12/2024 à 17h27
Le 02/12/2024 à 14h52
Le 02/12/2024 à 15h03
Le 02/12/2024 à 15h19
Le 02/12/2024 à 19h05
Le 02/12/2024 à 22h54
En gros il faut choisir de bon fabriquant...
Hier à 11h09
Le 02/12/2024 à 15h04
Le 02/12/2024 à 15h35
Modifié le 02/12/2024 à 15h30
Je ne cracherais pas dans la soupe pour pouvoir déverrouiller un peu l'UEFI de mon laptop et modifier/débloquer des paramètres qui ne sont pas accessibles du fait des restrictions du fabricant, obtenir un contrôle fin de ma machine, faire de l'undercloking... (J'en faisais sur un i5, ce qui faisait une réelle différence, mais sur un Zen, pas moyen)
De même pour activer les paramètres nécessaires pour faire du gpu passthrough avec seulement l'APU AMD...
Le 02/12/2024 à 15h47
Sinon je ne suis pas sûr que la faille te soit très utile, est-ce que ton code aura plus de privilèges qu'un .efi que tu exécuterais toi-même ?
Le 02/12/2024 à 23h14
le POC est surement tres joli techniquement mais combien de gnu/linux (serveur/desktop) ont le secure boot d'activé? ;)
Hier à 10h34
Hier à 22h06
Aujourd'hui à 01h19
Heureusement, c'est rentré dans l'ordre après avoir recréé l'entrée de boot manquante grâce à efibootmgr mais j'ai eu un instant de frayeur