Retour sur l’ECW 2024 à Rennes

Les attaques sur la chaîne de boot et les firmwares UEFI représentent plus de 20% des vulnérabilités exploitées au cours des 20 dernières années selon l’agence gouvernementale américaine CISA. Et ce chiffre est en nette progression. Cependant, des solutions existent pour se protéger de la plupart de ces attaques. Bien que souvent configurées de façon adéquate par défaut, il est important de comprendre leur fonctionnement pour analyser les menaces qui pèsent sur l’écosystème UEFI.

L’ECW 2024 Rennes : le salon cyber de Rennes

L’European Cyber Week (ECW) est un salon orienté autour des sujets cybers qui s’est tenu à Rennes du 18 au 21 novembre 2024. Organisé à l’initiative de la DGA (Direction Générale de l’Armement), il réunit les acteurs français de la sécurité informatique, de la startup au groupe international, en passant par les organismes de formation. Le salon propose des conférences, des ateliers, des formations et des rencontres professionnelles.

Les conférences couvrent des sujets variés, d’innovation et d’actualité. Ce sont autant des sujets techniques (extraction de secrets dans du matériel cryptographique, génération d’aléa sécurisé, etc.) que sociétaux (retour sur l’organisation des Jeux Olympiques, panorama de la menace cyber en 2024, etc.). Sur l’ensemble des conférences auxquelles j’ai pu assister, les 2 défis qui se profilent sont très clairement l’émergence massive de l’IA et l’adoption d’algorithmes de cryptographie post-quantique..

Grâce à Néosoft, j’ai pu assister à la conférence C&SAR by DGA. C’est l’événement principal de l’ECW. Il s’étend sur deux jours et fait venir des intervenants gouvernementaux, industriels et universitaires. Cet article propose un retour et un approfondissement sur la présentation d’ouverture : « Implants, bootkits et protection de démarrage ». Ce sujet était présenté par Sébastien BRILLET, expert cybersécurité pour la DGA. Celui-ci a donné un ton très technique dès le début de la conférence en insistant sur cet aspect critique de la sécurisation du démarrage des ordinateurs.

En effet, les logiciels bas-niveaux qui démarrent avant le système d’exploitation sont responsables de l’intégrité de tous les processus démarrés par la suite. Ils sont donc extrêmement critiques et souvent ciblés par des attaques. Ces composants nécessitent une attention particulière et une bonne compréhension. Cette problématique est d’ailleurs actualisée par la découverte récente (novembre 2024) de Bootkitty, le premier bootkit conçu pour Linux. Présentation en fin d’article.

Alors maintenant, c’est parti pour parler UEFI et Secure Boot !

Qu’est ce que l’UEFI ?

Pour être précis, l’UEFI (Unified Extension Firmware Interface) est un consortium qui édite depuis 2005 un standard nommé lui-aussi UEFI. Ce dernier définit l’interface entre le firmware et le système d’exploitation. Pour la suite de l’article, l’acronyme UEFI désignera ce standard.

L’UEFI remplace le BIOS (Basic Input Output System). Ce standard historique manquait certaines fonctionnalités. Depuis 2020, l’utilisation du BIOS est officiellement dépréciée au profit de l’UEFI.

Ainsi pour pouvoir démarrer correctement un OS doit respecter ce standard :

Le processus de démarrage est assez simple dans les grandes lignes :

• Après l’alimentation électrique de l’ordinateur, des vérifications d’intégrité sont lancées pour vérifier que les composants n’ont pas été modifiés (étape SEC). Ceux-ci sont ensuite initialisés (étape PEI).
• Le firmware UEFI est alors chargé depuis une mémoire auxiliaire flash (étape DXE). Il est responsable de démarrer un programme précis installé sur le disque de démarrage. Ce programme est installé dans la première partition du disque, appelée ESP (EFI System Partition). Sous Windows, le programme à démarrer est Bootmgfw.efi. Sous Linux il s’appelle shimx64.efi ou grubx64.efi (la différence est détaillée dans les chapitres suivants, avec l’introduction du Secure Boot).
• Ce programme chargé depuis l’ESP, se charge à son tour d’initialiser le noyau de l’OS installé sur les autres partitions des disques (étape BDS).
• Le noyau de l’OS, une fois démarré, peut lancer les différents processus du « Run Time » (étape RT).

Ce schéma est bien évidemment simplifié. De nombreuses autres vérifications et sous-routines sont lancées lors de la phase de « Boot Device Selection ».

Attaques possibles à toutes les étapes

Comme dans tout système et tout processus, chacune des étapes décrites ci-dessus est susceptible d’être attaquée. Par essence, ces étapes sont critiques : si l’une d’entre elles est compromise, un attaquant peut modifier le comportement de l’OS en entier, voir démarrer un tout autre OS.

