Pourquoi Secure Boot est une passoire depuis 13 ans sans que personne ne s'en rende compte ?

UNE FAILLE DE SÉCURITÉ GÉANTE DÉCOUVERTE DANS SECURE BOOT

Un standard de sécurité inventé par Microsoft pour protéger les ordinateurs Windows et Linux des infections au niveau du firmware (le logiciel intégré dans la carte mère) a été contournable en quelques minutes pendant treize ans. La découverte a été faite par des chercheurs de l'entreprise de cybersécurité ESET, qui ont identifié onze images de firmware défectueuses, dont une datant de 2013, pourtant toujours signées par Microsoft malgré leurs vulnérabilités.

Ces images, appelées shims, ont été créées pour étendre la protection Secure Boot aux appareils Linux et aux logiciels utilitaires. Avec une technique si simple qu'un débutant en piratage peut l'utiliser, ces shims oubliés permettent de bypasser complètement la sécurité intégrée dans l'UEFI (l'interface qui gère le démarrage de l'ordinateur).

COMMENT LES HACKERS PEUVENT PIÉGER VOTRE ORDINATEUR SANS VOUS LE FAIRE SAVOIR

La faille vient d'un oubli de Microsoft : l'entreprise n'a pas révoqué ces shims une fois leurs failles découvertes. Résultat, un pirate peut installer un shim vulnérable sur un PC Windows ou Linux, puis utiliser ce shim pour contourner la chaîne de signature numérique obligatoire. Une fois cette étape franchie, il peut installer un firmware malveillant qui se charge au démarrage de l'ordinateur, avant même que le système d'exploitation ne prenne le relais.

Le pire ? Ce firmware malveillant reste actif même après une réinstallation complète de Windows ou un changement de disque dur. Autrement dit, même si vous formatez votre PC, le pirate peut garder un accès permanent à votre machine.

SECURE BOOT : UNE PROTECTION QUI NE PROTÈGE PLUS RIEN DEPUIS 2012

Secure Boot a été lancé en 2012 pour empêcher les bootkits, des programmes malveillants qui s'installent au niveau du firmware. Sans Secure Boot, un pirate avec un accès physique même bref à votre ordinateur peut y installer un bootkit, comme ceux utilisés par des groupes de hackers soutenus par des États : LoJax (Russie, 2018), MosaicRegressor (2020), CosmicStrand (2022) ou encore BlackLotus (2023). D'autres bootkits connus portent les noms d'ESpecter, FinSpy ou MoonBounce.

La plupart de ces bootkits nécessitent un accès physique à la machine, ce qui est précisément le type de menace contre lequel Secure Boot a été conçu pour protéger.

LES SHIMS : DES OUTILS OUBLIÉS QUI OUVRENT GRANDE LA PORTE AUX PIRATES

Une liste de ces onze shims, compilée par le CERT, révèle que certains étaient utilisés par des distributeurs Linux comme RedHat, OpenSuse ou Oracle. D'autres faisaient partie de logiciels tiers, comme le Matriculation Examination Board de PC-Doctor Finland. Beaucoup de ces shims ont été créés avant l'existence de protections comme SBAT ou les listes d'interdiction MOK.

D'autres contiennent des bugs accumulés dans leur code ou dans les binaires secondaires qu'ils autorisent. Microsoft, qui supervise la signature des shims, a oublié de les révoquer une fois leurs vulnérabilités découvertes. Dans certains cas, cette omission a duré plus de dix ans.

COMMENT FONCTIONNE LA CONFIANCE DANS SECURE BOOT ?

Sur Windows, le chargeur de démarrage signé numériquement par Microsoft est le seul élément de confiance absolu. Pour qu'un composant se charge au démarrage, son certificat doit être explicitement signé par Microsoft. Les shims fonctionnent différemment : ce sont des ancres de confiance secondaires, signées par Microsoft avec l'un de ses certificats UEFI.

Une fois le shim installé, un certificat intégré dans le shim, appartenant au fabricant de la carte mère ou du logiciel, autorise tous les logiciels chargés ensuite. Quand une faille est découverte dans un shim, Microsoft le révoque normalement. Mais pour ces onze shims, l'entreprise a omis de le faire.

LA COMPLEXITÉ DE SECURE BOOT : UNE PORTE D'ENTRÉE POUR LES FAILLES

Microsoft n'a toujours pas expliqué comment ou pourquoi cette erreur a pu se produire. Une cause possible ? La complexité extrême du fonctionnement de Secure Boot. À la fois le Windows Boot Manager et les shims UEFI chargent deux bases de données : la base db, qui liste tous les certificats de signature autorisés, et la base dbx, qui contient les certificats et hachages plus fiables.

