CVE-2020-3433 : élévation de privilèges sur le client VPN Cisco AnyConnect

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Spécialité(s)


Résumé

Cet article explique comment trois vulnérabilités supplémentaires ont été découvertes dans le client VPN Cisco AnyConnect pour Windows. Elles ont été trouvées suite au développement d’un exploit pour la CVE-2020-3153 (une élévation de privilèges, étudiée dans MISC n°111). Après un rappel du fonctionnement de ce logiciel, nous étudierons chacune de ces nouvelles vulnérabilités.


Body

Début mai 2020, trois vulnérabilités impactant le client VPN Cisco AnyConnect pour Windows ont été identifiées par l’auteur de cet article. Ces failles ont été découvertes lors de l’étude de la CVE-2020-3153 qui a déjà fait l’objet d’un article dans MISC n°111 [1].

Les détails techniques de ces vulnérabilités ont été immédiatement communiqués à Cisco (« responsible disclosure »), et après trois mois de patience, elles ont été publiées sur le site de l’éditeur : il s’agit d’une élévation de privilèges (CVE-2020-3433) [2], d’un déni de service (CVE-2020-3434) [3] et d’une vulnérabilité permettant la modification des profils VPN (CVE-2020-3435) [4].

Nous commencerons par rappeler le fonctionnement d’AnyConnect, avant de décrire chacune des failles découvertes, en mettant particulièrement l’accent sur l’élévation de privilèges.

1. Rappel du fonctionnement d’AnyConnect

Dans l’article de MISC n°111, nous avions présenté les composants clés d’AnyConnect, les interactions de ces composants les uns avec les autres, ainsi que le mécanisme de mise à jour intégré à ce logiciel (auto-update). Nous allons synthétiser les éléments importants ici, mais le lecteur intéressé pourra se reporter à la première section du précédent article comme introduction à celui-ci.

Plusieurs composants de la suite AnyConnect pour Windows (dont l’interface graphique, vpnui.exe) interagissent avec un agent central (vpnagent.exe) en utilisant un mécanisme de communication interprocessus réseau (Inter-Process Communication, ou IPC). Cet agent est exécuté comme un service avec le compte local LocalSystem.

Les messages IPC utilisent une structure Type-Longueur-Valeur (Type-Length-Value ou TLV) et sont envoyés à l’agent sur le port TCP/62522 (loopback). Ils ne sont pas chiffrés et le protocole ne dispose d’aucune forme d’authentification. Ainsi, n’importe quel utilisateur local (non-privilégié) peut communiquer avec l’agent via ce protocole (à condition de respecter le format de ces messages).

Parmi les nombreux composants de ce logiciel, vpndownloader.exe va particulièrement nous intéresser dans toute la suite de cet article. Cet exécutable est responsable du téléchargement et de l’installation de mises à jour lorsque le mécanisme d’auto-update est utilisé.

Lorsque AnyConnect est mis à jour en utilisant son mécanisme intégré, la nouvelle version de vpndownloader.exe est téléchargée depuis la passerelle VPN ; cet exécutable est démarré puis il télécharge l’installateur de la nouvelle version d’AnyConnect. Après cela, l’agent copie puis démarre une nouvelle instance de vpndownloader.exe (en tant que NT AUTHORITY SYSTEM) qui se charge d’installer la mise à jour. Ces étapes sont résumées dans le diagramme de la Figure 1.

autoupdate-s

Fig. 1 : Étapes d’une « auto-update ».

De nombreuses vulnérabilités ont impacté vpndownloader.exe ces dernières années (dont la CVE-2020-3153). De ce fait, plusieurs contrôles ont été implémentés :

  • l’exécutable de la nouvelle version d’AnyConnect est téléchargé dans un dossier aléatoire de l’utilisateur courant (situé dans C:\Users\username\AppData\Local\Temp\Cisco\), puis est copié dans un autre dossier aléatoire (situé dans C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\). Ces dossiers sont supprimés lors du processus de mise à jour ;
  • les binaires sont signés (Cisco Systems, Inc), et leur signature est vérifiée avant leur exécution ;
  • 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é.

Par ailleurs, nous avions vu dans le précédent article que vpndownloader.exe (comme certains autres programmes de la suite AnyConnect) est affecté par une vulnérabilité de DLL hijacking : ce programme recherche une DLL, nommée dbghelp.dll, qui est manquante par défaut.

Nous allons désormais nous intéresser aux trois vulnérabilités découvertes début mai 2020.

2. Élévation de privilèges (CVE-2020-3433)

2.1 Description de la vulnérabilité

