Voyage au cœur des nouvelles défenses de Windows 10 Enterprise

Les boucliers de Windows 10

D’une manière générale, Windows 10 apporte de nombreux atouts en matière de sécurité. On retiendra plus particulièrement :

• Un nouvel antimalware Windows Defender (déjà dans Windows 8)
• La technologie de reputation Smartscreen (déjà dans Windows 8, pour sites et fichiers téléchargés)
• Le navigateur EDGE sandboxé
• La nouvelle implémentation de Secure Boot avec drivers signés
• La fonction Virtual TPM (pour sécuriser les machines virtuelles)
• L’intégration de la biométrie dans la couche de Login : Windows Hello
• La fonction anti fuite de données EDP
• La technologie de détection de tentative de hijacking des programmes : Control Flow Guard
• La technologie de protection des identifiants Windows : Credential Guard
• La technologie de verrouillage avancé du PC : Device Guard (Protected Processes + AppLocker)

Virtual Secure Machine

Les deux dernières technologies « Guard » listées ci-dessus dépendent intrinsèquement d’une innovation majeure du noyau de Windows et de son hyperviseur Hyper-V, innovation connue sous le nom de Virtual Secure Mode (VSM). Nous avons déjà eu l’occasion d’expliquer comment Microsoft avait implémenté le concept de micro-virtualisation avec Windows 10, un concept notamment démocratisé par des start-ups comme Bromium. Mais bien plus qu’implémenter de la micro-virtualisation, Microsoft a en réalité profondément modifié l’architecture sous-jacente de Windows 10.

Virtual Secure Mode s’appuie sur l’hyperviseur Hyper-V pour créer un environnement sécurisé dans lequel s’exécuteront des processus clés de Windows comme LSA (Local Security Authority), les routines de chiffrement ou celles de contrôle de l’intégrité des services. Ces processus se retrouvent ainsi isolés de l’environnement Windows principal. La compromission de ce dernier ne peut dès lors affecter ni l’exécution ni les données de ces processus.

Aucun code tiers ne peut s’exécuter dans la partition VSM et son intégrité est sans cesse contrôlée pour détecter toute modification. Comme nous allons le voir plus loin, les données protégées par VSM restent intouchables même si le noyau de Windows est compromis car même ce dernier ne peut y accéder directement.

Comment ça marche ?

Dans Windows 10, Hyper-V associe à chaque processeur virtuel un niveau de confiance (Virtual Trust Level, VTL) qui peut prendre deux valeurs : VTL0 pour le monde normal, et VTL1 pour le monde sécurisé.

Lorsque VSM est activé, Hyper-V crée une partition en VTL1 dotée d’un micro-noyau sécurisé désigné sous le nom de SKM (Secure Kernel Mode) s’exécutant en Ring 0 (avec le niveau VTL1) et d’un environnement d’exécution de processus de confiance - les Trustlets -, environnement désigné sous le nom de IUM (Isolated User Mode) et qui s’exécute en Ring 3.Windows et son noyau traditionnel (NTOS) sont quant à eux montés dans une autre partition en VTL0.

On notera au passage que SKM intègre ses propres pilotes signés ainsi que des services essentiels comme SKCI (Intégrité de code), CNG (Services de chiffrement & cryptographie).

Dans cet univers virtualisé par Hyper-V, les VTL sont prioritaires sur les « Ring » du processeur virtuel.
Il en résulte deux conséquences essentielles en matière de sécurité :

1. SKM utilise l’hyperviseur pour intercepter l’exécution du vrai noyau NT. C’est possible parce que le Ring 0/VTL0 du vrai noyau a une priorité inférieure au Secure-Kernel qui est en Ring 0/VTL1. Dès lors, certaines fonctionnalités clés du noyau Windows peuvent être déléguées au Secure-Kernel. Rien ne sert aux cyber-criminels d’intercepter les fonctionnalités clés d’un Windows compromis puisque celles-ci seront réalisées par SKM.
2. Les services et applications qui s’exécutent dans IUM (donc en User-Mode « Ring 3 ») peuvent manipuler des données et des droits que même le noyau de Windows ne peut pas modifier. Il suffit donc à Microsoft d’exécuter les services (qu’il soit Kernel-Mode ou User-Mode) les plus sensibles de Windows dans la partition VSM pour rendre inopérante toute compromission avancée du système, attaque de type « Pass-The-Hash », etc.

Certains diront qu’il suffit d‘infecter l’hyperviseur pour que cette belle mécanique perde de sa pertinence. C’est probablement vrai en théorie, mais nous rappellerons qu’en dix ans d’existence, seules deux vulnérabilités Hyper-V ont été découvertes (et bien sûr corrigées) et que la surface d’attaque de l’hyperviseur est vraiment très réduite tant il est compact. En outre, ces fonctionnalités présupposent l’utilisation du Secure Boot qui empêche toute exécution préalable à l’hyperviseur.

En réalité, le meilleur moyen d’attaquer une telle configuration est probablement d’arriver à créer ses propres Trustlets et à les injecter dans la Secure Virtual Machine ; ce qui est loin d’être évident comme l’explique Alex Inoescu dans sa session lors du dernier Blackhat. Les Trustlets et tout l’environnement VSM n’ont en effet aucune interface utilisateur ni même d’accès réseau.

