Getty Images
Alors que la quantité de données sensibles stockées sur les ordinateurs a explosé au cours de la dernière décennie, les fabricants de matériel et de logiciels ont investi de plus en plus de ressources pour sécuriser les appareils contre les attaques physiques en cas de perte, de vol ou de confiscation. Plus tôt cette semaine, Intel a corrigé une série de bogues qui permettaient aux attaquants d’installer un micrologiciel malveillant sur des millions d’ordinateurs utilisant ses processeurs.
Les vulnérabilités permettaient aux pirates disposant d’un accès physique de remplacer une protection Intel intégrée dans les processeurs modernes qui empêche les micrologiciels non autorisés de s’exécuter pendant le processus de démarrage. Connue sous le nom de Boot Guard, la mesure est conçue pour ancrer une chaîne de confiance directement dans le silicium afin de garantir que tous les micrologiciels chargés sont signés numériquement par le fabricant de l’ordinateur. Boot Guard protège contre la possibilité que quelqu’un falsifie le SPI-puce flash connectée qui stocke le UEFI, qui est un micrologiciel complexe qui relie le micrologiciel d’un PC à son système d’exploitation.
Sécurité renforcée par le matériel
Ces types de piratage se produisent généralement lorsque des attaquants connectent du matériel à l’intérieur d’un ordinateur et utilisent Dediprog ou des outils de programmation de puces similaires pour remplacer le micrologiciel autorisé par un micrologiciel malveillant.
Trammel Hudson
Comme l’explique Intel ici:
L’exécution du code BIOS UEFI n’est généralement pas liée au matériel sous-jacent, ce qui signifie que ce code BIOS UEFI s’exécute sans être vérifié ou mesuré. Par conséquent, cela rend l’ensemble du processus de démarrage vulnérable à la subversion du BIOS, que cela puisse se produire via un processus de mise à jour non protégé ou de simples attaques matérielles utilisant le remplacement de la mémoire flash SPI ou l’utilisation d’un Dediprog.
Intel Boot Guard fournit des contrôles de stratégie de démarrage renforcés par le matériel aux fabricants de plates-formes et aux propriétaires de plates-formes pour autoriser le code BIOS autorisé à s’exécuter sur cette plate-forme. Intel Boot Guard fournit cette racine de confiance (RoT) basée sur le matériel pour la vérification du démarrage de la plate-forme, qui est responsable de la vérification de l’image du BIOS avant l’exécution du BIOS. Intel Boot Guard augmente la barre de sécurité de la plate-forme, réduisant les vecteurs d’attaque ci-dessus et rendant plus difficile le lancement d’attaques pour subvertir le processus de démarrage.
Au début de cette année, le chercheur en sécurité Trammell Hudson a découvert trois vulnérabilités qui empêchaient Boot Guard de fonctionner lorsqu’un ordinateur sortait du mode veille. Connu techniquement sous le nom de S3, ce mode préserve tous les éléments stockés dans la mémoire de l’ordinateur mais éteint complètement le processeur.
Subvertir Boot Guard
Un attaquant capable de contourner Boot Guard lors du réveil pourrait alors mener une multitude d’activités malveillantes. Le principal d’entre eux est d’obtenir les clés utilisées pour crypter les disques durs, à condition que les clés soient stockées en mémoire, comme c’est le cas avec de nombreux ordinateurs en veille. Avec cela, un attaquant pourrait obtenir les versions déchiffrées de toutes les données stockées sur l’ordinateur sans avoir besoin du mot de passe de l’utilisateur.
Un attaquant pourrait également infecter la machine avec un rootkit (code malveillant difficile ou impossible à détecter) qui s’exécuterait dans mode de gestion du système jusqu’au prochain redémarrage. De tels implants SMM sont le genre de chose que la NSA aurait.
Bien que ces types d’exploits soient graves, les scénarios d’attaque sont limités car le piratage ne peut pas être effectué à distance. Pour de nombreuses personnes, les attaques qui nécessitent un accès physique ne font pas partie de leur modèle de menace. Cela nécessiterait également une expertise matérielle et micrologicielle et des outils spéciaux tels que le Dediprog ou Spispy, un émulateur flash open source développé par Hudson. Dans un article publié cette semaine, Hudson a écrit:
Étant donné que CVE-2020-8705 nécessite un accès physique, il est plus difficile à utiliser pour un attaquant qu’un exploit distant. Cependant, il existe quelques scénarios d’attaque réalistes où il pourrait être utilisé.
Un exemple est celui du dédouanement dans un aéroport. La plupart des voyageurs ferment leur ordinateur portable pendant la descente et lui permettent d’entrer en veille S3. Si l’appareil est pris par l’agence adverse lors de l’atterrissage, les clés de chiffrement du disque sont toujours en mémoire. L’adversaire peut retirer le capot inférieur et attacher un émulateur de flash intégré au système comme le spispy à la puce flash. Ils peuvent réveiller la machine et lui fournir leur firmware via le spispy. Ce micrologiciel peut analyser la mémoire pour localiser le processus d’écran de verrouillage du système d’exploitation et le désactiver, puis permettre au système de reprendre normalement. Ils ont désormais accès à l’appareil déverrouillé et à ses secrets, sans qu’il soit nécessaire d’obliger le propriétaire à fournir un mot de passe.
L’adversaire peut également installer son propre rootkit SMM « Ring -2 » à ce stade, qui restera résident jusqu’au prochain redémarrage dur. Cela pourrait leur fournir une exécution de code sur le système lorsqu’il s’est déplacé vers un réseau de confiance, permettant potentiellement un mouvement horizontal.
Un autre exemple est un implant matériel qui émule le flash SPI. L’iCE40up5k [a small field-programmable gate array board] utilisé dans l’une des variantes du spispy s’adapte facilement à l’intérieur ou sous un package SOIC-8, permettant une attaque persistante contre le chemin de reprise. Étant donné que le FPGA peut facilement faire la distinction entre un démarrage à froid et une validation du système sortant du mode veille, l’appareil peut fournir une version propre du micrologiciel avec la signature correcte lorsqu’il est validé ou lu par un outil comme flashrom, et ne version modifiée lors d’une reprise de veille. Ce type d’implant serait très difficile à détecter via un logiciel et, s’il était bien fait, ne serait pas déplacé sur la carte mère.
Le correctif est dans
L’une des vulnérabilités de Boot Guard provenait des paramètres de configuration que les fabricants brûlent littéralement dans le processeur via un processus appelé fusibles programmables à usage unique. Les OEM sont censés avoir la possibilité de configurer la puce pour exécuter Boot Guard lorsqu’un ordinateur sort de S3 ou non. Hudson ne sait pas pourquoi les cinq fabricants qu’il a testés l’ont éteint, mais il soupçonne que c’est parce que les machines reprennent beaucoup plus rapidement de cette façon.
Dans un e-mail, une porte-parole d’Intel a écrit: «Intel a été informé d’une vulnérabilité affectant Intel Boot Guard dans laquelle une attaque physique pourrait être en mesure de contourner l’authentification Intel Boot Guard lors de la reprise de l’état de veille. Intel a publié des mesures d’atténuation et recommande de conserver la possession physique des appareils. »
Intel ne dit pas comment il a corrigé une vulnérabilité qui découle de paramètres de fusible qui ne peuvent pas être réinitialisés. Hudson soupçonne qu’Intel a effectué le changement en utilisant un micrologiciel qui s’exécute dans Intel Management Engine, un coprocesseur de sécurité et de gestion à l’intérieur du chipset du processeur qui gère l’accès aux fusibles OTP, entre autres choses. (Plus tôt cette semaine, Intel a publié des détails jamais divulgués auparavant sur le ME ici.)
Les deux autres vulnérabilités provenaient de failles dans la façon dont les CPU récupéraient le micrologiciel lors de la mise sous tension. Les trois vulnérabilités ont été indexées sous l’ID de suivi unique CVE-2020-8705, qui a reçu une cote de gravité élevée d’Intel. (Intel a un aperçu de tous les correctifs de sécurité de novembre ici. Les fabricants d’ordinateurs ont commencé à publier des mises à jour cette semaine. Le post de Hudson, lié ci-dessus, a une rédaction beaucoup plus détaillée et technique.
