SecurityInsider
Le blog des experts sécurité Wavestone

La sécurité de Windows 10 – Partie 1 :Virtual Secure Mode (Espace virtualisé isolé)


Afficher l'image d'origine

Avec la sortie de Windows 10 et ses multiples nouvelles fonctionnalités de sécurité, les entreprises envisagent de plus en plus la transition de leur parc informatique. Afin de vous éclairer sur ces nouveautés, nous vous proposons une série d’articles sur ces nouveaux mécanismes implémentés par Microsoft. Au programme : Virtual Secure Mode, Credential Guard, Device Guard, Windows Hello, etc.

Présentation
Aujourd’hui, les entreprises équipées de machines sous Windows, que ce soit postes de travail ou serveurs, font face à une augmentation des menaces de sécurité. Du vol d’informations d’authentification à l’infection par des malwares, ces attaques profitent notamment de faiblesses inhérentes à Windows.
Dans le but de répondre à ces problèmes de sécurité, Microsoft a introduit de nouvelles fonctionnalités dans son dernier système d’exploitation, Windows 10. Les plus efficaces de ces nouveaux mécanismes se basent sur un concept particulier : Virtual Secure Mode, ou plus communément appelé « sécurité basée sur la virtualisation » . Il permet de sécuriser le système en créant une enclave protégée tirant parti de la virtualisation.


Figure 1 : Concept du Virtual Secure Mode

Virtual Secure Mode s’appuie sur l’hyperviseur Hyper-V 5.0+ pour créer un environnement sécurisé dans lequel s’exécutent des processus sensibles comme LSA, les routines de chiffrement et le contrôle d’intégrité des services. L’idée est ainsi d’isoler ces processus afin de protéger leur exécution et leurs données lors d’une compromission de l’environnement Windows normal. Microsoft a, en outre, choisi de complétement verrouiller la partition VSM en ne permettant à aucun code tiers de s’exécuter à l‘intérieur, en contrôlant à tout moment l’intégrité de celle-ci et en ne permettant même pas au noyau Windows d’y accéder. Toute compromission de ce dernier n’entrainerait pas de risques pour les processus et données sensibles telles que les informations d’authentification de domaine.

Fonctionnement
Historiquement, l’architecture moderne des processeurs utilise un système d’anneaux afin de protéger les différents niveaux du système d’exploitation en mettant en place une hiérarchie allant du plus privilégié (anneau le plus sécurisé, habituellement le numéro zéro dit Ring 0, qui contrôle l’espace d’adressage physique entier et héberge le kernel) au moins privilégié (anneau le moins sécurisé, habituellement celui au numéro le plus élevé, qui héberge les logiciels utilisateurs).
En intégrant l’hyperviseur Hyper-V dans l’équation, Windows 10 ajoute une nouvelle couche d’abstraction. Le choix a été fait afin d’apporter une séparation des pouvoirs du Ring 0 qui permettait au kernel d’exécuter toutes les instructions mais aussi d’accéder à la mémoire entière. Ainsi, possédant son propre jeu d’instructions lui permettant de s’émanciper des anneaux, Hyper-V a pour rôle de restreindre les actions du Ring 0. Se faisant, il se retrouve de facto en dessous de l’anneau 0 et est surnommé Ring -1. C’est maintenant ce dernier qui peut accéder à toute la mémoire physique, cantonnant le kernel à son rôle d’exécuteur d’instructions. L’hyperviseur est ainsi protégé du kernel et Ring 0.
De plus, sa petite taille en comparaison du reste du système fait qu’il est facile de vérifier son intégrité. Un point important à souligner est que Hyper-V tire profit de fonctions matérielles, notamment au niveau du microprocesseur (CPU), pour fonctionner.
Il aurait pu sembler intéressant d’isoler les processus et données sensibles dans l’hyperviseur, mais celui-ci aurait dès lors vu sa taille et sa complexité ainsi que sa surface d’attaque augmenter considérablement, conduisant à des risques de sécurité. Microsoft a alors imaginé un concept intéressant permettant de garder l’hyperviseur et d’isoler les processus et données critiques : les « Virtual Trust Levels » (VTL).
Les VTL sont des niveaux de sécurité allant de 0 à N (du moins accessible au plus accessible), un VTL est associé à un « Virtual Processor », un processeur virtuel. On peut schématiser de la sorte les deux modèles d’architecture :

Figure 2 : Architecture classique en anneaux à gauche, architecture en anneaux + VTL à droite

On remarque que les VTL apportent une nouvelle dimension. Il est dès lors possible de construire ce genre d’architecture :

Figure 3 : Architecture avec N VTL

Au contraire des anneaux, les VTL sont extensibles à l’infini et isolés les uns des autres. Cette propriété provient de l’utilisation de la traduction d’adresses de second niveau (Second Level Adress Translation ou SLAT), une technologie de virtualisation permettant d’éviter le problème de surcharge des « shadow page tables » (SPT), espace d’adressage utilisé par les machines virtuelles. SLAT permet en outre un mapping efficace entre hôte virtuel, hôte invité et système de pages physiques. Ainsi, les accès aux sections mémoires peuvent être facilement protégés et isolés les uns des autres.
Microsoft a fait le choix de deux VTL :

