Nous profitons du recent article de The Information qui décrit la volonté d’Apple de construire ses propres serveurs en raison d’une crise de paranoïa, pour partager avec vous une video découverte récemment traitant de Virtual Machine Introspection, une fonctionnalité de l’API Memory Inspection de l’Hyperviseur Xen (utilisé par Amazon pour AWS par exemple…).

Cette vidéo est présentée par Tamas K Lengyel, chercheur en sécurité et développeur actif sur les projets Xen Project Hypervisor, LibVMI et DRAKVUF (Dynamic Malware Analysis system). La description faites sur la home du site de ce dernier est particulièrement flipante :

DRAKVUF is an agentless dynamic malware analysis system built on Xen, LibVMI, Volatility and Rekall. It allows for in-depth execution tracing of malware samples and extracting deleted files from memory, all without having to install any special software within the virtual machine used for analysis.

Un peu avant la 3eme minute de la présentation, vous aller voir Tamas lancer la calculatrice de Windows 7 dans une VM, depuis l’hyperviseur, en “hijackant” la mémoire du GuestOS à l’aide de l’API VMI de Xen. Si si.

Ce projet est loin d’être recent puisqu’il date de 2011 et a bien été amélioré depuis :

In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added.

On vous laisse méditer sur les fonctions clefs du projets pendant que votre DSI se félicite d’avoir migré tout son système d’information sur Azure…

• Agentless start of malware execution.
• Agentless monitoring of Windows internal kernel functions.
• Guest multi-vCPU support.
• Tracing heap allocations.
• Tracing files being accessed.
• Extracting files from memory before they are deleted.
• Cloning of analysis VMs via copy-on-write memory and disk.

Ce que nous encourageons, par contre, c’est la modification du logo de boot parce que c’est bien fun :

Ces failles permettraient un memory leak du host au guest (interceptions de données provenant de la zone mémoire d’autres VM ?) et pire encore : exécuter du code sur le host via un guest (via le support Direct3D, actif par défaut sur ESX(i) 4.0).

Les seules “protections” possible seraient :

• Patcher
• Ne pas installer les pilotes graphiques des vmtools (!)
• Désactiver le driver SVGA (sous Windows)
• Désactiver le support 3D (pour les vmx en v7)

Cette faille à été corrigée par VMware avant la version GA (build 140815) d’ESX(i) 4.0 et patchée sur tous les autres produits encore supportés. Les version non patchées restes bien évidement vulnérables.