Credential Guard

Dans Windows 10, VSM est avant tout utilisé par une fonctionnalité dénommée « Credential Guard ». C’est d’ailleurs l’installation de celle-ci qui déclenche la mise en place de la nouvelle architecture Windows s’appuyant sur VSM.

Credential Guard utilise VSM pour protéger les identifiants Windows liés à un Active Directory (la fonctionnalité n’est en effet effective que sur les comptes des domaines NT pas sur les comptes locaux). Avec Credential Guard, les tokens de sécurité et les hash dérivés des identifiants issus d’Active Directory sont confinés dans la VSM et les services d’authentification (lsass.exe) sont exécutés dans la VSM.

L’objectif est de protéger le système et les identifiants contre l’une des techniques d’attaque les plus réputées : le « Pass-The-Hash ». Dans cette forme d’attaque, les hackers n’ont pas besoin de connaître le mot de passe pour s’authentifier mais simplement de découvrir le « Hash » (ce qui est enfantin sous Windows puisqu’il est mis en cache sur le poste) pour accéder aux ressources de l’entreprise.

S’il paraît difficile de protéger toutes les machines de l’entreprise avec Credential Guard, activer la fonction sur les machines nomades et celles les plus sensibles hausse considérablement le niveau de sécurité du réseau Windows.

Device Guard

Device Guard est un nouveau bouclier dans l’arsenal de défense de Windows. Device Guard est en réalité un ensemble de technologies qui permettent de protéger Windows contre l’exécution de logiciels malveillants. VSM est utilisé de sorte à isoler les services de Windows contre les malwares et les protéger des attaques Zero Days. En effet, parce que VSM exécute aussi bien des services « User Mode » que « Kernel Mode », les services essentiels du système se retrouvent protégés malgré les vulnérabilités inconnues qu’ils contiennent.

Device Guard permet à l’entreprise de signer tous les pilotes et tous les programmes qu’elle utilise et d’interdire toute exécution de codes non signés par l’entreprise. Typiquement, appliquée aux distributeurs et autres systèmes de Points de Vente, la technologie Device Guard aurait évité les diverses brèches rencontrées par Target et diverses banques.

Microsoft pense que Device Guard est actuellement la meilleure façon d’éliminer de façon certaine la menace « malware » des PC Windows, à condition bien évidemment d’être sûr de la personne en charge de la signature des applications au sein de l’entreprise.

Virtual TPM

Plus utiles sous Windows Server 2016 que sous Windows 10 (bien que celui-ci embarque Hyper-V et puisse donc exécuter des VM), les vTPM (Virtual TPM) permettent d’équiper chaque machine virtuelle d’un chip TPM virtuel pour protéger les clés et autres informations essentielles. Les vTPM sont elles aussi implémentées via le Virtual Secure Mode. VSM est utilisé par les VM comme un circuit TPM. On notera au passage que les fonctionnalités Credential Guard et Device Guard ne semblent pas, pour l’instant, pouvoir être activées sur des VMs.

Attention aux pré-requis et limitations

La mise en œuvre de VSM et des protections qui y sont liées (Credential Guard, vTPM, Device Guard) n’est pas possible sur toutes les machines. Elle présuppose un certain nombre de prérequis technique, comme :

• La machine doit être équipée de Windows 10 64-bit version ENTREPRISE ou ETUDIANT.
• La machine et son utilisateur doivent être liés à un Active Directory.
• La machine doit disposer d’un boot UEFI 2.3.1 ou supérieur.
• La fonctionnalité Secure Boot doit être activée.
• Le processeur doit être 64 bit.
• Le processeur doit supporter les technologies de virtualisation matérielles Intel-VTx ou AMD-V.
• Le processeur doit intégrer la gestion de mémoire virtualisée VT-d ou AMD-Vi I/O.
• La machine doit être équipée d’une puce TPM 2.0.

En réalité, Credential Guard peut être activée sans support TPM ni support d’Intel VT-d. Mais son efficacité est alors compromise puisque les clés utilisées pour le chiffrement de Credential Guard ne sont pas protégées par le hardware et l’absence de DMA rend l’isolation mémoire moins efficace.

Comment activer VSM et Credential Guard sous Windows 10

Pour activer ces fonctionnalités, vous devez utiliser un PC supportant les contraintes évoquées plus haut et dont les options UEFI et Secure Boot ont été activées (préalablement à l’installation de Windows 10). De même, il est impératif que la machine soit liée à un domaine puisque Credential Guard ne protège que l’authentification Active Directory.

Il faut ensuite activer « Hyper-V » via le module «  Activer ou désactiver des fonctionnalités Windows » du panneau de configuration. La fonction « Credential Guard » s’active depuis l’éditeur de stratégie.
Une fois celle-ci activée, il reste une dernière opération : instruire au boot Windows 10 de lancer VSM ; ce qui se fait par l’intermédiaire de la commande « bcdedit /set vsmlaunchtype auto ».

Autres ressources :
* https://channel9.msdn.com/Blogs/Seth-Juarez/Windows-10-Virtual-Secure-Mode-with-David-Hepkin
* http://blogs.msdn.com/b/virtual_pc_guy/archive/2015/10/26/using-a-hypervisor-to-secure-your-desktop-credential-guard-in-windows-10.aspx