 d'opérateur, j'utilisais des serveurs ESXY pour gérer la virtualisation et pas mal de personne. Il y a des processus qu'il faut vraiment réussir à isoler pour ne pas qu'il s'étend entre le hyper bizarre et l'environnement. Donc notre présentateur pour cette session va nous montrer l'exploit qu'il a découvert au dernier capture de flag en Chine. J'aimerais que vous accueillez F1 Y sur cette scène avec moi. Bonjour, merci pour l'introduction. Bonsoir à tous. Je suis F1, Y, F1, Y, Y, Y et je suis à Georgia Tech. Je vais vous montrer comment on peut sortir d'une machine virtuelle sandbox sur un serveur ESXY. Je vais vous partager mon expérience et le travail qu'on a fait avec CentOS sur ESXY. On vient de Chaitinko, du centre de recherche Chaitinko, à Pekin. On a fait pas mal de recherches sur l'IOT, les attaques, la recherche d'attaques IoT, Android et S4. On a une présence à la DevCon. On a plusieurs équipes qui ont eu des challenges à la DevCon et à la ITCon. Si vous êtes intéressé, vous invitez à participer à nos capture de flag à nos CTF. Avant de commencer notre aventure pour nous échapper d'une machine virtuelle, on va voir ce que veut dire s'échapper d'une machine virtuelle. Je vais demander, est-ce que certains d'entre vous, si vous avez utilisé un logiciel de virtualisation comme VMware, Workstation ou Hyper-V, virtual box, etc., levez vos mains. Ok, merci. On a beaucoup dans la salle. Si vous êtes un ingénieur logiciel ou dans la sécurité, vous avez probablement utilisé des logiciels de virtualisation. Mais si quelqu'un entend parler de s'échapper d'une machine virtuelle, qui a entendu ça, levez vos mains. Oh, je suis surpris. C'est vraiment beaucoup de gens. Ça me montre que beaucoup de gens sont au courant du sujet. Mais j'avais besoin d'introduire ça quand même. Donc, qu'est-ce que ça veut dire le virtual machine escape ? La plupart du temps, l'autre, le serveur, le système d'exploitation qui est sur Hypervisor, va émuler le hardware et présenter des ressources à notre guest, à notre OS guest. Et le système d'exploitation guest est isolé complètement du host. Mais si on a des bugs au niveau du host ou de l'hypervisor, c'est possible pour le guest de sortir de l'environnement virtualisé et d'exploiter les vulnérabilités et finalement exécuter du code directement sur le host, sur l'hypervisor. Donc, c'est ce qu'on appelle le virtual machine escape sur lequel j'ai travaillé. Donc, pourquoi est-ce qu'on a utilisé ESXY comme notre cible ? D'abord, c'est parce que c'est l'hypervisor que la plupart des entreprises utilisent pour créer leur cloud privé, donc pour mettre leur donnée privée, interne, incluant toutes ces sociétés, dont les logos sont listés ici, et vSphere, c'est un produit VMware donc c'est très répandu et très connu et ESXY c'est l'OS Hypervisor pour VMware vSphere. Donc, pourquoi on l'utilise dans le cloud privé ? C'est voilà la première raison pour laquelle je me suis penché là-dessus et la deuxième raison c'est qu'on utilise ça pour, on a eu beaucoup de vulnérabilités qui ont été démontrées dans VMware Workstation et comment sortir d'une machine virtuelle dans Workstation en utilisant les cartes graphiques, les ports internet, etc. Mais on n'a eu aucun escape démontré public sur ESXY et du coup c'était un challenge pour nous et on aime le challenge. C'est parce que je pense qu'il y a c'est peu de documents sur l'architecture. Alors la seule chose qu'on a trouvé c'est un whitepaper proposé par paper. Le whitepaper il a seulement quelques définitions. D'abord on va regarder l'architecture. Alors c'est un hypervisor bare metal de classe proprise de partie un noyau développé par VMware et l'autre partie le monde utilisateur. Le noyau c'est un système d'exploitation typosix avec un système en mémoire et les données constantes dans ce système ne sont pas persistantes et il gère aussi du matériel et le scaling des ressources. Il inclut aussi des drivers des VMM et les user space pour faire tourner les process sur l'OS VM kernel. C'est un process où l'on doit d'utiliser seulement une partie limitée de hock et des signaux. J'en accès à une partie de l'appli PSX. Les process utilisateurs du type STD, SSHD et etc. Ça c'est l'architecture du SXC. Je voudrais donner un exemple pour très comment ça fonctionne en pratique. Le processus VMX côté utilisateur parle avec VMM en disant des syscalls custom pas vraiment documentés et VMM va lancer l'environnement depuis l'OS virtualisé et donc il a des instructions sensibles. Le processus VMM l'émule aussi des matériels virtuels. C'est comme ça qu'une machine virtuelle marche dans un SXC. Comment on fait pour s'échapper de la mission virtuelle ? Si il y a une vulnérabilité dans le matériel virtuelle de VMX, on peut écrire un driver pour s'en échapper. Le driver veut parler au matériel virtuel et exploiter l'habit. Par exemple exécuter du shellcode dans le processus VMX. C'est ça qu'on arrive à sortir de machine virtuelle. La deuxième raison pour laquelle le SXC est si difficile, c'est l'API User World. VMX s'utilise plein d'appels systèmes non documentés, customisés. Réussir à écrire du code pour VMX c'est difficile parce qu'on ne sait pas quelle message l'utilise. Alors par chance on a réussi à trouver deux tables des syscalls après avoir décompressé le deux. Donc on a trouvé par exemple ces deux symboles pour être utiles si on veut reverser l'ingénieré un peu de code de VMX. Et il y a aussi des protections de sécurité, par exemple l'ASLR et du NX. Donc il est obligé de faire fuir un peu d'adresse, mémoire pour réussir à casser la randomisation de l'espace d'adresse. Et enfin il y a encore une autre protection qui me semble boxe, qui isole le processus VMX. Si par exemple on exécute du shell dans le processus VMX, en fait on ne peut pas exécuter de commande, on ne peut pas lire des champs sensibles à moins qu'on ait réussi à aussi sortir de la zone boxe. Alors on pense du coup que le VMX dans ESXY est une surface attack beaucoup plus faible. Par exemple si on compare Workstation ESXY, en fait on peut voir que pas mal de fonctionnalités étaient enlevées de VMX et mises dans le VM kernel. Par exemple la partie transmission de paquets de réseau qui était déplacée de VMX dans le noyau. On peut voir qu'il y a pas mal de vulnérabilité dans la partie transmission de paquets de cette carte virtuelle. Et c'est vulnérabilité, affecte uniquement le produit Workstation. Donc le VMX dans ESXY est une plus petite surface d'attaque. Maintenant, regardons comment on peut s'échapper de ESXY. Donc on va utiliser deux vulnérabilités VMX dans notre exploit. La première c'est un stack, une vulnérabilité de stack non utilisée. Et le deuxième est pour les stacks non utilisés en lecture. Donc on a les codes des vulnérabilités. Donc ce qu'on peut faire ici c'est qu'on peut faire du arbitrerie adresse free avec le premier et on peut avoir un leak d'information avec le second. Donc en combinant les deux, on peut faire de l'exécution de shellcode arbitraire dans le process VMX. Et finalement on utilise une vulnérabilité logique pour s'échapper du bac à sable, du sandbox de VMX et entrer à l'hyperaviseur ESXY. Donc regardons la première vulnérabilité. Donc c'est l'utilisation de stacks non initialisés. Donc on a ici, avec l'utilisation de filtre MAC, l'adresse MAC, on peut voir le mapping de la mémoire entre le guest et le host. Donc c'est aussi utilisé pour transporter des données entre le guest OS et le host. Donc on a l'initialisation du stack qui va utiliser un code pour exécuter la commande et recruter. Si on dirait qu'on n'a pas de problème sur l'exécution mais si on regarde la fonction, on voit que si on essaye d'exécuter ce code, on a un check qui se fait avant l'initialisation sur la pagination de la mémoire physique. Si le check passe, l'initialisation va se faire. Mais si le check ne échoue, il n'y aura jamais d'initialisation pour ce stack. Donc on a vu qu'on pouvait contrôler l'argument d'adresse en prenant un des registres de VMX. Donc ce qu'on voit dans cette fonction de release de mémoire physique, c'est que la fonction de retour nous montre uniquement l'initialisation. Donc si on peut... On peut écrire un champ arbitrage d'un structure de page et lui faire libérer un pointeur de notre structure de page physique. Donc il faut qu'on trouve une fonction pour écrire de données sur la pile. Alors quelque part, c'est un motif de développement standard. Donc on écrit sur la pile quand la variable est petite et sinon on passe sur le tas. Et donc on a trouvé une fonction qui a ce pattern. Donc cette fonction est utilisée quand l'OS se virtualise et j'aurai la structure TSB. Et donc il va utiliser si c'est petit la pile pour stocker la donnée et copier la donnée issue du système enfant sur la pile. Donc comment on combine tout ça pour faire un free de l'adresse arbitraire ? Donc pour ça on va dans l'OS guest, on utilise l'instruction outSB pour réussir à corrompre la pile de VMX. Et donc pour ça on va construire une structure de page physique. Et donc on lui met un nombre de pages de zéro et l'adresse qui est la fameuse adresse qu'on veut libérer. Et ensuite on utilise le réglage VMXnet3 qui était utilisé dans la fonction qui crée la page. Et ensuite on émet une commande VMXnet3 pour mettre à jour les filtres MAC. Et c'est à ce moment-là que dans VMX il va appeler la fonction feedMem release pour détruire la structure de page qu'on a remplie juste avant. Donc il va vérifier que pageCount est égal à zéro et dans ce cas-là il fait un free sur le champ pageArray qui est dans notre faux structure. Et donc avec ça on peut faire un free arbitraire en utilisant la pile utilisé. Alors l'autre vue navire arbitré c'est aussi dans la partie de cartes réseaux de VMX. Et donc c'est une structure, c'est une fonction qui permet de coalescer deux commandes. Donc pour ça il va lire une longueur du guest qui doit être 16 et ensuite il va initialiser les 8 premiers octets d'une structure sur la pile. Mais on voit qu'il a oublié d'initialiser l'autre champ de la structure. Et ensuite c'est réécrit dans la structure de l'OS guest. Et donc grâce à ça on arrive à extraire 8 octets non initialisés du process VMX. Et si on débug le process VMX on voit qu'il y a des offset fixes dans l'image. Et donc grâce à ça on peut obtenir toutes les informations sur l'espèce d'adressage par cette narrabilité. Donc qu'est-ce qu'on a maintenant ? D'un côté on peut faire un free sur l'adresse arbitraire grâce au premier exploit. Et grâce au deuxième on a toute l'information sur l'espèce d'adressage avec le deuxième exploit. Donc qu'est-ce qu'on veut faire ? Donc on veut exécuter du shellcode arbitraire dans le process VMX. Comment combiner ces deux vulnérabilités pour réussir à atteindre notre cible ? Alors en fait ce qui est pas facile c'est d'exécuter du shellcode arbitraire mais ce qu'on peut facilement faire c'est écrire à une adresse arbitraire. Donc d'abord comment on va réussir à écrire dans une adresse arbitraire en utilisant un free, une adresse arbitraire. Donc pour ça il nous faut une structure qui contient des pointeurs où on peut écrire et une taille. Et comme ça on pourra écraser ces structures et avec ça on pourra facilement écrire des adresses arbitraires. Donc pour essayer d'exploiter cette vulnérabilité il faut trouver une structure qui est dans le taille mais en fait on peut pas vraiment manipuler de manière stable la structure du taille. Parce que l'OS va assez souvent allouer libérer de la mémoire donc on peut pas vraiment travailler sur les structures du taille. Donc après en reversant un peu de code dans VMX on a trouvé une autre structure. Donc c'est un channel RPCI. Donc qu'est-ce que VMX RPCI ? Donc c'est un process qui permet de communiquer entre les guests et le host, c'est un mécanisme RPC. Et le deuxième terme avec lequel vous êtes peut-être familier c'est VMware Tools. C'est un outil que vous installez dans le guestOS qui a déjà installé ça dans son guestOS. Pas autant que tout à l'heure. Donc si vous utilisez VMware Workstation vous avez probablement installé VMware Tools. Dans votre guest, parce qu'une fois que vous l'installez vous pouvez utiliser des fonctionnalités qui sont très convainantes comme faire un copy-paste entre votre host et votre guest ou faire un drag and drop entre votre guest et votre host etc. VMware Tools implémente quelques commandes RPCI. Ici on a quelques exemples. On peut utiliser info set pour renseigner des informations sur notre guest. On peut faire info get pour récupérer les informations. Donc qu'est-ce qui se passe si on exécute ces commandes RPCI de notre guest ? Par exemple si on exécute ces commandes RPCI à l'intérieur de notre guest, en utilisant, on fait un set guest info 1, 2, 3. Donc notre guestOS retourne la commande à notre exécuteur RPCI au niveau du VMX et le handler va vérifier la source de l'exécution et ouvrir un canal et initialiser le call. Ensuite on va avoir un heap memory pour stocker les données de la commande. Ensuite il va utiliser une autre sous-commande qui s'appelle send data pour remplir les données de la memoire qui vient d'allouer. Et donc les données qu'on a envoyé du guest, à la taille, va être utilisées dans la commande Sennlenn et dans leur RPCI. Et donc enfin il va utiliser la sous-commande close pour détruire la structure channel, y compris la taille et le pointeur de données. Donc voilà c'est ce qui se passe quand on lance cette commande RPCI depuis le guest. Et en plus il y a aussi une structure de channel dans le segment de données qu'on peut utiliser. Donc ça c'est vraiment la structure parfaite pour notre exploit. Donc maintenant on a tout ce qu'il faut pour la structure qu'il faut pour les combiner. Alors on remarque aussi que vmx utilise pt malock de la gipc pour gérer son TA. Donc on choisit du coup d'utiliser l'attaque facebin. Alors qu'est-ce que c'est l'attaque facebin ? C'est une méthode pour exploiter les vulnérabilités de TA dans pt malock en utilisant la liste simplement chainée. Et donc cette méthode d'exploiter pt malock c'est en fait la première méthode que j'ai appris quand j'ai appris à faire des exploits. Alors maintenant quand on regarde le check qui est fait dans la gipc on a décidé de faire un free de l'adresse qui est reply index parce que en fait la gipc va traiter ça comme un faux chunk de mémoire. Donc d'abord il vérifie la taille courante du bloc de mémoire et on va choisir la taille du faux bloc mémoire pour être la taille de la structure channel. Et grâce à ça on va pouvoir chanter le check qui est fait dans vmx. Donc une fois qu'il y a le free qui est fait, le faux chunk va être mis dans la liste chainée facebin. Et donc on va réalouer le faux chunk avec la structure channel crochet n plus 2 et grâce à ça on pourra facilement écraser channel n plus 1 en mettant des données dans channel n plus 2. Et grâce à ça on va réussir à écraser des parties du channel n plus 1. Donc c'est facile de faire des écritures à des adresses arbitraires en construisant une fausse structure channel. Donc maintenant on se rappelle de notre cible. Notre cible c'est de faire de l'exécution du shellcode arbitraire dans vmx. Et pour l'instant on en est à l'écriture à une adresse arbitraire. Il y a plein de façons d'exécuter du shellcode arbitraire en faisant des écritures à des adresses arbitraires. On peut faire d'Europe par exemple. Donc par exemple on va écraser le segment got point plt. Donc par exemple si on écrase le pointeur de données du channel n plus 1 avec l'adresse du segment got plt. Donc on met un pointeur de fonction dans le got plt. Donc quand vmx utilise cette fonction qu'on écrase il va sauter sur notre gadget drop. Et donc grâce à ça on va pouvoir assez facilement faire de l'exécution de shell arbitraire en faisant de l'Europe. Et donc ça on va faire de l'exécution de code arbitraire dans vmx. Et donc là le process vmx va essayer d'exécuter une commande mais malheureusement ça marche pas. Donc on essaie de lire des chansons cibles comme tcpassword et ça va encore pas marcher. Et c'est là qu'on a réalisé qu'en fait il y avait une sandbox. Donc on ne peut pas exécuter toutes les commandes qu'on veut si on n'a pas aussi sorti de la sandbox. Donc la prochaine partie j'aimerais vous montrer comment on analyse et comment on s'échappe de la sandbox. Donc après avoir réalisé qu'on avait une sandbox dans eua6i on a regardé le code au niveau du vm kernel et on a trouvé un module qui s'appelle Access Control Subsystem. Et ce module implémente les checks pour les syscalls et c'est une sandbox qui est basée sur des règles. Donc on a cherché la configuration, les checks de configuration et ils sont dans ETC, VMware, Secpolicy, Domains. Et on a plusieurs domaines, plusieurs des règles qui sont dans différents domaines de notre sandbox. Une des règles qu'on a pu lire, on a vu, on a pu en déduire que le dossier var run est le seul dossier sur lequel on a des autorisations en lecture et en écriture. Donc on a plein de fichiers de configuration et des PID. Et le seul fichier de configuration qu'on peut écrire et lire, c'est le fichier inaidé.conf. Qu'est-ce qu'inaidé ? C'est Open Source et c'est un super serveur de domaines qui donne accès à des services internet. Donc on a regardé ce fichier inaidé.conf sur un serveur SXY. Et donc on voit qu'on a les autorisations de services SSH et OD pour l'authentification. Et on voit pour la partie d'authentification, on a réalisé que les services sont toujours énaiblés, sont toujours activés, même si les services SSH sont désactivés. Donc qu'est-ce qu'il se passe si on remplace la partie de configuration pour l'authentification ? De cette manière on pourrait rediriger l'authentification pour autoriser, on pourrait bypasser les règles et pouvoir lancer des processus. On a donc analysé les systèmes call et on a fait un kill sur le process inaidé et une fois que le process inaidé redémarrait, on peut exécuter n'importe quel commande dans le pod qu'il est décontrôle. Donc c'est comme ça qu'on a réussi à sortir de notre sandbox et maintenant je vais vous montrer une démo. Alors, je ne peux pas jouer la vidéo mais vous pouvez la trouver sur Youtube. On a écris cette démo après le DevCon et donc ça a été après avoir réussi à lancer l'exploit sur notre OES guest. Bon, voilà, c'est tout. Si vous voulez plus de détails sur notre chaîne d'exploit, vous pouvez trouver notre page là. Alors, si vous avez des questions, on a des micros, vous venez au micro, vous faites la queue derrière et on prendra vos questions. En attendant, il y a un signal angel. Est-ce qu'il y a des questions ? Pas de question de l'audience, micro n°6. Alors, est-ce que vous avez parlé à VMware pour ce petit yac ? On a réporté la vulnérabilité à VMware après en 2018 et ils ont mis un an à fixer une des deux vulnérabilités. Merci pour la belle présentation. Je voudrais juste savoir s'il y avait des choses importantes qu'un admin-système peut faire pour verrouiller la sandbox un petit peu plus, pour faire des mesures préventives sur les systèmes USXI ou est-ce qu'il n'y a rien à faire ? Est-ce que vous pouvez répéter la question ? C'était un peu trop rapide pour moi. Est-ce que vous pouvez faire quelque chose en tant qu'administrateur pour renforcer encore plus la sécurité autour de l'environnement de sandbox ? Oui, on peut désactiver l'environnement de sandbox en ligne de commande sur les serveurs USXI. Je ne vous ai pas mis la commande dans cette présentation, mais j'ai trouvé la commande dans la documentation. On peut la trouver en recherchant la documentation USXI. Je l'ai trouvé en utilisant une commande en ligne de commande USXI, et c'est pas documenté par VMWare, je l'ai trouvé moi-même. Je vais partager cette commande sur mon Twitter plus tard. Désolé, j'ai oublié de la mettre dans la présentation. Mais est-ce que ça aurait pu prévenir de cette attaque ? En faisant ce changement avec cette commande, est-ce que ça pourrait prévenir de l'attaque que tu viens de montrer ? Le sandbox est là pour protéger les procès VMX. Donc, si tu mets à jour ton USXI, ça va protéger. On a une question d'Internet. Alors, cet exploit, est-ce qu'il marche sur des VM qui n'ont pas PDX en utilisant la traduction de binaire ? C'est-à-dire, est-ce que c'est plus universel que juste... Est-ce que vous pouvez répéter la question ? Alors, est-ce que ça marche aussi sur les choses non AMD ou les machines VDX qui font de la traduction de binaire ? Alors oui, parce que toutes ces vulnérabilités existent dans le hardware virtuel. Donc il suffit d'utiliser de la virtualisation, on utilise tous de la virtualisation dans les machines virtuels. Donc oui, d'autres questions d'Internet ? Non, c'est tout, merci. Est-ce que tout le monde peut m'aider et remercier F1YYY pour cette super obsession ?