Vulnérabilité dans Zoom Chat

CVE-2021-30480 [Score CVSS v3.1: 8, 8]
Une vulnérabilité a été découverte dans Zoom Chat sur les systèmes d’exploitation Microsoft Windows et macOS. Cette vulnérabilité vise précisément le logiciel Zoom Chat et non les composantes chat de Zoom Meetings et Zoom Video Webinars. Ci-dessous, quelques détails techniques concernant l’exploitation de la vulnérabilité (pour une explication exhaustive, voir le lien en référence).

Afin de réaliser l’exploitation, des chercheurs ont acheté des comptes premium pour avoir un accès complet aux différentes fonctions de Zoom. La suite explique dans les grandes lignes comment ils ont réussi à trouver la faille Zoom Chat.

L’une des premières étapes a été d’analyser les communications de Zoom. Différentes combinaisons ont été testées avec des proxies, des DNS modifiés et des certificats CA installés dans Windows. Il en ressort que Zoom utilise de nombreuses requêtes HTTP, mais le Chat utilise une connexion XMPP. La mise en place d’interception au niveau des XMPP a permis la suite de l’analyse.

Une partie de désassemblage, « reverse », a été réalisée avec les DLL présents pour Zoom. L’objectif était de trouver des zones faibles ou exploitables dans les différentes DLL.

Cette recherche a permis de trouver une vulnérabilité au niveau de la mémoire. La fonction vient d’une des DLL d’OpenSSL de Zoom avec la partie EVP_DecodeBlock. Lors de la gestion du décodage en base64, l’initialisation de la taille permet d’avoir une fuite possible. Le calcul de la taille à allouer n’est pas correct et permet de mettre du code forgé.

Zoom Chat supporte une configuration nommée « Advanced Chat Encryption » (pour les utilisateurs payants). Deux versions sont disponibles : la V2 est utilisée, la V1 est utilisée à la demande de l’usager. 

Le processus de V1 est le suivant : le message envoyé par un utilisateur est chiffré via une clé symétrique, avec un identifiant-clé pour préciser le message-clé utilisé. La configuration relative à la réception du message vérifie si celle-ci a la clé symétrique via l’identifiant-clé. Si la configuration ne trouve pas cette clé, un message de requête (RequestKey) avec un récipient X509 pour le chiffrement de la clé est envoyé à l’émetteur. L’émetteur répond à cette requête (ResponseKey) en envoyant le certificat X509, et un élément XML contenant le message-clé chiffré, ainsi qu’une signature.

Dans le cas où la clé est chiffrée par une clé RSA, le résultat du déchiffrement RSA tient dans la mémoire car celui-ci ne dépasse pas 1024 bits. Aucun débordement constaté.

Dans le cas où un processus de chiffrement utilise Elliptic Curve Diffie-Helman, le message-clé est chiffré avec AES. En renvoyant un message (ResponseKey) contenant des données dépassant 1024 bits et chiffrées en AES, cela provoque un débordement de tas pendant le déchiffrement. Dans ce cas, le résultat du déchiffrement dépasse 1024 bits.

La faille étant découverte, l’objectif a été de pouvoir l’exploiter. Pour développer une exploitation du bug trouvé, il faut d’abord comprendre les avantages et désavantages du débordement de tampon trouvé (non exhaustif):

- Avantage : la taille n’est pas directement limitée (implicitement par la taille maximum d’un paquet XMPP, mais en pratique c’est déjà largement suffisant).

- Désavantage : La taille doit être un multiple de la taille des blocks AES, c'est-à-dire 16 bits. Il peut y avoir du rembourrage à la fin, mais même si ce rembourrage est présent il écrasera les données jusqu’au bloc complet avant de se voir retiré.

Diverses recherches ont été effectuées au niveau de Windows 10 pour compromettre les allocateurs de tas (NT-Heap et Segment-Heap). Pour la partie NT-Heap, il existe deux allocateurs : LFH (Low Fragment Heap) et Back-End-Allocator. Les tests n’ont pas permis une exploitation à 100% mais des résultats probants à 25%. Pour une exploitation de vulnérabilité, ce n’était pas assez.

Le faible taux de réussite des méthodes précédentes a permis aux chercheurs de repartir sur les fondamentaux. Existe-t-il une DLL vulnérable qui n’a pas toutes les mesures de sécurité en place ?

A cette réponse, il est ressorti 2 DLL d’OpenSSL qui n’ont pas le CFG (Control Flow Guard) d’activé. Pour réussir une exploitation à 100% avec ces DLL, ils auront trouvé des solutions pour passer l’ASLR (Address Space Layout Randomization) et le DEP (Data Exécution Prevention) afin de faire un dépassement de tampon et d’utiliser une ROP (Return-Oriented Programming) Chain pour lancer le code malveillant ou choisi.

L’attaquant à partir d’un serveur qu’il maîtrise peut :

• Initialiser une requêtes HTTPS avec 1087 bytes
• Attendre la connexion TLS complète
• Mettre en place le dépassement de tampon immédiatement après pour écraser l’entête et intégrer les dépassements dans l’entête suivant
• Attendre la connexion TLS complète
• Récupérer les informations de la requête

A partir de ce moment, tout est en place pour réussir une exécution de code arbitraire. L’exemple a été fait avec une image GIF de quelques méga. Celle-ci permet l’utilisation d’une ROP Chain dans les adresses de libcrypto-1_1.dll.

Actuellement, l’exploitation a un taux estimé de réussite de 50% en 5 minutes et peut être optimisée jusqu’à 75%.