La description de la vulnérabilité du bulletin de sécurité publié par Cisco [2] peut se synthétiser de la manière suivante : une vulnérabilité dans le mécanisme IPC d’AnyConnect pour Windows permet à un attaquant authentifié de réaliser un DLL hijacking. Elle provient d’une validation insuffisante des ressources chargées par l'application au moment de l'exécution. Un attaquant authentifié pourrait l’exploiter en envoyant un message IPC spécialement conçu afin d’élever ses privilèges.

L’éditeur a attribué un score CVSS 7.8 (« high ») à cette vulnérabilité. Celle-ci a été corrigée avec la version 4.9.00086 d’AnyConnect, publiée mi-juin 2020 (soit environ un mois et demi avant la publication du bulletin de sécurité).

2.2 Dernier rappel sur le mécanisme de mise à jour intégré

Dans la première section de cet article, nous avons évoqué les grandes étapes d’une mise à jour en utilisant le mécanisme d’auto-update (davantage détaillées dans MISC 111 [1]), mais revenons un instant sur une des étapes de ce processus (étape 5 du diagramme de la Figure 1).

Peu de temps avant le début de l’installation de la nouvelle version d’AnyConnect, le composant de téléchargement/installation, vpndownloader.exe, est démarré (par l’agent) en tant que NT AUTHORITY\SYSTEM avec comme argument : "CAC-re-launch C:\Users\ATGO\AppData\Local\Temp\Cisco\25869.tmp\anyconnect-[...].exe -".

Cette commande a été capturée lors d’une mise à jour automatique d’AnyConnect 4.5.02036 vers la version 4.6.03049. Cet argument provoque la copie du fichier anyconnect-[...].exe (par vpndownloader) vers un dossier temporaire d’AnyConnect, puis son exécution.

Dans le précédent article, nous avions mentionné que d’autres commandes « CAC » sont utilisables pour ce composant en plus de CAC-re-launch : CAC-move, CAC-vcredist-install, et CAC-nc-install. Lors de nos tests, CAC-nc-install était plus stable. Nous allons donc continuer de l’utiliser (en réalité, CAC-re-launch cause un déni de service, mais nous verrons cela plus loin).

Maintenant, nous allons porter notre attention sur le tiret placé après le chemin vers anyconnect-[...].exe.

2.3 Trouver une élévation de privilèges

Nous savons qu’AnyConnect vérifie les signatures des exécutables passés en paramètre à vpndownloader, du moins le premier paramètre passé en argument après la commande « CAC ».

Nous voulons voir si le tiret peut être remplacé par un nom de fichier. Nous modifions donc notre exploit pour la CVE-2020-3153 afin d’envoyer la commande suivante dans un message IPC :

"CAC-nc-install -ipc=1337 C:\Windows\System32\cmd.exe C:\Windows\System32\calc.exe".

Depuis les versions 4.7.x d’AnyConnect, un paramètre -ipc=xxx (avec xxx un nombre quelconque) est nécessaire comme argument pour les commandes CAC, mais il n’est pas supporté sur les versions plus anciennes.

En parallèle de l’envoi de ce message IPC, nous suivons les évènements dans Process Monitor de Windows Sysinternals. Nous remarquons alors que les deux fichiers (cmd.exe et calc.exe) ont été copiés dans le même dossier C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Installer\<xxx>.tmp\ avant d'être supprimés.

Ce comportement est déjà intéressant : cela prouve que la commande « CAC » envoyée dans notre message IPC était un argument valide pour vpndownloader, et donc que le tiret peut être remplacé par un nom de fichier !

Ensuite, nous regardons les journaux d’évènements Windows, et nous voyons que la vérification de la signature de cmd.exe a échoué. Cette erreur était attendue, car AnyConnect vérifie la signature des exécutables lors de son processus d’auto-update (les binaires doivent avoir une signature valide de Cisco Systems, Inc pour être exécutés). Cependant, aucune mention de calc.exe n’apparaît dans les logs !

Nous modifions donc notre message IPC précédent pour remplacer le premier chemin vers un binaire de Cisco :

"CAC-nc-install -ipc=1337 C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\vpndownloader.exe C:\Windows\System32\calc.exe".

Dans Process Monitor, nous observons le même comportement que lors de notre dernier test : les deux fichiers sont copiés dans le même dossier temporaire. Cette fois, la copie de vpndownloader.exe démarre en tant que NT AUTHORITY SYSTEM (comportement attendu).

Dans les logs Windows, nous trouvons un message nous indiquant que la vérification de la signature de vpndownloader.exe est réussie, mais toujours pas la moindre mention de calc.exe.

Nous nous inspirons de l’approche de DLL « planting » déjà utilisée pour la CVE-2020-3153 (avec cette même DLL dbghelp) pour notre troisième essai. En effet, lors de nos différentes expérimentations avec Process Monitor, nous avions noté que vpndownloader cherche une DLL nommée dbghelp.dll (dans le répertoire depuis lequel le programme est démarré).

