Une fuite récente d'une « Golden Key » de Microsoft couplée à la présence d'un mode Debug a permis de désactiver le démarrage sécurisé sur les appareils Windows. Continuer à lire!
Les systèmes d'exploitation Windows ne sont plus le choix par défaut et le premier choix sur la scène mobile. La nature Open Source d'Android a trouvé de nombreux fans chez les constructeurs OEM et, par conséquent, de moins en moins de téléphones utilisent Windows de nos jours.
Mais si vous faites partie de ceux qui continuent à utiliser un appareil Windows dans leur vie quotidienne, il y a quelques nouvelles pour vous. Bon ou mauvais, cela dépend de votre position et de votre interprétation des cas d'utilisation de cette actualité.
Comme le rapporte Ars Technica et Le registre avec les nouvelles provenant d'un site internet qui va probablement vous donner mal à la tête (je ne plaisante pas), quelques développeurs (@jamais_libéré et @TheWack0lian) ont découvert qu'une porte dérobée intégrée par Microsoft à des fins de débogage ouvrait la possibilité de désactiver le démarrage sécurisé sur les appareils Windows.
Le démarrage sécurisé et qu'est-ce que c'est?
Lorsque vous démarrez pour la première fois un appareil Windows, la procédure de démarrage se déroule dans cet ordre général: UEFI (Unified Extensible Firmware Interface, qui remplace le BIOS) -> Boot Manager -> Boot Loader -> Les fenêtres. UEFI est l’endroit où la fonctionnalité Secure Boot est présente. Comme son nom l'indique avec Démarrage sécurisé, il vise à améliorer la sécurité en exigeant des signatures numériques sur les prochaines étapes. Essentiellement, si le chargeur de démarrage n'est pas signé avec les clés avec lesquelles l'UEFI s'attend à ce qu'il le soit, la procédure de démarrage de votre appareil ne se terminera pas.
Secure Boot est une fonctionnalité facultative, mais Microsoft a rendu son activation obligatoire pour obtenir la certification Windows à partir de Windows 8 et versions ultérieures. Le raisonnement ici était que le démarrage sécurisé rendrait difficile aux auteurs de logiciels malveillants l'insertion de code dans la procédure de démarrage. Cependant, un effet secondaire du Secure Boot était qu'il rendait un peu compliqué le double démarrage sur les machines Windows, car soit le deuxième système d'exploitation et tous ses prérequis doivent également être signés numériquement, soit le démarrage sécurisé doit l'être. désactivé. Il y a beaucoup d’autres problèmes à cela, et les utilisateurs chevronnés du double démarrage en savent plus que je ne pourrais l’expliquer dans un paragraphe.
Désormais, il existe certains appareils sur lesquels le démarrage sécurisé ne peut pas être désactivé par l'utilisateur même s'il le souhaite. C'est le domaine dans lequel notre sujet est considérablement réduit à tous les appareils Windows (y compris ordinateurs de bureau) vers des appareils Windows spécifiques tels que les appareils Windows Phone, les appareils Windows RT, certains appareils Surface et même HoloLens. Ces appareils d'utilisateur final ont Démarrage sécurisé verrouillé, ce qui signifie qu'un l'utilisateur final ne peut pas modifier ou désactiver les aspects liés au démarrage sécurisé, et par extension, ils ne peuvent pas toucher au système d'exploitation d'une manière non autorisée par Microsoft pour l'utilisateur final.
Mais aux fins du développement officiel en cours, Secure Boot doit être un peu assoupli. Sur les appareils sur lesquels Secure Boot est verrouillé, il existe des politiques de démarrage sécurisé qui peuvent faciliter le développement autorisé sans avoir besoin de désactiver Secure Boot. Comme le mentionnent les utilisateurs chercheurs, ce fichier de stratégie de démarrage sécurisé est chargé par le gestionnaire de démarrage au début du processus de démarrage de Windows. Les fichiers de stratégie peuvent également contenir des règles de registre qui, à leur tour, peuvent contenir, entre autres, des configurations pour la stratégie elle-même. Encore une fois, le fichier de stratégie doit être signé et d'autres dispositions sont en place pour garantir que seul Microsoft peut apporter ces modifications.
L’élément de signature s’appuie également sur ce qu’on appelle le DeviceID, qui est utilisé lors de l’application. Je vais laisser le billet de blog expliquer ici, car il y a quelques parties qui ne sont pas aussi claires pour moi :
Il existe également une chose appelée DeviceID. Il s'agit des 64 premiers bits d'un hachage SHA-256 salé, d'une sortie UEFI PRNG. Il est utilisé lors de l'application de stratégies sur Windows Phone et sur Windows RT (mobilestartup le définit sur Phone et SecureBootDebug.efi lors de son premier lancement sur RT). Sur le téléphone, la politique doit être située à un endroit spécifique sur la partition EFIESP avec le nom de fichier incluant la forme hexadécimale du DeviceID. (Avec Redstone, cela a été remplacé par UnlockID, qui est défini par bootmgr et n'est que la sortie brute UEFI PRNG).
Fondamentalement, bootmgr vérifie la stratégie lors de son chargement. Si elle inclut un DeviceID qui ne correspond pas à l'ID de périphérique du périphérique sur lequel bootmgr est exécuté, la stratégie ne pourra pas se charger. Toute stratégie qui permet d'activer la signature de tests (MS appelle ces stratégies Retail Device Unlock / RDU, et pour les installer, c'est déverrouiller un appareil), est censé être verrouillé sur un DeviceID (UnlockID sur Redstone et au-dessus de). En effet, j'ai plusieurs politiques (signées par le certificat de production Windows Phone) comme celle-ci, où les seules différences sont le DeviceID inclus et la signature. Si aucune stratégie valide n'est installée, bootmgr utilise une stratégie par défaut située dans ses ressources. Cette politique est celle qui bloque l'activation de la signature de tests, etc., à l'aide des règles BCD.
C'est la partie où les choses deviennent intéressantes. Lors du développement de Windows 10 v1607, Microsoft a créé un nouveau type de stratégie de démarrage sécurisé (appelé désormais SBP par souci de concision) à des fins de tests et de débogage internes. La stratégie est de nature « supplémentaire », sans DeviceID présent, et elle entraîne la fusion de ses paramètres dans une stratégie de démarrage existante. Le gestionnaire de démarrage charge les anciens types de SBP, puis vérifie sa signature et son authenticité, puis charge ces politiques de démarrage supplémentaires. Le problème ici est qu’il n’y a aucune autre vérification sur la politique supplémentaire elle-même. De plus, les gestionnaires de démarrage antérieurs à Windows 10 v1511 ne connaissent pas l'existence de la nature supplémentaire de ces stratégies et, par conséquent, réagir comme s'ils avaient chargé une police d'assurance parfaitement valide et signée. Encore une fois, ce comportement était probablement dû au développement interne, de sorte que les développeurs n'auraient pas dû avoir à signer chaque version du système d'exploitation et chaque modification mineure qu'ils devaient apporter sur l'appareil.
Ce SBP est appelé « clé d'or » car il annule fondamentalement l'objectif des contrôles de signature. Ce SBP a été involontairement expédié sur des appareils vendus au détail, bien que dans un état désactivé. Les développeurs ont trouvé ce SBP et ont fait connaître leurs découvertes. Désormais, le SBP peut être trouvé flottant sur Internet, ce zip particulier étant utilisé pour installer le SBP sur les appareils Windows RT.
Qu'est-ce que cela signifie?
Si vous avez chargé un SBP supplémentaire, vous pouvez activer la signature de test pour Windows pour vous permettre de charger des pilotes non signés. De plus, étant donné que ces politiques entrent en jeu avant l'étape Boot Manager de la procédure de démarrage, vous pouvez compromettre la sécurité de l'ensemble de la commande et exécuter du code non autorisé (lecture auto-signé). Cela ouvre de nombreuses possibilités, tant pour les utilisateurs souhaitant modifier des parties de Windows au-delà de leur autorisation que pour les créateurs de logiciels malveillants.
Les auteurs de cette découverte se concentrent sur l’ironie de tout ce fiasco. Microsoft a verrouillé le démarrage sécurisé sur certains appareils pour garder les modifications non autorisées à distance, mais a ensuite intégré une porte dérobée pour leur permettre de poursuivre le développement et le débogage. Mais cette porte dérobée ouvre la voie à la désactivation du démarrage sécurisé sur tous les appareils exécutant Windows, rendant toute cette épreuve inutile.
Non seulement les utilisateurs volontaires peuvent désormais installer des distributions Linux (et éventuellement Android) sur des tablettes Windows uniquement et Les utilisateurs réticents peuvent également installer des bootkits malveillants s'ils compromettent l'accès physique à leur téléphone. appareil. Bien que le premier soit quelque chose sur lequel nous pouvons sauter dans les airs, le second n’inspire pas vraiment beaucoup de confiance. Cela va dans les deux sens et cela nous montre pourquoi la sécurité est une arme à double tranchant. De plus, le SBP est de nature universelle, permettant son utilisation sur n'importe quel appareil, quelle que soit son architecture. Ce n'est pas particulièrement utile pour les cas d'ordinateurs de bureau sur lesquels le démarrage sécurisé peut être facilement désactivé, mais il a une portée immense pour les appareils sur lesquels vous ne pouvez pas jouer avec le démarrage sécurisé.
Alors, quelle est la solution?
Microsoft a publié quelques correctifs, mais les développeurs insistent sur le fait que le problème n'est pas entièrement résolu. Vous pouvez consulter ces correctifs (MS16-094 et MS16-100), puis lisez le article de blog lui-même pourquoi ils ne résolvent pas le problème. S'ils sont corrects, ce problème n'a pas de correctif ou de correctif en vue, bien que cela n'empêchera pas Microsoft d'essayer de placer davantage de barrages routiers sur le chemin.
Et ensuite?
Il existe un monde de possibilités, et certaines d'entre elles se préparent sur nos forums Windows. Vous pouvez consulter nos forums sur Développement et piratage de Windows Phone 8 et nos forums pour Windows 8, Windows RT et Surface Développement et piratage. Vous pouvez également trouver fils d'instructions pour certains appareils, où d'autres utilisateurs discutent de la même chose.
La présence de cette porte dérobée de débogage et la fuite du SBP sont importantes non seulement pour le tiers développement d'appareils Windows verrouillés, ils nous montrent également un sombre rappel de ce qui peut arriver si c'est intentionnel il reste des portes dérobées. L'accent récemment mis sur la sécurité s'est tourné vers les agences d'enquête qui font pression pour que la présence de telles portes dérobées soit utilisée pour les aider dans leurs enquêtes légales. Mais tôt ou tard, ces méthodes volonté tomber entre de mauvaises mains. Ce qui est censé être utilisé comme un outil de lutte contre la criminalité et d’aide à la justice deviendra alors un jour l’outil du crime lui-même.
Que pensez-vous de la fuite du Debug SBP? Pensez-vous que de telles « clés d’or » devraient exister? Faites-le nous savoir dans les commentaires ci-dessous !