VM escape … oui, mais encore ?
Le groupe chinois Qihoo 360, coutumier des exploits (bien préparés) dans les concours de sécurité, à touché 105.000 dollars pour un triple exploit… chapeau !
Le scénario: un poste de travail virtualisé innocent visite un site internet au contenu malveillant (en javascript).
En trois coups, l’équipe de Qihoo à réussi à traverser les mécanismes d’isolement du navigateur, du système d’exploitation et à remonter jusqu’à l’hyperviseur.
Pourtant, tout avait l’air OK et ressemble à ce qui se fait couramment en entreprise, avec toutes les garanties apportées par les éditeurs sur la robustesse des produits…
Les mesures mises en place
√ Contre les sites internet malveillants ou possédés : bac à sable et navigateur moderne
√ Contre les menaces: des solutions professionnelles et un système d’exploitation récent
√ Pour optimiser les ressources / réduire les coûts / aller dans le cloud : virtualisation
Les failles exploitées
⊗ Bac à sable (Edge) : KO via un débordement de la pile
⊗ Système d’exploitation (Windows 10) : KO via une faille noyau (UAF)
⊗ Virtualisation (VMWare) : KO via une faille exploitant un buffer non initialisé
Donc, quand un internaute se promène sur un site malveillant, la ballade peut se terminer par une prise de contrôle de l’hyperviseur, puis de là potentiellement le cœur de l’infrastructure (les autres VM de cet hyperviseur et comme par exemple la VM firewall).
Cette démonstration de force, ou plutôt d’habileté à mettre en déroute la sécurité de toute la pile d’un datacenter virtuel, rappelle que tout est piratable…
Inévitable, alors que faire ?
Pour éviter l’effet domino et une telle escalade, dans la mesure du possible il faut résister à la facilité, à la tentation de suivre la mode du tout virtualisé (y compris le réseau, la sécurité).
Les principes type KISS et de la séparation des fonctions ne sont pas incompatibles avec une infrastructure moderne et économique (cher ≠ meilleur), du moins pour le moment. Car les efforts des constructeurs-éditeurs pour du « software defined » (SDN, SDS, SDDC) conduiront bien à terme à l’effacement des limites.
Le problème de fond étant la maturité de l’offre -qui ne sera par définition jamais atteinte- et donc l’empilage des couches logicielles qui rendent possible un triple exploit comme celui ci.
Il reste donc les bonnes pratiques, déjà connues mais toujours valides. L’état de l’art et le bon sens lors de la conception de solutions, ensuite les tests, mises à jour, contrôles et corrections. Pour tout cela, il faut du temps, des compétences des ressources.
Comment ont ils fait ? Mes serveurs sont ils en risque ? Que faire pour éviter que ça se reproduise, est-ce vraiment inévitable…? Et si finalement la vraie question était : quels moyens accordez vous réellement à la sécurité ?
Mathieu Lubrano / Blog 