Que se passe-t-il réellement au démarrage de l’ordinateur ? Entre la pression sur le bouton démarrer et l’interface utilisateur, l’ordinateur a dû démarrer l’ensemble de ses technologies. Pourtant, ce fonctionnement nous est complètement invisible. À chaque démarrage de l’ordinateur, il n’est pas demandé à l’utilisateur de reconfigurer chaque élément : Bus PCI, Processeur, Carte graphique… Tout cela est dû à l’élément central de l’ordinateur : la carte mère. C’est elle qui agit comme le chef d’orchestre du système et qui va initialiser, à sa manière, tous les périphériques.
par Solène SPRENGER, Pierre-François Maillard et Armand Ito
Etudiants en 4ème année à l’ESIEA
Figure 1 : comparaison des interfaces BIOS (gauche) et UEFI (droite).
Lorsque les premiers électrons atteignent la carte mère, elle doit immédiatement déterminer les différentes actions à entreprendre. Pour cela, la carte mère embarque un micrologiciel, aussi appelé firmware (voir Fig 2). C’est ce micrologiciel qui va prendre le contrôle de l’ordinateur et initialiser tous les composants. Après quoi, celui-ci donnera le contrôle au système d’exploitation, Linux, Windows ou Mac.
Figure 2 : illustration du déroulement lors d’un boot.
2) BIOS
Lorsque les premiers ordinateurs ont été créés, ce système d’initialisation se devait d’être le plus minimaliste possible. En effet, il ne devait pas prendre trop de temps à l’initialisation de l’ordinateur et il devait utiliser un minimum de mémoire. C’est pourquoi le BIOS (Basic Input Output Système) a été créé. Celui-ci est installé directement sur la carte mère par le constructeur. Il est possible de garder un certain contrôle de celui-ci via une interface de configuration. Néanmoins, si l’on peut modifier certains paramètres, on ne peut normalement pas modifier le code d’un BIOS.
En effet, ce dernier est bien souvent stocké sur une puce qui n’est pas modifiable (on parle de Read-Only Memory). Cependant il est possible depuis 1995 (avec l’arrivée du plug-and-play) de modifier le BIOS, ce qui valut la naissance de virus comme le CIH. Ainsi, les constructeurs de BIOS disposaient alors de deux possibilités pour répondre à cette problématique.
La première, utopique, visait à créer un BIOS capable de s’adapter à toutes les évolutions futures. La seconde, plus pragmatique, visait à figer le BIOS une fois pour toutes et assumer directement l’absence d’évolution. En ce sens, les conséquences sont doubles :
• Un manque de sécurité
Il est impossible de le modifier. Cela implique que si la moindre faille ou le moindre bug vient à être découvert, dès lors, l’ordinateur se trouve vulnérable sans aucune possibilité de correctif.
• L’incapacité d’évoluer
Le code est absolu et définitif. Si une technologie vient à évoluer, le BIOS ne peut pas systématiquement prendre en compte cette dernière. L’exemple typique réside dans les méthodes de partitionnement. En 1980, le MBR (Master Boot Record) est utilisé pour gérer un disque possédant plusieurs systèmes d’exploitation différents. Il répond à des problématiques liées à son époque : peu de systèmes d’exploitation disponibles et des disques avec une faible capacité… On parle d’un monde où il est possible de créer jusqu’à 4 partitions de boot avec une capacité maximale théorique de 2.2 To par disque. Cependant, fin des années 1990, les capacités de stockage augmentent, rendant le MBR obsolète. Pour anticiper l’obsolescence de ce standard, la GPT (GUID Partition Table) est mise en place pour corriger cette limitation technique. Toutefois, les anciens BIOS ne peuvent pas s’adapter. Aussi, cela oblige à l’achat d’une nouvelle carte mère permettant de passer au nouveau système de lecture.
3) EFI et UEFI
Les différents fabricants de micrologiciels se sont donc demandé comment répondre à ces problématiques. Les premières réponses proposaient de nouveaux styles de BIOS, mais ceux-ci ne permettaient pas de réponses concrètes, la conception primitive du système empêchait son évolution (voir Fig 3).
Figure 3 : Slide de UEFI Forum montrant la transition entre l’époque du BIOS et celui de l’UEFI.
Mais en 1998 Intel sort un projet qui va révolutionner le monde des micrologiciels. Il s’agit de l’EFI (Extensible Firmware Interface). Celui-ci apporte un important changement de philosophie : l’EFI n’a pas pour objectif d’installer un simple micrologiciel, mais celui d’installer un véritable système d’exploitation. Il met en place ses propres pilotes et il permet le lancement d’applications. Avec l’évolution des méthodes de stockage, il devient dès lors possible de l’éditer, et même de le mettre à jour via des capsules de mise à jour. Cependant, le changement majeur de cette évolution réside dans sa conception : le BIOS était généralement développé en assembleur, laissant sa création et ses évolutions à une poignée d’experts sur la planète. L’EFI, quant à lui, est développé en C.
Cela rend la création du micrologiciel accessible à un bien plus large public. C’est cette capacité d’évolution qui a permis à l’EFI, de, petit à petit, s’imposer face à son prédécesseur trop limité. En 2004, un consortium des principaux acteurs du développement de micrologiciel eut lieu. Celui-ci composé notamment de Apple, Microsoft, Intel, AMD et IBM, a eu pour but de généraliser le développement de l’EFI. Ce conglomérat aboutira à la création de l’UEFI (Unified Extensible Firmware Interface), une nouvelle norme se basant en sa quasi-intégralité sur l’EFI, permettant d’uniformiser le développement du micrologiciel et de mettre fin au BIOS.
Il n’existe pas d’UEFI unique, chaque constructeur a la possibilité de fabriquer le sien avec l’ajout de ses spécificités. C’est pour cela qu’il est possible de trouver des UEFI avec des styles graphiques très différents. Ils sont cependant fondamentalement issus de la même norme. Le monde de l’Open Source s’est lui aussi approprié la norme UEFI. Ainsi la communauté Tianocore a mis en place son kit de développement nommé EDK2, celui-ci sert de référence. Intel, et Microsoft plus récemment ont même tous les deux créé des projets stables autour du projet EDK2 avec leurs propres identités. Il s’agit du projet UDK (Intel) et µ (Microsoft).
4) UEFI et le Secureboot
L’UEFI est composé de plusieurs éléments de sécurité fondamentaux. L’un d’entre est particulièrement connu : le « Secure Boot » (voir Fig 4). Celui-ci permet un contrôle de l’intégrité du noyau à l’aide d’une table de signatures stockée dans l’UEFI. Lors du lancement du système d’exploitation, l’UEFI vérifie si celui-ci correspond bien à une signature déjà préenregistrée, sans quoi il ne sera pas lancé. Cette fonctionnalité a amené une vive polémique lors de son lancement rendant le démarrage de certains Linux impossible sur une partie des UEFI. L’option est devenue désactivable permettant à tout système d’exploitation de se lancer, néanmoins sans cette sécurité.
Figure 4 : Slide de chez Intel montrant un chainage complet du Secure Boot.
5) UEFI et le Hardware
La sécurité d’un système peut être apportée par le Secure Boot ou les puces Trusted Computing Module (TPM). On peut notamment citer quelques constructeurs de TPM comme Atmel, Broadcom, Intel, Nuvoton (anciennement Winbond) ou STMicroelectronics. Malgré cela, un élément fondamental de l’intégrité de l’UEFI est souvent oublié : les mémoires de type ROM n’ont de « Read Only » que le nom. En effet, de nos jours la plupart des ROM dans nos PC sont reprogrammables, le cas des ROM tel que des Mask ROM ou encore des Programmable ROM qui ne peuvent être programmées qu’une seule fois se font rares. Dans le cas des ROM utilisées pour le BIOS et l’UEFI les constructeurs de cartes mères préfèrent utiliser des SPI flash (le plus souvent ce sont des EEPROM), car elles sont plus malléables et leur permettent de faire des mises à jour de leur firmware depuis l’ordinateur.
Dans le cas des EEPROM il est parfaitement possible de la reprogrammer directement sur la carte mère avec des programmeurs de composants conçus à cet effet (ce genre d’attaque se prénomme Evil Maid). Bien entendu, il est nécessaire d’avoir un accès physique à la machine, de l’ouvrir et de mettre en place le nouvel UEFI. En dépit de ces difficultés, ce genre d’attaque est tout à fait possible. Il n’est pas rare que certains ordinateurs soient sans surveillance pendant une période donnée. Même si ouvrir, extraire puis reprogrammer une EEPROM peut sembler long et compliqué, le temps nécessaire à son exécution peut être, en réalité, de 5 minutes dans les cas les plus simples comme vus à la Def Con 26 (UEFI Exploitation for the Masses).
Heureusement pour nous certain PC comme le Lenovo E560 sont bien plus dur à désassembler (voir Fig 5 et 6), dans des conditions de Laboratoire et avec un équipement classique (de simples tournevis électroniques et une carte plastique) le temps de désassemblage et réassemblage est de 30 minutes. À partir de ce moment, il serait innocent de penser que cela s’arrête ici. En effet, n’oublions pas l’Intel Direct Connect Interface (DCI). Sans rentrer dans les détails il est possible grâce, ou à cause, d’Intel d’accéder à l’EEPROM via la DCI, depuis une clé USB 3.0. Heureusement pour nous le Secure Boot de l’UEFI et l’Intel Boot Guard sont supposés, depuis 2013, combler cette lacune… Mais comme toujours un paramètre non négligeable rentre dans l’équation donnant lieu aux failles et bugs, l’Humain. Entre les problèmes d’implémentation, voire l’absence de l’utilisation de l’Intel Boot Guard, nos très chers hackers ont un bel avenir devant eux .
Figure 5 : Photo avant le démontage du PC.
Figure 6 : Photo illustrant un remplacement de BIOS.
6) UEFI et les attaques Sofware
Toutefois, si ces attaques sont possibles au niveau matériel, elles sont tout autant possibles au niveau logiciel. Les attaques sur les BIOS et UEFI ne sont pas nouvelles. En effet, ceux-ci sont le point névralgique du système, et chaque ordinateur moderne en est équipé. Cela signifie que si une faille vient à être trouvée, elle devient dès lors, non seulement commune à tout système, mais aussi la cause de graves conséquences : l’UEFI se situant au-dessus de tout système d’exploitation, on parle parfois de Ring -2.
Les malwares UEFI sont, jusqu’à récemment, restés très théoriques. Il ne faut pas imaginer l’UEFI comme un système avec une sécurité faible. Les différents constructeurs de cartes mères ont bien compris que ce micrologiciel est un élément déterminant de la sécurité de leur système. C’est pourquoi les malwares UEFI nécessitaient généralement trop de prérequis pour être applicables à grande échelle.
Figure 7 : Frise historique des rootkit sur BIOS, présentation de Alex Matrosov.
Pourtant cette manière de voir les choses a récemment drastiquement changé. Le logiciel Lojack est un logiciel d’antivol avec une option de persistance. Cela signifie qu’il survit à la réinstallation d’un système d’exploitation. Pour cela, il possède un module UEFI lui permettant une survivabilité à toute épreuve. En Mai 2018, une infection sur celui-ci est décrite dans le Blog d’Arbor Network, compromettant la totalité des systèmes qu’il équipe. Une partie de l’infection à lieu au sein du micrologiciel. Le premier véritable malware UEFI est né. Son nom est Lojack.
L’infection avait pour objectif de mettre une backdoor, qui était exploitable si le « Secure Boot » n’était pas mis en place.
Depuis les recherches autour de l’UEFI ont explosé. Les conférences autour de celui-ci se sont multipliées. En 2018, la conférence phare de la Black Hat le concernait. On retrouve même certains documents de la NSA disponibles, dans les fuites de Snowden, sur le site WikiLeaks montrant la présence et l’exploitation de certaines failles. On peut notamment citer le Hook de la fonction ExitBootService permettant de mentir sur la mémoire RAM du système d’exploitation.
7) Conclusion
Mais quelles sont les réponses à ces attaques ? Bien qu’existantes, elles se retrouvent très vite limitées. L’antivirus ne peut rien effectuer sur le micrologiciel car celui-ci est antérieur à son lancement. Le Secure Boot offre une protection intéressante, cependant cela n’exclue pas tous les types attaques. Les quelques utilitaires de sécurité permettant une analyse de l’UEFI sont très vite limités par les spécificités des constructeurs apportées à la norme. La meilleure défense réside finalement dans la protection physique de son ordinateur. Cependant, le problème de détection de malware comme Lojax reste toujours présent. Les véritables réponses à tous les types d’attaques UEFI restent encore à être apportées.
Figure 8 : Photo d’un système de rançonnage sur UEFI.