Pour qu'un composant soit chargé, il doit être autorisé par la base db et non révoqué dans la base dbx.

Étant donné le nombre élevé de composants Linux exécutés au démarrage, il est impossible de lister chacun d'eux dans ces bases, car la base dbx n'a qu'une capacité de 32 ko. Microsoft a donc recours à d'autres méthodes de révocation : SBAT (Secure Boot Advanced Targeting) et le SVN (Secure Boot Security Version Number).

Chaque composant dans le chargeur UEFI contient des métadonnées signées par le même certificat qui authentifie le binaire. Ces métadonnées indiquent le nom du composant et lui attribuent un numéro de génération incrémenté à chaque nouveau correctif de sécurité.

SBAT ET SVN : DES MÉCANISMES QUI NE FONCTIONNENT PAS ASSEZ BIEN

Une variable dans l'UEFI stocke le numéro de génération minimal acceptable pour chaque composant. Cette variable est appliquée par le shim, et non par le firmware. Le shim intègre également la politique, ce qui permet d'intégrer de nouvelles règles via un mécanisme appelé SbatLevel.

« À chaque démarrage, le shim vérifie d'abord ses propres métadonnées SBAT contre la politique, ce qui permet à un shim obsolète de se rejeter lui-même, puis applique le même test à chaque binaire qu'il charge, refusant tout ce dont le numéro de génération est inférieur au minimum exigé par la politique », explique le chercheur de l'ESET.

La complexité ne s'arrête pas là. Les shims intègrent à la fois un certificat de shim géré par le vendeur et un certificat de shim intégré, qui autorisent tous les chargeurs de démarrage et utilitaires chargés ensuite.

UNE CERTIFICATION EXPIRÉE QUI NE SUFFIT PAS À RÉVOQUER LES SHIMS VULNÉRABLES

Même l'expiration du certificat Microsoft qui a signé les shims, survenue fin mai, ne suffit pas à révoquer ceux identifiés par ESET. Ces shims autorisent des composants secondaires connus pour être vulnérables à diverses exploits. Par exemple, le shim d'Oracle signe un binaire vulnérable à la CVE-2015-5381, une faille dont l'exploitation ne nécessite pas de compétences avancées.

D'autres shims vulnérables ne supportent pas des protections comme l'application de la liste d'interdiction MOK ou l'application de SBAT, toutes deux mises en place après la sortie des shims concernés. Certains shims identifiés contiennent même des vulnérabilités dans leur propre code.

WINDOWS ET LINUX : DEUX SYSTÈMES TOUCHÉS PAR LA MÊME FAILLE

Cette faille touche aussi bien les utilisateurs de Windows que ceux de Linux, même si les PC Windows 11 en configuration Secured-core par défaut ne sont probablement pas concernés. Tout utilisateur Windows ayant installé les mises à jour de juin n'est plus vulnérable. Les utilisateurs Linux doivent vérifier le Linux Vendor Firmware Service ou consulter leur distributeur. Les statuts de révocation sont disponibles via le script uefi-dbx-audit.

UNE FAILLE QUI REMET EN CAUSE LE MODÈLE MÊME DE SECURE BOOT

La possibilité pour des pirates d'avoir pu contourner Secure Boot pendant plus de dix ans grâce à des scripts aussi simples qu'un « hack par copier-coller » ne plaide pas en faveur du modèle proposé par Microsoft et les fabricants de matériel. Comme mentionné précédemment, la complexité extrême de Secure Boot est l'un des principaux facteurs de cette faille.

« C'est une solide réfutation de tout le modèle Secure Boot », déclare HD Moore, expert en sécurité firmware, PDG et fondateur de runZero, et critique de longue date de Secure Boot. Ses griefs incluent le fait que Microsoft soit la racine de confiance de facto pour toute la plateforme UEFI, l'incapacité de la protection à évoluer suffisamment, et la possibilité pour des composants de démarrer même après l'expiration des certificats de niveau supérieur.

« L'ensemble de l'écosystème est quelque peu brisé et a besoin d'un redémarrage », ajoute-t-il.

CE QUE VOUS DEVEZ FAIRE MAINTENANT POUR VOUS PROTÉGER

Si vous utilisez un PC Windows, installez les mises à jour de sécurité de juin 2024. Si vous êtes sous Linux, consultez le service de firmware du fournisseur de votre distribution ou utilisez le script uefi-dbx-audit pour vérifier si votre système est vulnérable. Les shims concernés ont enfin été révoqués par Microsoft, mais il est crucial d'agir rapidement pour éviter toute exploitation.