Nous faisons donc un troisième essai avec cette fois le chemin vers notre DLL « malveillante » :

"CAC-nc-install -ipc=1337 C:\[...]\vpndownloader.exe C:\chemin\vers\dbghelp.dll".

Une invite de commande privilégiée (NT AUTHORITY\SYSTEM) apparaît alors dans notre session utilisateur : le code de la DLL a été exécuté !

Lorsque nous exécutons notre exploit, les étapes suivantes se déroulent :

  1. L’exploit envoie un message IPC (non sollicité) à destination de vpnagent.exe qui contient la commande « CAC » suivante : "CAC-nc-install -ipc=1337 C:\[...]\vpndownloader.exe C:\chemin\vers\dbghelp.dll" (le paramètre -ipc doit être enlevé pour les versions plus anciennes d’AnyConnect).
  2. vpnagent.exe copie vpndownloader.exe depuis C:\Program Files (x86)\Cisco\[...]\vpndownloader.exe vers C:\ProgramData\Cisco\[...]\Temp\Downloader\vpndownloader.exe.
  3. Cette copie de vpndownloader.exe est démarrée (par l’agent) en tant que NT AUTHORITY\SYSTEM avec comme argument, la commande « CAC » envoyée par l’exploit.
  4. Cette instance de vpndownloader.exe copie vpndownloader.exe et dbghelp.dll vers C:\ProgramData\Cisco\[...]\Temp\Installer\<xxx>.tmp\.
  5. Le programme vpndownloader.exe est exécuté (car signé Cisco Systems, Inc) depuis le dossier <xxx>.tmp en tant que NT AUTHORITY\SYSTEM et charge dbghelp.dll (DLL « planting »).
  6. Le code de la DLL est exécuté (en tant que NT AUTHORITY\SYSTEM).

Ces étapes sont synthétisées dans le diagramme de séquence de la Figure 2.

exploit cve-2020-3433-s

Fig. 2 : Exploitation de la vulnérabilité CVE-2020-3434.

3. Déni de service (CVE-2020-3434)

Lors du développement de l’exploit pour la CVE-2020-3153, nous avions cru constater un « crash » de l’agent AnyConnect en utilisant CAC-re-launch. Comme expliqué ci-après, ce n’était pas un crash, mais un arrêt de l’agent.

Lors d’une mise à jour automatique, l’ancienne version de vpnagent.exe s’arrête, puis l’installation de la nouvelle version du logiciel s’installe, puis le nouvel agent démarre.

Ces étapes sont réalisées avec la commande passée en paramètre de vpndownloader que nous avons vue précédemment : "CAC-re-launch C:\Users\ATGO\AppData\[..]\anyconnect-[...].exe -".

Si nous envoyons un message IPC en remplaçant le chemin précédent par un autre binaire signé par Cisco (vpndownloader.exe par exemple), alors l’agent s’arrête, le binaire fourni démarre, mais le service de l’agent ne redémarre pas. Windows ne cherche pas à redémarrer ce service, car il a été arrêté correctement. À nouveau, le paramètre -ipc=xxx est nécessaire depuis les versions 4.7.x.

Ce problème a été communiqué à Cisco et a été assimilé à un déni de service dans leur bulletin de sécurité avec un score CVSS de 5.5 (« medium ») [3]. Ce déni de service semble être corrigé avec la version 4.9.01095.

4. Modification de profil VPN (CVE-2020-3435)

AnyConnect gère des profils VPN sous forme de fichiers XML. Un profil contient les réglages nécessaires à l’établissement de la connexion VPN (adresse, port, etc.), mais aussi, éventuellement, quelques options avancées (autoriser ou non les portails captifs, forcer l’utilisation du VPN si le réseau n’est pas de confiance, etc.).

Cisco fournit quelques recommandations de réglages Windows pour durcir la configuration dans sa documentation, et en particulier celle de s’assurer qu’un utilisateur ne peut pas modifier les profils VPN situés dans C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\ (par défaut, un utilisateur non privilégié ne peut pas écrire dans ce dossier).

Si aucun profil n’est pré-déployé localement ou si le profil a été mis à jour sur la passerelle, alors le composant de téléchargement d’AnyConnect (encore et toujours vpndownloader.exe) se charge de récupérer et d’installer ce profil.

À l’aide de Process Monitor et Wireshark, nous remarquons un comportement semblable à une mise à jour automatique : le profil est téléchargé depuis la passerelle ASA à l’aide d’un processus vpndownloader.exe (non privilégié) vers un dossier temporaire de l’utilisateur, puis une instance privilégiée de ce programme est démarrée (par l’agent) pour copier le profil vers le dossier Profile.

Comme précédemment, nous retrouvons une commande « CAC » dans un message IPC à destination de l’agent, qui est ensuite passée comme paramètre à l’instance privilégiée de vpndownloader.exe :

