CreateRCE — Encore une autre vulnérabilité dans CreateUri
Synthèse
Chercheur chez Akamai, Ben Barnea a découvert une vulnérabilité critique dans Microsoft Windows à laquelle a été attribué le code CVE-2023-35628.
Un attaquant sur Internet peut déclencher cette vulnérabilité contre les clients Outlook sans aucune interaction de l'utilisateur (Zero Click).
Cette vulnérabilité réside dans l'analyse d'un chemin par la fonction CreateUri. Nous connaissons actuellement deux façons de déclencher cette vulnérabilité : (1) en envoyant un courrier électronique sophistiqué à un client Outlook, ou (2) en incitant un utilisateur à naviguer dans l'Explorateur de fichiers jusqu'à un dossier contenant un fichier malveillant téléchargé.
Cette vulnérabilité a été révélée à Microsoft de manière responsable et a été corrigée dans cadre du Patch Tuesday de décembre 2023.
Les machines Windows sur lesquelles la mise à jour logicielle de décembre 2023 est installée sont protégées contre cette vulnérabilité. En outre, les clients Outlook qui utilisent des serveurs Exchange corrigés avec la mise à jour logicielle de mars 2023 sont protégés contre la fonctionnalité exploitée.
Introduction
L'omniprésence de Microsoft dans les entreprises et au-delà en fait une cible de choix (et lucrative) pour les attaquants. C'est pourquoi nous avons mené des recherches approfondies sur la suite de produits et de protocoles, en identifiant les vulnérabilités et en développant des outils qui facilitent leur détection et leur atténuation.
Dans le cadre de ces recherches, nous avons découvert une nouvelle vulnérabilité d'exécution de code à distance (RCE) dans la fonction WinAPI CreateUri qui est appelée dans le cadre du correctif de la vulnérabilité initiale CVE-2023-23397. Alors que la précédente chaîne de vulnérabilités RCE nécessitait d'enchaîner deux vulnérabilités pour obtenir une primitive RCE de type Zero Click, celle-ci peut le faire seule. En plus d'Outlook, nous vous indiquerons également comment déclencher la vulnérabilité dans l'Explorateur de fichiers.
La saga des vulnérabilités
Parmi les vulnérabilités abordées dans le cadre du Patch Tuesday de mars 2023, une vulnérabilité critique d'Outlook a été découverte par Microsoft (à laquelle a été attribué le code CVE-2023-23397). Elle était exploitée « in the wild » par un acteur malveillant commandité par l'État russe dénommé Forest Blizzard.
En décembre 2023, Microsoft et le Polish Cyber Command ont publié une déclaration dans laquelle ils affirment avoir constaté de récentes tentatives d'exploitation de la vulnérabilité par le même acteur malveillant. Cette vulnérabilité permettait à un attaquant de forcer un client Outlook à se connecter au serveur de l'attaquant. Dans le cadre de cette connexion, le client envoie ses informations d'identification NTLM à l'attaquant, qui peut ensuite les déchiffrer hors ligne ou les utiliser dans le cadre d'une attaque par relais. Cette vulnérabilité peut être exploitée à distance en passant par Internet sans aucune action de la part de l'utilisateur (attaque de type Zero Click).
Après la publication du correctif pour cette vulnérabilité, nous avons détecté deux contournements ainsi qu'une vulnérabilité d'analyse sonore. L'enchaînement des vulnérabilités de contournement et d'analyse pourrait conduire à une primitive RCE complète de type Zero Click sur le client Outlook.
MapUrlToZone
Dans le cadre du correctif de la vulnérabilité Outlook CVE-2023-23397, le code responsable du traitement d'un son de rappel personnalisé ajoute un appel à MapUrlToZone. L'appel vérifie que l'URL fournie, spécifiée par le biais de la propriété MAPI PidLidReminderFileParameterétendue, ne pointe pas vers une ressource Internet.
Bien que cela atténue la vulnérabilité initiale, cela ajoute une nouvelle surface d'attaque : la fonction MapUrlToZone ; nous contrôlons le chemin qui est transmis à la fonction MapUrlToZone.
Dans le cadre de l'analyse effectuée par MapUrlToZone,cette dernière appelle CreateUri. CreateUri crée un objet IUri représentant un URI (Uniform Resource identifier). Pour créer cet objet, la fonction sait analyser les deux URL et certains des chemins DOS Windows.
Lorsque CreateUri est appelée avec un chemin de fichier (par exemple, en utilisant le schéma file://ou un chemin Windows pointant vers un fichier/répertoire), la fonction CrackUrlFile est appelée. Il s'agit également de la fonction qui contenait contournements décrits dans le précédent billet de blog,.
La nouvelle vulnérabilité
Au début de CrackUrlFile, si cette fonction reçoit une URL plutôt qu'un chemin Windows, elle crée une copie de l'entrée, puis convertit la copie de l'URL en chemin Windows à l'aide de PathCreateFromUrlW. Le tampon de travail est marqué comme alloué dynamiquement, ce qui permet de le libérer ultérieurement. Si elle reçoit un chemin d'accès Windows, la fonction travaille directement sur le chemin d'accès d'entrée et n'a donc pas besoin de libérer le pointeur.
Pendant l'analyse du tampon de travail, le tampon peut être avancé ; par exemple, s'il s'agit d'un chemin de terminal local (commençant par « \\.\ » ou « \\?\ »), la fonction avance le pointeur de quatre caractères. Ensuite, si le nom du terminal est « UNC\ », elle l'avance de quatre caractères supplémentaires. En présence de plusieurs barres obliques inverses, la fonction fait également avancer la mémoire tampon au-delà des barres obliques inverses dupliquées.
Dans le cadre de l'inversion des correctifs apportés aux contournements, nous avons remarqué l'ajout d'un nouveau code dans CrackUrlFile en juillet 2023, qui ne semblait pas lié à nos contournements (Figure 1).
Figure 1 : Décompilation du code nouvellement ajouté
Dans le cadre de l'analyse du chemin, la fonction vérifie si le composant de chemin est un chemin de lecteur ou un chemin associé à une racine. Si c'est le cas, elle marque le chemin comme étant local. Le nouveau code remplace le pointeur de tampon d'origine par un pointeur sur le composant du chemin (le tampon avancé) si le chemin est celui d'un lecteur.
C'est l'origine du bogue : Le pointeur qui a été avancé est sauvegardé. Plus tard, le pointeur de la mémoire tampon d'origine (PPWorkingBuffer dans la Figure 1) est récupéré et libéré s'il a été alloué dynamiquement. Puisqu'il a été remplacé par le pointeur avancé, un appel à free() se produit avec un pointeur qui n'a pas été retourné par malloc. Cela donne à un attaquant une primitive pour fournir à l'allocateur de mémoire les métadonnées d'un bloc malveillant.
Pour déclencher la vulnérabilité, nous devons d'abord spécifier une URL de schéma de fichier, avec un chemin UNC. Ensuite, nous devons marquer le chemin comme un chemin de lecteur. Nous devons donc utiliser un partage (C:). Le chemin complet pour déclencher la vulnérabilité ressemblera à ceci :
file://./UNC/C:/Akamai.com/file.wav
Le code corrigé copie maintenant les octets du composant du chemin en utilisant RtlMoveMemory, au lieu de sauvegarder le pointeur.
Déclenchement en passant par l'Explorateur
Bien qu'il n'ait pas été possible de trouver de tels emplacements dans le cadre de nos recherches, nous avons fait une tentative rapide : le déclenchement en passant par l'Explorateur Windows.
Pour ce faire, nous avons créé un raccourci (fichier .lnk) pointant vers le chemin d'accès vulnérable. Une fois que la victime consulte le répertoire dans lequel se trouve le fichier raccourci, la vulnérabilité est déclenchée dans l'Explorateur, ce qui entraîne un plantage immédiat (Figure 2).
Pour vérifier si votre machine est vulnérable à ce problème, nous vous invitons à télécharger notre démonstration de faisabilité (PoC) qui fera planter l'Explorateur. (Lisez attentivement les spécificités et les risques relatifs au PoC dans notre référentiel de recherche sur la sécurité avant utilisation.)
Figure 2 : Plantage de l'Explorateur à la suite de la PoC
Résumé
Il s'agit de notre dernier article de blog concernant la recherche sur l'impact potentiel de la CVE-2023-23397.
En mai 2023, lorsque nous avons découvert le premier contournement, nous avons recommandé de supprimer la fonctionnalité exploitée puisque l'utilisation de MapUrlToZone ajoute une nouvelle surface d'attaque. Nous avons également mentionné que l'exposition d'une surface d'attaque d'analyse sonore à un attaquant distant en mode Zero Click, sans aucun bac à sable, présente plus de dangers que d'avantages pour les utilisateurs.
Dans nos recherches ultérieures, nous avons réussi à prouver exactement cette hypothèse en identifiant deux contournements, un problème d'analyse sonoreet, enfin, une corruption de la mémoire d'analyse du chemin d'accès de Windows.
Nous espérons que vous avez appris de nouvelles choses sur les chemins Windows, les codecs sonores et les différentes vulnérabilités grâce à ces articles. Nous encourageons les autres chercheurs à examiner les correctifs et à réfléchir à la manière dont ils peuvent être contournés. Nous ne pouvons pas exclure que d'autres contournements de MapUrlToZone existent.
Vous en voulez encore ?
Lisez nos précédents articles de blog sur ce sujet :