Ces attaques sont souvent très difficiles à détecter depuis l’OS. En effet, après altération du système d’exploitation, un attaquant est en mesure de déjouer toute tentative de vérification d’intégrité faite par celui-ci. De plus, ces attaques sont parmi les plus persistantes car elles sont implantées au plus bas niveau et agissent avant le démarrage de l’OS.

On distingue 2 catégories d’attaques :

• Les rootkits ou implants UEFI sont les attaques qui modifient le firmware UEFI. Ils sont très difficilement réalisables en pratique car ils nécessitent un accès à la mémoire flash où est installé le firmware UEFI. En revanche, ces attaques se révèlent extrêmement discrètes et particulièrement persistantes. Par exemple, même une réinstallation complète du système d’exploitation ne permet pas de les éliminer.
• Les bootkits sont les attaques qui visent plutôt l’étape suivante : la partition ESP et la modification des programmes qui démarrent l’OS. Ces programmes sont facilement modifiables car ils résident sur un disque dur accessible depuis tout système d’exploitation. À la différence des rootkits, les bootkits ne persistent pas après la réinstallation d’un OS (si la partition ESP est réécrite).

Des attaques sur les autres phases de la chaîne de boot sont aussi réalisables mais nous ne les détaillerons pas dans cet article. Elles relèvent plutôt de la sécurité physique et matérielle (phases précédentes) ou de la sécurité système et OS (phases suivantes).

Quelques exemples d’attaques connues ces dernières années :

• LoJaX (2018) (Rootkit)
• EsPecter (2021) (Bootkit)
• FinSpy (2021) (Bootkit)
• CosmicStand (2022) (Rootkit)
• BlackLotus (2022) (Bootkit)

Secure Boot : une protection contre les attaques par supply chain

Afin de contrer ces attaques (rootkits et bootkits), l’UEFI a introduit le Secure Boot. L’objectif est de vérifier, à toutes les étapes du démarrage, la signature de chaque programme avant de les lancer. Cela permet de s’assurer de l’intégrité et de l’authenticité de toute la chaîne d’initialisation de l’OS. Par extension cela permet de s’assurer que l’OS démarré par l’utilisateur n’a pas été modifié (intentionnellement ou non).

À noter que des mesures complémentaires au Secure Boot peuvent être mises en place pour garantir l’intégrité des processus systèmes qui sont exécutés. Par exemple, sous Windows on retrouve System Guard.

Le Secure Boot repose sur l’utilisation de signatures cryptographiques et sur une liste des certificats pouvant signer les programmes exécutés lors des phases de boot UEFI.

Les ordinateurs intègrent tous un système analogue à une Infrastructure de Gestion de Clés (IGC) pour gérer cette liste de certificats :

• L’équivalent de l’autorité racine est la Plateform Key (PK). C’est un certificat du constructeur, écrit en dur sur les composants de la carte mère.
• L’équivalent des autorités intermédiaires sont les Key Exchange Keys (KEK). Elles peuvent être renouvelées régulièrement sans avoir à modifier la PK.
• L’équivalent des certificats finaux sont enregistrés dans la DB. Ce sont ces certificats qui signent les programmes exécutés lors du Secure Boot.
• L’équivalent de la liste de révocation de certificat est la DBX. Ce sont des certificats compromis qui ne doivent plus être utilisés pour signer des programmes.

Cependant, à la différence d’une IGC, la PK n’est pas utilisée pour signer les certificats KEK et les KEK ne sont pas utilisés pour signer les certificats dans la DB. La PK et les KEK sont utilisés pour signer les programmes qui ont le droit de modifier ces certificats. C’est-à-dire :

• Seul un programme signé par une KEK peut modifier les certificats présents dans la DB et la DBX.
• Seul un programme signé par la PK (donc le constructeur) peut modifier un certificat KEK.
• La PK peut, elle aussi, être renouvelée par un programme signé par la PK elle-même, mais ce cas de figure est rare en pratique.

Le Secure Boot dans un contexte multi-acteurs (Linux)

Ce système hiérarchique de confiance fonctionne parfaitement tant qu’il y a un nombre d’acteurs de confiance limités (Microsoft, les distributions majeures Linux et les quelques constructeurs du marché). Cependant il est difficile à adapter pour des usages où chacun peut modifier son OS et veut pouvoir le signer de façon à être compatible Secure Boot. C’est pour cette raison que dans le cas de Linux, il existe une autre source de certificats : Machine Owner Keys (MOK). Il s’agit d’une liste de certificats autorisés pour le Secure Boot mais qui ne sont pas nécessairement validés par une « autorité centrale ».