Figure 4 : Architecture de la sécurité basée sur virtualisation de Windows 10

À l’activation de Virtual Secure Mode, deux partitions virtualisées isolées (instances de machines virtuelles) sont créées :

  • Un « monde normal », s’exécutant dans le VTL0, dans lequel tourne le système Windows normal
  • Un « monde sécurisé », s’exécutant dans le VTL1, dans lequel tourne un système minimal hébergeant uniquement des composants critiques. La partie utilisateur de cet environnement sécurisé est appelée « Isolated User Mode » (IUM)
Puisque nous ne pouvons pas faire confiance à VTL0, la communication entre les deux partitions est quasi unidirectionnelle :
  •  VTL1 est quasi inaccessible à VTL0 (quelques données sont quand même partagées entre les deux partitions)
  • VTL1 ne peut accéder à VTL0 que par un canal sécurisé
En outre, c’est l’hyperviseur qui gère les accès en utilisant « Extended Page Tables » (EPT), l’implémentation Intel de SLAT. Celui-ci peut alors poser les restrictions suivantes sur VTL0, restrictions qui représentent en fait les nouvelles fonctionnalités de sécurité dans Windows 10 :
  • Bloquer la lecture (+R) : permet de cacher les secrets cryptographiques (Credential Guard)
  •  Bloquer la lecture, l’écriture et l’exécution (+RWX) : permet de bloquer l’exécution de code et la modification de code (Device Guard)
  • Bloquer l’écriture (+W) : permet de prévenir la modification de pages exécutables partagés avec VTL1
Voici une représentation des partitions en Virtual Secure Mode :


Figure 5 : Architecture générale du Virtual Secure Mode

Le monde sécurisé est composé du :

  • Secure Kernel Mode » (SKM) qui ne fait que le strict minimum (e. g. chiffrement des pages avant transfert en mémoire, …)
  • Isolated user Mode » (IUM) qui comprend des processus et données sensibles (e. g. les informations d’authentification, etc.)


Figure 6 : Architecture du Virtual Secure Mode

Les processus critiques dans le monde sécurisé sont appelés « Trustlets », ce sont des processus de confiance. Limités en nombre, ils sont isolés les uns des autres afin qu’un trustlet compromis ne corrompe pas le reste du système. C’est un module du secure kernel, « Hypervisor based Code Integrity », qui décide si un binaire peut être lancé en tant que trustlet ou non.
L’un des trustlets les plus intéressants est lsalso.exe, qui fournit la protection des informations d’authentification de domaine, Credential Guard. Cette fonctionnalité permet le chiffrement des secrets Kerberos et NTLM sans les rendre visibles à un attaquant extérieur, mais aussi le stockage sécurisé de la clé machine (machine key) avec Kerberos FAST, afin de se prémunir des attaques par rejeu et garantir l’origine du ticket-granting ticket (TGT). Le seul moyen d’accéder à ces secrets serait l’exploitation de vulnérabilités dans l’hyperviseur ou le matériel.
Les trustlets n’ont pas accès à CSRSS, aux redirections DLL, etc…
Enfin, Microsoft ne permet pas de créer ses propres trustlets. Mais, même dans le cas où il serait possible d’en créer (modification du système) et de les charger, notre trustlet devrait remplir certaines contraintes critiques de sécurité.

Figure 7 : Architecture de la sécurité basée sur la virtualisation

Intéressons-nous maintenant au monde sécurisé. Comme précédemment dit, l’hyperviseur se trouve sur un « anneau » bien à lui en dessous de l’anneau 0. Bien que ne faisant pas partie des mêmes VTL, le secure kernel mode (SKM) et normal kernel mode partagent le même anneau (Ring 0), de même que l’isolated user mode (IUM) et le normal user mode partagent le Ring 3.
Le SKM est composé de plusieurs éléments :

  • Un kernel minimal appelé Smart Kernel (SK)
  • Des modules pour le noyau :
    •  cng.sys (fournit les nouveaux services cryptographiques)
    •  skci.dll (driver de Code Integrity, nécessaire à Device Guard), aussi appelé « Hypervisor-based Code Integrity » (HVCI), est une version plus simple mais fonctionnellement identique de ci.dll, la bibliothèque standard de Code Integrity des systèmes Windows
Le SKM va, en outre, marquer les entrées dans l’EPT comme exécutable seulement si le HVCI a confirmé que le code dans les pages est signé. De manière globale, le kernel ne peut pas exécuter de pages exécutables provenant de l’IUM.
Les communications entre le monde normal et le monde sécurisé se font via des canaux sécurisés
Les trustlets communiquent avec les processus du monde normal grâce à des appels à distance RPC
Le kernel normal et le kernel sécurisé communiquent via des appels systèmes spécifiques au travers de l’hyperviseur
Ainsi, même si le monde normal est compromis, les canaux sécurisés permettent de garder le VTL1 en sécurité. Le monde sécurisé n’autorise aucune interaction avec l’utilisateur et aucune exécution de code tiers n’est permise par le secure kernel. Les performances de la sécurité basée sur la virtualisation sont optimisées matériellement et logiciellement, de sorte à avoir un impact minimal inférieur à 5%.

