Cet article explique comment développer un exploit pour la CVE-2020-3153, une élévation de privilèges à l’aide d’un « path traversal » dans le client Cisco AnyConnect pour Windows (avant la version 4.8.02042). Après une brève présentation de ce produit et de son fonctionnement, nous étudierons cette vulnérabilité et verrons comment elle peut être exploitée.
En avril 2020, les détails techniques d’une vulnérabilité (CVE-2020-3153) dans un des composants du client Cisco AnyConnect pour Windows ont été publiés [1]. Son exploitation permet à un attaquant authentifié sur Windows d’élever ses privilèges.
Dans cet article, nous commencerons par examiner comment les différents composants d’AnyConnect interagissent entre eux, puis nous décrirons succinctement la vulnérabilité étudiée avant de détailler son exploitation.
1. Présentation du fonctionnement d’AnyConnect
1.1 Généralités
Le client AnyConnect pour Windows est composé de nombreux exécutables et DLL dont :
- vpnagent.exe, l’agent central de la solution réalisant la majorité des actions. Il est exécuté comme un service en tant que LocalSystem ;
- vpnui.exe, l’interface graphique d’AnyConnect. Ce programme est exécuté avec le compte de l’utilisateur courant.
L’interface graphique d’AnyConnect et d’autres composants de la solution (en particulier, celui de téléchargement/installation – vpndownloader.exe) communiquent avec l’agent à l’aide d’un mécanisme de communication interprocessus (Inter-Process Communication, ou IPC) réseau sur le port TCP/62522 (interface de loopback uniquement). Ce port est ouvert par l’agent.
Le client utilise un ou plusieurs profils VPN sous forme de fichiers XML. Ces profils contiennent les réglages pour l’établissement du tunnel (adresse, port, etc.) ainsi que d’éventuelles conditions, comme par exemple, la connexion automatique au VPN si la machine n’est pas sur un réseau de confiance.
1.2 Mécanisme d’auto-update
Le client AnyConnect peut être mis à jour de plusieurs manières sur un parc Windows, par exemple en utilisant une solution centralisée comme SCCM, mais également via une fonctionnalité de mise à jour intégrée (auto-update).
Quand cette fonctionnalité est activée et lorsque le client se connecte au serveur VPN (Cisco ASA), le composant de téléchargement d’AnyConnect (vpndownloader.exe) va vérifier si une mise à jour du client est disponible et si de nouveaux profils doivent être récupérés. Le cas échéant, le composant va télécharger les mises à jour (du logiciel et/ou des profils), puis les installer avant d’établir le tunnel VPN. Cette fonctionnalité est activée (ou peut être désactivée) dans les profils VPN.
Nous avons analysé le déroulement d’une mise à jour automatique avec Wireshark pour capturer les différents messages échangés via le réseau, et en utilisant Process Monitor, de Windows Sysinternals, pour surveiller en temps réel les activités liées à cette mise à jour (processus, registre, etc.). Par ailleurs, les journaux d’évènements Windows peuvent être utiles puisque AnyConnect produit des logs assez détaillés.
Avant de continuer, précisons que notre analyse concerne une mise à jour automatique d’AnyConnect de la version 4.5.02036 à la version 4.6.03049. Certaines observations pourraient être différentes avec d’autres versions.
La capture de la Figure 1 montre l’un des nombreux messages envoyés via le protocole IPC (ici de l’interface graphique vers l’agent).
Sans connaître le protocole utilisé, nous notons que les messages ne sont pas chiffrés et nous observons de nombreux chemins locaux et noms de fichiers. Dans cette capture d’écran, comme dans le reste de cet article, l’utilisateur (non privilégié) courant est ATGO.
En parallèle, de nombreux évènements sont capturés par Process Monitor.
Résumons les grandes étapes de notre mise à jour automatique :
- vpndownloader.exe est téléchargé depuis la passerelle ASA vers C:\Users\ATGO\AppData\Local\Temp\D378.tmp\vpndownloader.exe. Cette étape est effectuée par vpnui.exe, en tant qu’utilisateur courant (ATGO ici).
- vpndownloader est démarré en tant qu’utilisateur courant avec la commande suivante : "C:\Users\ATGO\AppData\Local\Temp\D378.tmp\vpndownloader.exe" "-ipc gc".
- anyconnect-win-4.6.03049-[...].exe est téléchargé, par vpndownloader, depuis la passerelle ASA, vers C:\Users\ATGO\AppData\Local\Temp\Cisco\25869.tmp\anyconnect-4.6.03049-[...].exe. On peut déjà noter que les chemins vers vpndownloader.exe (étape 2) et vers anyconnect-4.6.03049-[...].exe sont identiques avec ceux de notre capture Wireshark (Figure 1).
- vpnagent.exe, exécuté en tant que service, avec des droits privilégiés, copie C:\Users\ATGO\AppData\Local\Temp\D378.tmp\vpndownloader.exe vers C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Downloader\vpndownloader.exe.
- Cette copie de vpndownloader est démarrée (par l’agent) en tant que NT AUTHORITY\SYSTEM avec la commande "C:\ProgramData\Cisco\[...]\Temp\Downloader\vpndownloader.exe" "CAC-re-launch C:\Users\ATGO\AppData\Local\Temp\Cisco\25869.tmp\anyconnect-[...].exe -".
- anyconnect-[..].exe est copié depuis le dossier temporaire précédent vers C:\ProgramData\Cisco\[...]\Temp\Installer\23342.tmp\.
Puis l’installation de la version 4.6.03049 d’AnyConnect commence. Cette nouvelle version démarre et le client se reconnecte au serveur VPN.
Les étapes 1 à 6 précédentes peuvent être synthétisées avec le diagramme de séquence de la Figure 2.
Avant de comprendre le protocole IPC, nous remarquons que tous les chemins listés dans les étapes précédentes apparaissent dans notre capture Wireshark, à l’exception de C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\[..].
De plus, il est important de noter que :
- les noms des dossiers en xxx.tmp sont aléatoires et sont supprimés lors du processus de mise à jour ;
- les signatures des exécutables sont vérifiées, puis si elles sont valides (Cisco Systems, Inc), les binaires sont démarrés ;
- les fichiers et sous-dossiers dans C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ ne peuvent pas être modifiés par un utilisateur non privilégié.
1.3 Le protocole IPC d’AnyConnect
Le composant vpndownloader a été affecté par des vulnérabilités ces dernières années et le protocole IPC d’AnyConnect a déjà été étudié.
Le lecteur intéressé par les détails de ce protocole est invité à lire les articles de SerializingMe [2] [3]. Nous nous contenterons ici de fournir les éléments clés de ce protocole ainsi que la traduction de notre capture Wireshark (Figure 1).
Ce protocole n’est pas chiffré et ne dispose d’aucune forme d’authentification. Ainsi, n’importe quel utilisateur local (non-privilégié) peut communiquer avec l’agent via des messages IPC (à condition de respecter le format de ces messages).
Ce protocole utilise une structure Type-Longueur-Valeur (Type-Length-Value ou TLV) envoyée sur le port TCP/62522 (loopback).
La capture Wireshark de la Figure 1 peut se traduire de la manière suivante. Les caractères hexadécimaux de certaines valeurs ont été supprimés, mais ont été décodés sous forme de commentaires pour des raisons de lisibilité.
Nous comprenons qu’il faudra changer les champs mis en évidence dans ce paquet si nous voulons communiquer avec l’agent à l’aide ce protocole.
1.4 Les commandes CAC
Dans la valeur de l’index 2, nous pouvons reconnaître l’argument qui est passé à vpndownloader à l’étape 5 de la mise à jour automatique (section 1.2). En réalisant une rétro-ingénierie rapide de ce composant, nous listons plusieurs commandes CAC en plus de CAC-re-launch : CAC-move, CAC-vcredist-install, et CAC-nc-install.
Après plusieurs essais, nous remarquons que la commande CAC-nc-install semble être plus stable que CAC-re-launch. Nous utiliserons donc CAC-nc-install dans la suite de cet article.
Par ailleurs, un paramètre -ipc=xxx (avec xxx un nombre quelconque) est nécessaire comme argument pour les commandes CAC des versions 4.7.x et 4.8.x, mais il n’est pas supporté sur les versions plus anciennes.
2. Description de la vulnérabilité CVE-2020-3153
La description du bulletin de Cisco pour cette vulnérabilité [4] peut se résumer de la manière suivante : une vulnérabilité dans le composant d'installation du client AnyConnect pour Windows pourrait permettre à un attaquant authentifié de copier des fichiers arbitraires dans des répertoires système, avec des droits privilégiés. Cette vulnérabilité demeure dans la manière dont ce composant traite les noms des fichiers. Cette vulnérabilité pourrait permettre à un attaquant (authentifié) d’élever ses privilèges.
L’auteur original de la découverte [1] propose deux scénarios d’exploitation. Nous n’étudierons pas la première approche puisqu’elle repose sur le hijacking d’une DLL qui n’est pas liée à AnyConnect.
Le second scénario consiste à exploiter un path traversal pour copier un binaire signé par Cisco, vulnérable à un DLL hijacking. Puisque ce programme est signé, il va être exécuté (par vpndownloader), et le code de notre DLL sera exécuté également (avec des privilèges élevés).
3. Exploitation via DLL hijacking
3.1 Path traversal
Dans son article [1], l’auteur explique que le path traversal peut être exploité quand un exécutable est copié dans le dossier temporaire d’AnyConnect.
Ce problème vient de la façon dont vpndownloader traite le nom du fichier à partir du chemin complet. Il cherche la dernière occurrence du caractère « backslash » (\). La partie suivant ce caractère est traitée comme le nom de fichier et est utilisée comme nom de destination, alors que l’API de Windows accepte aussi le « slash » (/) comme séparateur.
Ainsi, il est possible de forcer vpndownloader à créer des fichiers en dehors du dossier temporaire d’AnyConnect.
Pour rappel, le chemin vers le dossier temporaire d’AnyConnect n’apparaît pas dans le message IPC envoyé à l’agent (section 1.2).
En conséquence, nous comprenons que le problème réside dans la façon dont vpndownloader.exe traite la commande suivante : "CAC-re-launch C:\Users\ATGO\[...]\Temp\Cisco\[...]\anyconnect-[...].exe -".
Nous testons l’envoi d’un message IPC avec le chemin vers anyconnect-[...].exe remplacé par : C:\myOwnPath\nope\nope\nope\nope\../../../../anyconnect.exe.
En traçant les évènements avec Process Monitor, nous voyons que le fichier anyconnect.exe (qui est préalablement placé dans C:\myOwnPath\anyconnect.exe) est copié vers C:\ProgramData\Cisco\ au lieu de C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Installer\xxxxx.tmp\.
Ainsi, vpndownloader a considéré que le nom de notre fichier est ../../../../anyconnect.exe. D’où le path traversal de quatre niveaux.
À ce stade, nous pouvons écrire un fichier à un emplacement arbitraire puisque cette opération est effectuée par un processus privilégié. De plus, si le fichier copié est un binaire signé par Cisco, il va être exécuté en tant que NT AUTHORITY\SYSTEM. Nous allons voir dans la section suivante comment tirer parti de ce comportement pour élever nos privilèges.
3.2 Élévation de privilèges
L’auteur original propose d’utiliser cstub.exe, un binaire signé par Cisco faisant partie de la suite AnyConnect, qui est affecté par une vulnérabilité de DLL hijacking (recherche non sécurisée d’une DLL manquante, nommée dbghelp.dll). Pour rappel, Windows cherche les DLL d’un programme en commençant par le répertoire depuis lequel ce programme est chargé. L’idée est donc d’exploiter le problème de path traversal pour déplacer ce binaire à un endroit où nous avons préalablement placé notre DLL malveillante.
Cependant, Process Monitor montre que vpndownloader recherche également dbghelp.dll, et permet d’exploiter la vulnérabilité sans dépendre de cstub.exe qui n’est pas toujours présent (selon la configuration du client VPN).
Voici ce qui se passe quand notre exploit est exécuté :
- L’exploit place une DLL malveillante dans C:\ProgramData\Cisco\dbghelp.dll. Pour rappel, un utilisateur standard n'a pas accès en écriture dans C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ et ses sous-dossiers (mais il peut écrire dans C:\ProgramData\Cisco\).
- L’exploit envoie un message IPC (non-sollicité) à destination de vpnagent.exe qui contient une commande CAC-nc-install avec l’argument : "C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\nope\nope\nope\nope\../../../../vpndownloader.exe -" (index 2 du paquet en section 1.3).
- vpnagent.exe copie vpndownloader.exe depuis C:\Program Files (x86)\Cisco\[...]\vpndownloader.exe (ce chemin est indiqué dans notre message IPC à l’index 6) vers C:\ProgramData\Cisco\[...]\Temp\Downloader\vpndownloader.exe.
- C:\ProgramData\Cisco\[...]\Temp\Downloader\vpndownloader.exe est démarré (par l’agent) en tant que NT AUTHORITY\SYSTEM avec comme argument, la commande CAC-nc-install envoyée par l’exploit.
- C:\ProgramData\Cisco\[...]\Temp\Downloader\vpndownloader.exe copie C:\Program Files (x86)\Cisco\[..]\vpndownloader.exe vers C:\ProgramData\Cisco\vpndownloader.exe. Notre path traversal permet de copier le fichier quatre niveaux plus hauts que lors du déroulement normal !
- C:\ProgramData\Cisco\vpndownloader.exe est exécuté (car signé Cisco Systems, Inc) en tant que NT AUTHORITY\SYSTEM et charge notre dbghelp.dll (DLL hijacking).
- Le code dans la DLL est exécuté (NT AUTHORITY\SYSTEM) : dans notre cas, une invite de commande privilégiée apparaît dans la session de l’utilisateur courant.
Les étapes 1 à 6 peuvent être synthétisées avec le diagramme de séquence de la Figure 3.
Conclusion
Nous avons vu comment, à partir d’un article technique (mais incomplet) et de quelques outils communs, il était possible de comprendre les étapes nécessaires, mais suffisantes, pour développer un exploit fonctionnel pour un produit de sécurité fréquemment utilisé en entreprise. En particulier, nous n’avons pas eu besoin de compétences pointues en rétro-ingénierie.
Cette vulnérabilité pourra très certainement être utile lors de tests d’intrusion internes ou lors de missions de Red Team, afin d’élever ses privilèges rapidement sur le poste de travail d’une cible. De plus, certaines organisations n’ont probablement pas pris le risque de mettre à jour ce logiciel par crainte d’une interruption de service, en particulier avec la nécessité du télétravail lors de la dernière crise sanitaire.
Pour faciliter l’exploitation, un module Metasploit a été développé par l’équipe de Rapid7 fin juin 2020. Ce module implémente le scénario de DLL hijacking détaillé ici, et s’appuie aussi sur notre idée d’utiliser vpndownloader au lieu de cstub. Pour terminer, le lecteur intéressé pourra retrouver le code de mon exploit sur GitHub [5].
Remerciements
Merci à mes collègues Maxime Clementz et Ouadie Lachkar de m’avoir encouragé à rédiger cet article et pour leur relecture. Merci également à Christophe et René pour leur relecture attentive. Enfin, merci à mes autres collègues pour leur support.
Références
[1] SSD Advisory, Cisco AnyConnect Privilege Elevation through Path Traversal : https://ssd-disclosure.com/ssd-advisory-cisco-anyconnect-privilege-elevation-through-path-traversal/
[2] SerializingMe, AnyConnect Elevation of Privileges, Partie 1 : https://www.serializing.me/2016/12/14/anyconnect-elevation-of-privileges-part-1/
[3] SerializingMe, AnyConnect Elevation of Privileges, Partie 2 : https://www.serializing.me/2016/12/20/anyconnect-elevation-of-privileges-part-2/
[4] Bulletin de sécurité Cisco pour la CVE-2020-3153 : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ac-win-path-traverse-qO4HWBsj
[5] Dépôt GitHub de l’auteur de cet article pour la CVE-2020-3153 : https://github.com/goichot/CVE-2020-3153