Récemment, Microsoft a finalement corrigé la vulnérabilité de contournement du démarrage sécurisé (Secure Boot) qui se cachait dans le système depuis 2013. Les chercheurs en sécurité ont souligné que le principal problème exposé par cet incident n'était pas la vulnérabilité elle-même, mais les anciens composants dotés de signatures numériques mais le manque de gestion efficace du suivi.

Cette vulnérabilité de sécurité de longue date découle d’un simple oubli administratif : les composants obsolètes n’ont jamais été officiellement révoqués. Des chercheurs du célèbre fournisseur de sécurité ESET ont découvert qu'un ensemble de chargeurs de démarrage UEFI « shim » vulnérables, certains remontant à 2013, sont toujours considérés comme des composants fiables par les systèmes Microsoft des années après que les vulnérabilités ont été exposées. Cela signifie que les attaquants peuvent facilement contourner le mécanisme de démarrage sécurisé sur les appareils Windows et Linux. Il est rapporté que le problème implique un total de 11 fichiers binaires shim, qui contiennent toujours des signatures valides et sont acceptés par les systèmes effectuant un démarrage sécurisé. Étant donné que la signature est l'identifiant clé qui permet au code de s'exécuter pendant le processus de démarrage, une fois le composant de confiance compromis, toutes les étapes de démarrage suivantes seront affectées.

Martin Smolár, chercheur d'ESET, a souligné : « Le danger de ces anciennes versions de shims n'est pas qu'elles utilisent de nouvelles vulnérabilités, mais qu'aucune nouvelle vulnérabilité n'est nécessaire pour contourner le démarrage sécurisé UEFI. Les attaquants n'ont pas besoin d'exploits sophistiqués, tant qu'ils disposent d'une copie ancienne mais toujours fiable et non révoquée du binaire shim, et qu'ils ont des connaissances de base sur le fonctionnement du shim UEFI, il suffit de contourner cette ligne de sécurité vitale. Dans des scénarios d'attaque réels, les pirates peuvent utiliser ces cales pour charger un micrologiciel malveillant avant le démarrage du système d'exploitation. Ce type de malware est extrêmement caché et tenace, et il est difficile de le supprimer complètement même si vous réinstallez le système d'exploitation ou même si vous remplacez des périphériques matériels tels que des disques durs.

Le mécanisme de démarrage sécurisé a été introduit pour la première fois en 2012 et son intention initiale était d'empêcher de telles attaques de bas niveau. Ce mécanisme nécessite que chaque morceau de code de la chaîne de lancement soit signé numériquement par une autorité de confiance. Microsoft sert de racine de confiance dans le système et est responsable de la signature de son propre chargeur de démarrage et des cales utilisées par d'autres logiciels tels que Linux. En fait, shim est un compromis qui permet aux logiciels non-Microsoft de s'exécuter normalement dans un environnement de démarrage sécurisé. Une fois que Microsoft fournit une signature pour un shim, le shim peut utiliser son certificat intégré pour approuver les composants suivants.

Cependant, le principe pour que ce mécanisme fonctionne efficacement est qu'une fois qu'une cale présente une vulnérabilité, elle doit être immédiatement révoquée. Mais dans cet incident, ce mécanisme de blocage a complètement échoué. Les cales concernées proviennent d'un large éventail de sources, couvrant des distributeurs Linux tels que Red Hat, openSUSE et Oracle, ainsi que certains outils tiers. Certains de ces composants existaient avant l'avènement de nouveaux mécanismes de protection tels que les listes de refus SBAT et MOK ; d’autres contenaient eux-mêmes des failles de code ou permettaient le chargement de composants présentant des vulnérabilités connues. ESET a spécifiquement souligné une cale Oracle qui permet d'exécuter des binaires avec la vulnérabilité CVE-2015-5381, et le seuil technique pour exploiter la vulnérabilité est assez bas.

Une autre partie du problème réside dans la complexité croissante des mécanismes de démarrage sécurisé. Le système s'appuie actuellement sur plusieurs couches pour déterminer quel code peut s'exécuter, notamment une base de données de signatures de confiance, des listes de révocation et de nouveaux mécanismes basés sur les versions tels que SBAT. Chaque lien nécessite des mises à jour et une maintenance précises. Comme l'explique Smolár, dbx est responsable de la révocation de fichiers binaires spécifiques, tandis que SBAT et Secure Boot SVN de Microsoft sont responsables de la révocation de versions spécifiques. Chaque composant de démarrage contient des métadonnées avec un numéro de version et le système est censé intercepter tout composant tombant en dessous d'un seuil défini. Mais cela dépend entièrement de la mise à jour en temps opportun des données de seuil. Il convient de noter que même si le certificat Microsoft utilisé pour signer ces shims expire, cela n'empêche pas automatiquement leur exécution, ce qui expose pleinement la dépendance de l'ensemble du système à la révocation active plutôt qu'aux mécanismes d'échec d'expiration intégrés.

Actuellement, les systèmes Windows ayant installé les dernières mises à jour ne sont plus menacés par cette vulnérabilité ; pour les utilisateurs de Linux, les experts recommandent de vérifier auprès du responsable de la distribution correspondant ou d'utiliser des outils tels que fwupd pour confirmer si le système a été protégé.

Cependant, ce qui suscite des inquiétudes plus profondes dans l’industrie, c’est la fragilité de ce système de confiance. La gestion des relations de confiance entre de nombreux composants, fournisseurs et mises à jour fréquentes s'est avérée être une tâche extrêmement difficile. HD Moore, PDG et fondateur de runZero, a déclaré sans détour dans une interview : « Il s'agit d'une critique sévère de l'ensemble du modèle de démarrage sécurisé. » Il a souligné qu'il existe trop de composants signés qui ne disposent pas d'un suivi efficace et peuvent encore être utilisés à des fins involontaires et dangereuses. Moore a conclu : « Le résultat final est qu'il existe un grand nombre de composants signés (connus de personne sauf de Microsoft) qui peuvent contourner le démarrage sécurisé - dont certains sont utilisés pour démarrer d'autres programmes, et ils comportent également des failles de sécurité générales et d'autres bugs, ce qui signifie qu'ils peuvent être utilisés pour démarrer presque n'importe quoi. L'écosystème entier est cassé dans une certaine mesure et nécessite un redémarrage complet.