BootKitty, l'esquisse d'une menace nouvelle sur les systèmes Linux

Les bootkits UEFI, c'est aussi sur Linux.

Telle est la principale information à retenir d'une des dernières analyses d'ESET. Elle porte sur le dénommé BootKitty.

De nombreux éléments suggèrent qu'il s'agit d'un PoC, pas encore déployé largement - et d'aileurs pas prêt pour. S'il a effectivement la particularité d'être conçu pour les systèmes Linux, le malware ne peut cibler, en l'état, que quelques versions d'Ubuntu. Tout du moins d'après la souche étudiée. En l'occurrence, un fichier bootkitty.efi uploadé en novembre 2024 sur VirusTotal.

Un périmètre d'action limité par le codage en dur

BootKitty contient deux fonctions (inutilisées) capables d'afficher des chaînes de caractères pendant l'exécution. L'une écrit le nom du bootkit en ASCII art ; l'autre, ce qui s'apparente à une liste d'auteurs et de contributeurs.

Puisqu'il utilise un certificat autosigné, BootKitty ne peut s'exécuter lorsque Secure Boot est activé, sauf si les attaquants sont parvenus à y installer ledit certificat.

La couverture limitée des systèmes Linux tient à l'exploitation de patterns codés en dur. Ce ne sont pas, constate ESET, les meilleurs pour englober un grand nombre de versions du noyau et de GRUB. De même, l'usage d'offsets là aussi codés en dur pour patcher le kernel réduit encore plus le périmètre d'action. Aussi Bootkitty peut-il en arriver à modifier aléatoirement du code et des données, entraînant non pas des compromissions, mais des crashs.

Une chaîne de modules noyau malicieux

Une fois exécuté par le shim, BootKitty lance une version légitime de GRUB et modifie plusieurs fonctions en mémoire. Parmi elles, start_image, que GRUB invoque pour lancer vmlinuz. Ainsi que grub_verifiers, qui sert à contrôler l'intégrité des vérificateurs de fichiers (BootKitty la trafique de sorte qu'elle ne procède à aucune vérification de signature).

Lorsque l'image kernel est décompressée, BootKitty modifie la fonction module_sig_check afin que tout module soit chargé sans vérification. Il remplace par ailleurs la première variable d'environnement du processus init pour charger prioritairement deux objets ELF partagés. Leur finalité n'est pas claire à ce stade. Ils semblent simplement ouvrir la voie au chargement d'autres fichiers malveillants.

BootKitty laisse diverses traces. Il modifie par exemple le nom de version du noyau en ajoutant la chaîne BoB13. Celle-ci est repérable avec la commande uname -v, ainsi qu'avec dmesg, qui permet aussi de trouver la variable d'environnement init. En outre, lorsque le bootkit est présent, le noyau est marqué comme contaminé, en plus de pouvoir charger tout module non signé.

Un module uploadé sur VirusTotal à peu près au même moment que BootKitty et avec le même identifiant de contributeur pourrait y être lié. Parmi les indices qui vont dans ce sens, une chaîne de caractères commune ("BlackCat", qui apparaît comme une référence à un des auteurs du malware, a priori sans rapport avec le ransomware du même nom).
Ce module est un dropper : il récupère un binaire ELF exécuté avec Bash. Lequel binaire attend le démarrage complet du système (signal : le lancement du gestionnaire d'affichage gdm3) pour charge un autre module...

Illustration générée par IA