En effet, la philosophie de Linux et de l’Open Source en général repose sur le principe que n’importe qui peut créer, modifier et installer son système d’exploitation (ou même une chaîne de boot personnalisée), sans avoir à obtenir l’accord d’un constructeur. Il est possible d’ajouter un certificat dans la MOK, pour le déclarer « de confiance ». À noter qu’il est possible d’utiliser l’utilitaire mokutil sous Linux.

Cette fonctionnalité introduit bien évidemment des risques de contournement du Secure Boot. Afin de mitiger ces risques, un utilisateur physique est forcé de renseigner un mot de passe lors du démarrage de l’ordinateur pour confirmer que l’ajout d’un certificat de la MOK est volontaire. Il est donc à la charge de l’utilisateur de faire attention à ces certificats.

Autre différence par rapport à Windows : il est à noter que le firmware UEFI est généralement fourni par le constructeur et est indépendant de l’OS. Alors comment savoir s’il faut charger les certificats de la MOK ? Réponse : on utilise une couche d’abstraction (shimx64.efi) qui est signée par Microsoft et qui est capable de valider les programmes signés soit par des certificats dans la MOK, soit par les certificats des distributions majeures Linux (Ubuntu, Debian, RHEL, etc.).

De cette manière, le firmware UEFI lance dans tous les cas un programme signé par le certificat « Microsoft Production », qui est présent dans la DB. Et dans le cas de Linux, le « maillon » suivant de la chaîne de démarrage (grubx64.efi) peut être personnalisé tout en conservant les garanties d’intégrité et d’authenticité du Secure Boot.

Bootkitty : le premier bookit visant Linux

Le 27 novembre 2024, ESET a publié les résultats de l’analyse d’un nouveau bootkit . Originellement publié sur VirusTotal, Bootkitty est le premier bootkit connu qui vise les systèmes Linux. Tout d’abord d’origine inconnue, il s’agit en fait d’un projet étudiant coréen visant à faire prendre conscience des risques et des menaces. S’agissant d’une preuve de concept, le programme est bénin et se contente d’afficher des messages lors du démarrage de l’OS. Il n’y a pour l’instant aucune utilisation mal intentionnée connue de ce bootkit.

Ce programme est un bootkit, ce qui signifie qu’il modifie les fichiers de la partition ESP. Son installation est relativement simple : un accès administrateur au système d’exploitation suffit.

Toutefois, il ne peut pas survivre à une réinstallation de la partition ESP.

Le fonctionnement de ce bootkit vise à être invisible pour l’utilisateur :

• Depuis un OS Linux déjà installé, le fichier préexistant GRUB est renommé en grubx64-real.efi et un nouveau fichier grubx64.efi qui contient l’attaque active est créé.
• Lors du redémarrage suivant, l’installation d’un certificat dans la MOK doit être validée par l’utilisateur. Il s’agit du certificat auto-signé qui a servi à signer le nouveau fichier grubx64.efi.
• Après l’installation du certificat, le processus de démarrage suit un déroulement classique : le firmware UEFI exécute shimx64.efi, signé par Microsoft (étape 2 sur le schéma). Celui-ci lance ensuite grubx64.efi, signé par un certificat en MOK (étape 4). L’attaque est alors activée.
• Ce programme malveillant va modifier légèrement le vrai GRUB et l’exécuter comme lors d’un démarrage classique (étape 5). Les modifications ajoutées vont permettre de modifier le comportement du noyau Linux pour exécuter du code supplémentaire au démarrage de l’OS (étapes 6 à 10).

Dans cette attaque, 2 points sont à retenir :

• L’exécution du bootkit est transparente pour l’utilisateur. L’installation ne nécessite que des droits administrateurs. Les seuls signes de compromission sont la validation d’un certificat en MOK, l’apparition du fichier grubx64-real.efi (qui, dans un cas réel, serait plus obfusqué) et le fait que l’OS est marqué « teinté » (potentiellement corrigeable dans un cas réel).
• Le Secure Boot n’est pas vraiment contourné puisque les programmes exécutés sont tous signés et autorisés. Mais le système est abusé dans le cas particulier de Linux afin d’autoriser un programme malveillant. Il reste donc difficilement exécutable pour un administrateur qui comprend les notions de Secure Boot.

Sources et pour aller plus loin…

1. Slides de la conférence C&SAR 
2. Enregistrement audio de la conférence C&SAR
3. Spécifications des standards UEFI
4. Liste de malwares attaquants UEFI
5. Analyse de Bootkitty par ESET 
6. Analyse de Bootkitty sur VirusTotal