"CAC-move C:\Users\ATGO\AppData\Local\Temp\Cisco\3427.tmp\vpnprofile.xml C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\vpnprofile.xml A78FAA0602241A35A012F17F1045F2D2453DF553 sha1 0".

Nous comprenons que les deux premiers paramètres de cette commande sont le chemin vers le profil téléchargé puis sa destination. Le paramètre sha1 nous laisse supposer que A78FAA0602241A35A012F17F1045F2D2453DF553 correspond à l’empreinte SHA-1 du profil XML.

Nous vérifions cette hypothèse :

PS C:\Users\ATGO> Get-FileHash -Algorithm SHA1 'C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\vpnprofile.xml' | Select Hash
 
Hash
----
A78FAA0602241A35A012F17F1045F2D2453DF553

Pour l’exploitation, nous créons un nouveau profil XML (dans le but de contourner d’éventuelles restrictions), puis nous envoyons la commande suivante dans un message IPC :

"CAC-move -ipc=1337 C:\chemin\vers\monprofil.xml C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\vpnprofile.xml 61E343E5A9FF4317538B040135F261EBEFB94F93 sha1 0".

avec 61E343E5A9FF4317538B040135F261EBEFB94F93, l’empreinte SHA1 de notre nouveau profil (monprofil.xml).

Une fois cette commande envoyée, nous observons que le contenu de vpnprofile.xml a été remplacé par celui de notre nouveau profil.

Cette vulnérabilité a été également communiquée à l’éditeur qui lui a attribué, à nouveau, un score CVSS de 5.5 (« medium ») [4]. Au moment de la rédaction de cet article, cette vulnérabilité n’a pas été corrigée dans la dernière version d’AnyConnect pour Windows disponible (4.9.01095).

Conclusion

Nous avons vu qu’il était possible de trouver de nouvelles vulnérabilités en s’appuyant sur les résultats d’autres chercheurs en sécurité. Nous n’avons pas eu besoin de compétences particulières en rétro-ingénierie, nous avons utilisé uniquement Process Monitor, Wireshark et les journaux d’évènements Windows pour détecter ces vulnérabilités et un peu de C# pour développer les exploits correspondants (disponibles sur GitHub [5]).

La première vulnérabilité étudiée dans cet article pourra être utilisée lors d’un test d’intrusion pour élever nos privilèges sur une machine que nous aurons compromise au préalable. Les deux autres pourront servir à contourner le VPN, en particulier sur des configurations « durcies », et ainsi exfiltrer des données, attaquer le poste depuis le réseau local, etc.

Comme le télétravail risque de continuer encore quelque temps pour certains d’entre nous, les différents clients VPN des entreprises ne seront peut-être pas mis à jour dans l’immédiat.

La découverte de ces vulnérabilités a été une expérience enrichissante à plusieurs points de vue, en particulier la partie responsible disclosure : les communications avec l’équipe PSIRT (Product Security Incident Response Team) étaient rapides (en général moins d’un jour ouvrable), directes et simples.

La politique de divulgation de vulnérabilités de Cisco stipule que les bulletins de sécurité pour une vulnérabilité notée « medium » sont publiés dès qu’un correctif est publié ou sous 90 jours au maximum. Pour les vulnérabilités « high », les vulnérabilités sont publiées uniquement après correction. En fin de compte, les trois vulnérabilités ont été publiées sous 90 jours, mais l’élévation de privilèges a été corrigée en moins d’un mois et demi.

Pour finir, la surface d’attaque d’AnyConnect étant large (et avec des mécanismes IPC non sécurisés), le lecteur intéressé pourra probablement trouver de nouveaux problèmes de sécurité dans ce produit.

Le lecteur intéressé pourra retrouver le code de mes exploits sur GitHub [5].

Remerciements

Merci à mes collègues Maxime Clementz et Ouadie Lachkar pour leur support pendant ces trois mois d’attentes et pour la relecture de cet article. Merci également à Christophe et René pour leur relecture attentive. Enfin, merci à tous mes collègues pour leur soutien.

Références

[1] A. Goichot, « CVE-2020-3153 : élever ses privilèges grâce au télétravail », MISC n°111, septembre-octobre 2020 : https://connect.ed-diamond.com/MISC/MISC-111/CVE-2020-3153-elever-ses-privileges-grace-au-teletravail

[2] Bulletin de sécurité Cisco pour la CVE-2020-3433 : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-anyconnect-dll-F26WwJW

[3] Bulletin de sécurité Cisco pour la CVE-2020-3434 : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-anyconnect-dos-feXq4tAV

[4] Bulletin de sécurité Cisco pour la CVE-2020-3435 : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-anyconnect-profile-7u3PERKF

[5] Dépôt GitHub de l’auteur : https://github.com/goichot/CVE-2020-3433



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous