Obsolescence programmée signé Intel pouvant favoriser le monopole de Microsoft faisant rappeler le foutoir avec Windows 8 en 2012 ! En effet, Intel supprimera la prise en charge du BIOS hérité de l'UEFI à partir de 2020. Le bon vieux BIOS a atteint la quarantaine, et il s'avère que c'est à ce moment qu'il va mourir sur les plates-formes Intel 64 bits. Ces dernières années, Intel a mis en œuvre son mécanisme UEFI (Unified Extensible Firmware Interface) avec une prise en charge du BIOS hérité comme option supplémentaire (le mode Legacy), mais la société a l'intention de supprimer la prise en charge du BIOS hérité de son UEFI d'ici 2020 afin d'améliorer la sécurité. Pour la plupart des utilisateurs, la suppression passera inaperçue, mais pour ceux qui utilisent et s'appuient sur du matériel hérité sur les plates-formes les plus récentes, cela signifie migrer vers d'autres plates-formes.
Afin de garantir une transition en douceur du BIOS vers l'UEFI (en garantissant la compatibilité avec les logiciels et le matériel hérités qui utilisent OpROM 16 bits), le Forum Unified EFI (qui comprend pratiquement tous les principaux développeurs et fournisseurs de matériel) a défini plusieurs systèmes UEFI et introduit un module de prise en charge de compatibilité (CSM) en option pour la classe 2 de l'UEFI pour faciliter le processus.
La grande majorité des PC disposent aujourd'hui de la classe 2 de l'UEFI et peuvent donc proposer des modes UEFI ou BIOS, qui peuvent être sélectionnées dans la configuration du BIOS. Certains systèmes appartiennent déjà à la classe 3 (par exemple, Microsoft Surface Book), mais ils sont rares. Dans le but de rendre omniprésentes des fonctionnalités telles que Secure Boot d'UEFI, Intel prévoit de supprimer la prise en charge CSM des nouvelles plates-formes client et serveur d'ici 2020. Par conséquent, toutes les nouvelles plates-formes à partir de ce moment seront strictement en classe 3.
Une fois CSM supprimé, les nouvelles plates-formes ne pourront pas exécuter de systèmes d'exploitation 32 bits, ne pourront pas utiliser de logiciels associés (au moins en mode natif) et ne pourront pas utiliser de matériel plus ancien, comme des HBA RAID (et donc des disques durs plus anciens connectés) à ces adaptateurs de bus hôte), cartes réseau et même cartes graphiques dépourvues de BIOS compatible UEFI (lancées avant 2012-2013). Ceux qui ont besoin de programmes plus anciens pourront toujours les exécuter en mode virtualisation, mais le matériel obsolète devra être retiré ou rester sur des plates-formes plus anciennes (classe 2 et antérieur).
Pour les années restantes, Intel recommande à ses partenaires d'améliorer l'expérience utilisateur UEFI, de promouvoir les fonctionnalités UEFI comme le démarrage sécurisé, la capsule signée et autres, et de supprimer les dépendances DOS / BIOS des outils de maintenance de production. Faites essentiellement tout pour réduire l'importance de CSM.
Une question intéressante concernant la dépréciation de la prise en charge du BIOS hérité sur les nouvelles plates-formes d'Intel est laquelle d'entre elles sera la première à abandonner CSM dans l'espace client. Intel prépare un certain nombre de plates-formes clientes pour PC de bureau et mobiles grand public (10e génération et ultérieur) qui seront lancées dans les années à venir, mais à l'heure actuelle, nous n'avons aucune idée si la société a l'intention de réduire CSM à un point en 2020, ou si ce sera un changement difficile.
Mais une option qui a un effet pervers, elle empêche de continuer à utiliser un ancien matériel parfaitement fonctionnel mais non signé. Typiquement, une vieille carte son PCI par exemple, datant d’une époque où les composants n’étaient pas signés numériquement, ne fonctionnerait pas sur un PC équipé d’un UEFI en classe 3. Il lui faut un mode Legacy BIOS pour continuer à tourner (classe 2).
L’autre effet pervers liée à cette évolution vers la classe 3 vient du monde du logiciel libre. Car si un système peut refuser un matériel non signé numériquement, il peut également n’autoriser que les systèmes d’exploitations de son choix. Une carte mère en classe 3 peut carrément bloquer l'installation de Linux et obliger d'utiliser Windows 10 et ultérieur
Il reste à voir si AMD a des plans similaires - nous avons cherché à déterminer l'état des lieux. La principale raison pour laquelle Intel effectue ce changement est due à la sécurité, et certains OEM peuvent nécessiter des fonctionnalités UEFI spécifiques dans leurs futurs produits.
Toutefois, si l'installation de Linux est impossible alors voici une parade : allez dans les paramètres de la carte mère (BIOS) et il vous suffira de définir un mot de passe administrateur (Set Supervisor Password / Set Admin Password) qui débloquera les menus grisés et de passer les options Secure Boot et Fast Boot @ Disabled (désactivé) pour pouvoir installer Ubuntu sur votre ordinateur (méthode la + simple). Le fait de définir un mot de passe administrateur empêchera le système ainsi que les virus UEFI de modifier ou de mettre à jour le BIOS.
Pratiquement tous les ordinateurs sont vulnérables à la récente cyberattaque Logo FAIL - Quand UEFI chope un virus !
Si UEFI de votre carte mère est infectée, il vous suffira de reflasher cette dernière avec la mise à jour depuis le site du constructeur via une clef USB (réseau débranché) et il existe une parade pour bloquer toute infection : le mot de passe administrateur (si possible désactiver "Flash Write") au sein du BIOS
Les UEFI qui démarrent les appareils Windows et Linux peuvent être piratés par des images de logo malveillantes.
Des centaines de modèles d'ordinateurs Windows et Linux provenant de pratiquement tous les fabricants de matériel sont vulnérables à une nouvelle attaque qui exécute un micrologiciel malveillant au début de la séquence de démarrage, ce qui permet des infections qu'il est pratiquement impossible de détecter ou d'éliminer à l'aide des mécanismes de défense actuels.
L'attaque, baptisée Logo FAIL par les chercheurs qui l'ont conçue, se distingue par la relative facilité avec laquelle elle est exécutée, l'étendue des modèles grand public et professionnels concernés et le haut niveau de contrôle qu'elle permet d'exercer sur eux. Dans de nombreux cas, Logo FAIL peut être exécuté à distance dans des situations de post-exploitation en utilisant des techniques qui ne peuvent pas être détectées par les produits de sécurité traditionnels pour les points finaux. Et comme les exploits s'exécutent durant les premières étapes du processus de démarrage, ils sont capables de contourner toute une série de défenses, y compris le Secure Boot de l'industrie, le Secure Boot d'Intel et les protections similaires d'autres sociétés conçues pour empêcher les infections par les "bootkits".
Game over pour la sécurité de la plateforme
LogoFAIL est une constellation de deux douzaines de vulnérabilités récemment découvertes qui se cachent depuis des années, voire des décennies, dans les interfaces de micrologiciel extensibles unifiées responsables du démarrage des appareils modernes exécutant Windows ou Linux. Les vulnérabilités sont le fruit de près d’un an de travail de Binarly, une entreprise qui aide les clients à identifier et à sécuriser les micrologiciels vulnérables.
Les vulnérabilités font l’objet d’une divulgation massive coordonnée publiée mercredi. Les sociétés participantes représentent la quasi-totalité de l'écosystème des processeurs x64 et ARM, à commencer par les fournisseurs UEFI AMI, Insyde et Phoenix (parfois encore appelés IBV ou fournisseurs de BIOS indépendants) ; des fabricants d'appareils tels que Lenovo, Dell et HP ; et les fabricants de processeurs intégrés aux appareils, généralement Intel, AMD ou les concepteurs de processeurs ARM. Les chercheurs ont dévoilé l'attaque mercredi lors de la Black Hat Security Conference à Londres.
Les parties concernées publient des avis indiquant lesquels de leurs produits sont vulnérables et où obtenir des correctifs de sécurité. Des liens vers des avis et une liste de désignations de vulnérabilités apparaissent à la fin de cet article.
Comme son nom l'indique, LogoFAIL implique des logos, en particulier ceux du vendeur de matériel, qui s'affichent sur l'écran de l'appareil au début du processus de démarrage, alors que l'UEFI est toujours en cours d'exécution. Les analyseurs d'images dans les UEFI des trois principaux IBV sont criblés d'environ une douzaine de vulnérabilités critiques qui sont passées inaperçues jusqu'à présent. En remplaçant les images de logo légitimes par des images identiques spécialement conçues pour exploiter ces bugs, LogoFAIL permet d'exécuter du code malveillant à l'étape la plus sensible du processus de démarrage, connue sous le nom de DXE, abréviation de Driver Execution Environment.
"Une fois l'exécution de code arbitraire réalisée pendant la phase DXE, la partie est terminée pour la sécurité de la plateforme", ont écrit des chercheurs de Binarly, la société de sécurité qui a découvert les vulnérabilités, dans un livre blanc. "A partir de cette étape, nous avons un contrôle total sur la mémoire et le disque de l'appareil cible, y compris ainsi sur le système d'exploitation qui sera démarré."
À partir de là, LogoFAIL peut fournir une charge utile de deuxième étape qui dépose un exécutable sur le disque dur avant même le démarrage du système d'exploitation principal. La vidéo suivante montre un exploit de validation de principe créé par les chercheurs. L'appareil infecté – un Lenovo ThinkCentre M70 de deuxième génération exécutant un processeur Intel Core de 11e génération avec un UEFI sorti en juin – exécute des défenses de micrologiciel standard, notamment Secure Boot et Intel Boot Guard.
Dans un e-mail, le fondateur et PDG de Binarly, Alex Matrosov, a écrit :
LogoFAIL est un ensemble récemment découvert de vulnérabilités de sécurité à fort impact affectant différentes bibliothèques d'analyse d'images utilisées dans le micrologiciel du système par divers fournisseurs pendant le processus de démarrage de l'appareil. Ces vulnérabilités sont présentes dans la plupart des cas dans le code de référence, affectant non pas un seul fournisseur mais l'ensemble de l'écosystème de ce code et des fournisseurs d'appareils où il est utilisé. Cette attaque peut donner à un acteur malveillant un avantage en contournant la plupart des solutions de sécurité des points finaux et en fournissant un kit de démarrage de micrologiciel furtif qui persistera dans une capsule de micrologiciel avec une image de logo modifiée.
Détournement du flux d'exécution
Il existe plusieurs façons d'exploiter LogoFAIL. Les attaques à distance fonctionnent en exploitant d'abord une vulnérabilité non corrigée dans un navigateur, un lecteur multimédia ou une autre application et en utilisant le contrôle administratif obtenu pour remplacer l'image du logo légitime traitée au début du processus de démarrage par une image identique qui exploite une faille de l'analyseur. L’autre méthode consiste à accéder brièvement à un appareil vulnérable pendant qu’il est déverrouillé et à remplacer le fichier image légitime par un fichier malveillant.
Dans les deux cas, le logo malveillant amène UEFI à exécuter le code créé par l’attaquant pendant la phase DXE très importante à chaque démarrage de l’appareil. En exécutant du code à ce stade précoce, lorsque la majeure partie de l'initialisation du système est effectuée, un exploit détourne tout le flux d'exécution qui suit, lui permettant de contourner les défenses de sécurité telles que Secure Boot et les mécanismes de démarrage vérifiés basés sur le matériel tels que Intel Boot Guard, AMD. Démarrage validé par le matériel ou démarrage sécurisé basé sur ARM TrustZone.
Selon la configuration UEFI, une simple commande copier/coller, exécutée soit par l'image malveillante, soit avec un accès physique, suffit dans de nombreux cas pour placer l'image malveillante dans ce que l'on appelle ESP, abréviation de EFI System Partition, une région du disque dur qui stocke les chargeurs de démarrage, les images du noyau et tous les pilotes de périphérique, utilitaires système ou autres fichiers de données nécessaires avant le chargement du système d'exploitation principal.
Cette approche présente des avantages majeurs. La première est qu'aucun code exécutable ne touche jamais le disque dur, une technique connue sous le nom de malware sans fichier qui entrave la détection par les antivirus et autres types de logiciels de protection des points finaux. Autre avantage : une fois l'image en place, elle garantit qu'un appareil reste infecté même lorsqu'un système d'exploitation est réinstallé ou que le disque dur principal est remplacé.
Lorsque le micrologiciel du système basé sur UEFI est configuré pour utiliser correctement des protections telles qu'Intel Boot Guard avec un logo non modifiable, il n'est pas possible de déposer l'image malveillante dans l'ESP. Dans la plupart de ces cas, cependant, il est toujours possible d'exécuter un outil logiciel disponible gratuitement sur le site Web d'IBV ou du fournisseur de l'appareil, qui reflashera le micrologiciel du système d'exploitation. Pour passer les contrôles de sécurité, l'outil installe le même micrologiciel UEFI signé cryptographiquement déjà utilisé, avec seule l'image du logo, qui ne nécessite pas de signature numérique valide, modifiée. Dans de nombreux cas, l’outil IBV est signé numériquement, ce qui rend moins probable l’intervention des protections des points finaux.
Dans la présentation de mercredi, les chercheurs ont fourni le schéma suivant pour illustrer le fonctionnement des attaques LogoFAIL.
Dans le livre blanc accompagnant la présentation, les chercheurs écrivent :
Comme le montre l'image précédente, une attaque LogoFAIL peut être divisée en trois étapes différentes. Tout d'abord, l'attaquant prépare une image de logo malveillante et la stocke dans l'ESP ou dans une section non signée d'une mise à jour du micrologiciel, puis il redémarre l'appareil. Au cours du processus de démarrage, le microprogramme vulnérable chargera le logo malveillant à partir de l'ESP et l'analysera à l'aide d'un analyseur d'images vulnérable, ce qui permet à l'attaquant de détourner le flux d'exécution en exploitant une vulnérabilité dans l'analyseur lui-même. En exploitant cette menace, l'attaquant peut exécuter un code arbitraire pendant la phase DXE, ce qui signifie que la sécurité de la plateforme est totalement compromise.
Ce second schéma reflète l'influence du processus de démarrage du microprogramme UEFI et montre la différence entre l'exploit BlackLotus, qui a moins d'impact que LogoFAIL.
En bref, quel est l'impact exact de nos conclusions et qu'est-ce qui rend LogoFAIL si dangereux ? Comme nous pouvons le voir sur l'illustration précédente :
LogoFAIL ne nécessite aucun accès physique à l'appareil. Comme il peut être exécuté entièrement à partir du système d'exploitation, il brise complètement toute frontière de sécurité entre le système d'exploitation et le micrologiciel. Les défenses modernes "sous le système d'exploitation", telles que Secure Boot, sont également totalement inefficaces pour contrer cette menace.
Les attaques qui commencent au niveau du micrologiciel peuvent être exploitées pour installer un kit de démarrage et contourner tout mécanisme de sécurité au niveau du système d'exploitation, tout en restant totalement indétectables par les solutions de détection de la sécurité.
Étant donné que LogoFAIL cible le code spécifique de l'UEFI, cette nouvelle menace n'est pas limitée à une seule architecture. Il s'agit au contraire d'un autre exemple d'exploitation intersilicielle qui affecte à la fois les appareils x86 et ARM.
Y a-t-il un "fuzzer" dans la plate-forme ?
Les chercheurs ont découvert les vulnérabilités en exécutant les analyseurs d'images UEFI à l'aide d'un outil connu sous le nom de fuzzer. Les fuzzers sont conçus pour identifier les bogues de programmation en exécutant de petits morceaux de code encore et encore avec de petites variations dans l'entrée à chaque fois. À chaque fois qu'il y a un plantage, le fuzzer note l'adresse mémoire où il s'est produit et l'entrée qui l'a déclenché. Une analyse plus poussée à l'aide d'autres outils et processus a permis aux chercheurs d'isoler les bogues qui permettent l'exécution de code arbitraire ou d'autres types de vulnérabilités.
"À la fin de la campagne, nous avons été submergés par le nombre de plantages que nous avons trouvés, à tel point que les trier manuellement s'est avéré assez compliqué", écrivent les chercheurs. Au total, ils ont identifié 24 causes profondes uniques, dont 13 sont, selon eux, exploitables.
Ce processus de triage nous a permis de bien comprendre les causes profondes de ces bogues. Bien qu'ils couvrent un large éventail de problèmes de sécurité logicielle, le thème sous-jacent est un manque de validation des données fournies par l'attaquant. Par exemple, la première capture d'écran montre un bogue dans l'analyseur BMP de l'AMI : le pointeur appelé "Image" est initialisé en ajoutant à l'adresse de départ de l'image (&Header->CharB) le champ d'en-tête "ImageOffset". Comme ce décalage peut être fixé arbitrairement par un attaquant, la variable "Image" peut pointer presque n'importe où dans la mémoire. La deuxième capture d'écran est tirée de l'analyseur PNG de l'AMI et elle ne contient pas un seul bogue, mais deux. Le premier bogue est une vérification manquante de la valeur de retour de la fonction "EfiLibAllocateZeroPool", qui renvoie NULL en cas d'échec. Le second bogue est un débordement d'entier sur l'entier 32 bits représentant la taille de l'allocation. Lorsque l'attaquant définit la variable "PngWidth" à une grande valeur, la multiplication par deux fera déborder le résultat et le transformera en une petite valeur (par exemple : 0x80000200 * 2 = 0x400). De cette manière, l'attaquant peut forcer l'allocation d'un tampon trop petit pour contenir les données PNG décodées et ainsi faire déborder le tampon lorsqu'il sera utilisé.
Les résultats de notre campagne de fuzzing indiquent sans équivoque qu'aucun de ces analyseurs d'images n'a jamais été testé par des IBV ou des OEM. Nous pouvons affirmer cela en toute confiance parce que le fuzzer a été capable de trouver des plantages juste après avoir fonctionné pendant quelques secondes et nous avons trouvé des plantages dans presque tous les analyseurs que nous avons testés.
Étant donné que les vulnérabilités de l'analyseur d'images exploitées par LogoFAIL résident dans l'UEFI, les Mac, les smartphones et les autres appareils qui reposent sur d'autres mécanismes de démarrage ne sont pas affectés. Il est intéressant de noter que même lorsqu'Apple s'appuyait sur l'UEFI pour démarrer une génération antérieure de Macs équipés de processeurs Intel, ceux-ci n'étaient toujours pas vulnérables au LogoFAIL. La raison : Apple a codé en dur les fichiers d'image dans l'UEFI, ce qui rend impossible le remplacement du fichier légitime par un sosie malveillant. En tant que développeur à la fois du matériel et des logiciels qui font fonctionner les Mac, Apple avait cette capacité. La diversité des écosystèmes gravitant autour des plateformes Windows et Linux exige une plus grande souplesse.
De nombreux appareils vendus par Dell ne sont pas directement exploitables car les fichiers images sont protégés par Intel Boot Guard, ce qui rend impossible leur remplacement, même en cas d'attaque physique. En outre, de nombreux appareils Dell ne permettent pas de personnaliser le logo. Bien que ces conceptions ferment efficacement la surface d'attaque de LogoFAIL, M. Binarly recommande de corriger les vulnérabilités d'analyse d'image de haute sévérité, "car elles représentent un danger qui pourrait se transformer par inadvertance en problème de sécurité".
Un bref historique des exploits du firmware
LogoFAIL s'appuie sur un vaste corpus de recherches menées sur plus d'une décennie. Le détournement de la séquence de démarrage en exploitant des bogues d'analyse d'images dans les UEFI a été démontré pour la première fois lors d'une présentation Black Hat en 2009 par les chercheurs Rafal Wojtczuk et Alexander Tereshkin. Depuis lors, de nouvelles découvertes ont été régulièrement faites dans le cadre de recherches ultérieures et, dans quelques cas, d'attaques découvertes dans la nature par des acteurs malveillants du monde réel.
Le premier cas connu d’attaque réelle exploitant la puissance de l’UEFI s’est produit en 2018 avec la découverte d’un malware baptisé LoJax. Version réutilisée d'un logiciel antivol légitime connu sous le nom de LoJack, LoJax a été créé par le groupe de piratage soutenu par le Kremlin et suivi sous des noms tels que Sednit, Fancy Bear et APT 28. Le logiciel malveillant a été installé à distance à l'aide d'outils malveillants capables de lire et d'écraser des parties. de la mémoire flash du firmware UEFI.
En 2020, les chercheurs ont découvert le deuxième exemple connu de malware réel attaquant l’UEFI. Chaque fois qu'un appareil infecté redémarrait, son UEFI vérifiait si un fichier malveillant était présent dans le dossier de démarrage de Windows et, sinon, l'installait. Les chercheurs de Kaspersky, le fournisseur de sécurité qui a découvert le logiciel malveillant et l'a nommé « MosaicRegressor », ne savent toujours pas comment l'UEFI a été infecté. Une possibilité est que les PC aient reçu une fausse mise à jour UEFI. Une autre possibilité était d'obtenir un bref accès physique. sur un appareil et en utilisant une clé USB spécialement conçue pour infecter l’UEFI.
Depuis lors, une poignée de nouveaux bootkits UEFI ont vu le jour. Ils sont suivis sous des noms tels que ESpecter, FinSpy et MoonBounce. En réponse à ces menaces, les fabricants d'appareils ont commencé à introduire des mesures pour mieux verrouiller le processus de démarrage UEFI.
La clé parmi les défenses est Secure Boot, une norme à l'échelle de l'industrie qui utilise des signatures cryptographiques pour garantir que chaque logiciel utilisé au démarrage est approuvé par le fabricant de l'ordinateur. Secure Boot est conçu pour créer une chaîne de confiance qui empêche les attaquants de remplacer le micrologiciel de démarrage prévu par un micrologiciel malveillant. Si un seul maillon de la chaîne de démarrage n'est pas reconnu, Secure Boot empêchera le démarrage de l'appareil.
Plus tôt cette année, des chercheurs de la société de sécurité ESET ont découvert le premier exemple connu de malware UEFI qui contourne le démarrage sécurisé. La capacité du kit de démarrage UEFI, surnommé Black Lotus, à vaincre une protection de sécurité en place depuis 12 ans était impressionnante, mais il souffrait d'une limitation clé : il pouvait être tué en effectuant une simple réinstallation du système d'exploitation principal. . LogoFAIL n'a pas une telle limitation. Tant que l'image malveillante est exécutée par l'UEFI, la machine exécutant le firmware restera infectée. Le schéma suivant, présentée plus haut dans cet article, met en contraste les différences entre LogoFAIL et Black Lotus.
Rien n’indique que les vulnérabilités de LogoFAIL aient été activement exploitées dans la nature, mais il est également difficile de le savoir, car les infections sont très difficiles à détecter à l’aide d’outils et de méthodes traditionnels. Cependant, un indice de compromission peut être fourni en examinant le fichier image analysé lors du démarrage. Si le hachage cryptographique de ce fichier diffère du hachage du fichier que les fabricants d'appareils mettent généralement à disposition gratuitement, l'appareil peut être analysé plus en détail pour rechercher des signes indiquant qu'il a été exploité.
Les vulnérabilités LogoFAIL sont suivies sous les désignations suivantes :
- CVE-2023-5058
- CVE-2023-39538
- CVE-2023-39539
- CVE-2023-40238
Cette liste est actuellement incomplète. Des avis sont disponibles auprès d’une douzaine de parties. Une liste non exhaustive d'entreprises publiant des avis comprend AMI, Insyde, Phoenix et Lenovo. La liste complète n’était pas disponible au moment de la publication. Les personnes souhaitant savoir si un appareil spécifique est vulnérable doivent vérifier auprès du fabricant.
La meilleure façon de prévenir les attaques LogoFAIL est d’installer les mises à jour de sécurité UEFI publiées dans le cadre du processus de divulgation coordonné de mercredi. Ces correctifs seront distribués par le fabricant de l'appareil ou par la carte mère exécutée à l'intérieur de l'appareil. C'est également une bonne idée, lorsque cela est possible, de configurer les UEFI pour utiliser plusieurs couches de défense. Outre Secure Boot, cela inclut à la fois Intel Boot Guard et, lorsqu'il est disponible, Intel BIOS Guard. Il existe des défenses supplémentaires similaires disponibles pour les appareils exécutant des processeurs AMD ou ARM. La parade consiste à définir un mot de passe administrateur au sein de UEFI pour contre-carrer tout attaque.
Aucun commentaire :
Enregistrer un commentaire