Prérequis
La sécurité basée sur la virtualisation nécessite quelques prérequis permettant de fournir un haut niveau de sécurité :

  • Windows 10 Enterprise 64-bits
  • Secure Boot, pour être sûr que le firmware lancé au démarrage est sûr
  • Technologie de virtualisation IOMMU (VT-d, AMD-Vi, etc.) afin de gérer les accès mémoire vers le monde sécurisé
  • Puce TPM 2.0 pour de stocker les secrets et clés dans le matériel
Néanmoins, la sécurité basée sur la virtualisation peut être activée malgré certaines contraintes matérielles non respectées, la sécurité du système en sera par contre réduite.

Installation
L’activation du Virtual Secure Mode est très simple puisqu’elle peut se faire par l’intermédiaire des stratégies de groupe (GPO) :

Figure 8 : Activation de la sécurité basée sur la virtualisation par GPO

Il est conseillé d’activer le démarrage sécurisé (Secure Boot) et les protections DMA qui correspondent à la protection matérielle apportée par la technologie de virtualisation.
Il faut aussi activer l’IUM et les fonctionnalités Hyper-V :

Figure 9 : Activation du mode utilisateur isolé et des fonctionnalités Hyper-V

Conclusion
Virtual Secure Mode représente une base très intéressante pour la sécurité sur la virtualisation. Microsoft a choisi d’implémenter ces nouvelles fonctionnalités de sécurité sur cette architecture afin de protéger efficacement les machines Windows 10. À ce jour, aucune faille dans la conception et dans l’implémentation n’a été publiée. Microsoft cherche à limiter la surface d’attaque : petite taille de l’hyperviseur, ajout de la dimension VTL, etc. De plus, l’entreprise a favorisé la séparation des pouvoirs, des privilèges et des rôles, ce qui représente une bonne pratique.
De manière général, le SKM ne fait pas confiance au système normal, bien qu’il en dépende. Le secure kernel ne fait pas plus que demandé en laissant le système Windows normal se charger de la gestion des ressources, gestion mémoire, etc. En outre, il ne paraît pas possible d’attaquer le système avec des attaques classiques de type NOP sled : le code non signé chargé (HVCI doit donc d’abord être contourné) ne serait pas exécuté puisque le SKM, au travers du mapping EPT, ne marquerait pas les pages du code malveillant comme exécutables. De même, s’il est possible de charger de force en mémoire un trustlet malveillant et de le lancer, il ne pourrait pas avoir accès au SKM ou aux autres trustlets sains sans remplir tous les prérequis inhérents aux trustlets.
Néanmoins, Virtual Secure Mode possède quelques faiblesses qui nécessitent une attention particulière, comme sa dépendance à Secure Boot, celui-ci permettant d’être sûr que le Boot Loader tourne sur un firmware sûr. L’implémentation du Secure Boot dépend des fabricants et il n’est pas rare de trouver des bugs ou vulnérabilités dans le design. Autre cas, la sécurité basée sur la virtualisation peut être activée sans Secure Boot ! Ces deux situations pourraient mettre en péril la sécurité du système : un attaquant pourrait ainsi développer son propre hyperviseur. Une fois le VSM compromis, un attaquant pourrait injecter un malware en tant que trustlet et accéder au SKM pour atteindre les secrets isolés. De plus, SKM ne possède pas de liste en dur des identifiants de trustlets valides, ni même de leur empreinte. Il convient aussi de savoir que HVCI ne vérifie pas sa propre intégrité. Enfin, pour l’instant, la robustesse de RPC n’a pas été mise-à-mal publiquement, mais il est clair que les communications entre le monde normal et le monde sécurisé pourraient être des cibles d’attaques de choix.
À moins d’une vulnérabilité dans l’hyperviseur ou le matériel, les contraintes matérielles et logicielles adoptées semblent permettre de protéger le système, l’exécution de n’importe quel type de code non signé paraît ainsi difficile. Il est, par contre, nécessaire, pour une sécurité du plus haut niveau, d’être doté de tous les prérequis matériel et de les activer ; la présence de vulnérabilités ou l’absence d’au moins l’un d’eux peut devenir un vecteur d’attaque intéressant pour un attaquant.
Le prochain article portera sur Device Guard. À bientôt !

Sources :
Alex Ionescu (2015), Battle of SKM and IUM, BlackHat 2015
Baris Saydag, Seth Moore (2015), Defeating Pass-the-Hash, BlackHat 2015
Microsoft

Abderahmane HABAIEB 

Aucun commentaire:

Enregistrer un commentaire