D'une vulnérabilité à une autre : une analyse de correctifs Outlook révèle une faille importante dans l'API Windows
Contributions éditoriales et additionnelles de Tricia Howard
Synthèse
Ben Barnea, chercheur chez Akamai, a découvert une nouvelle vulnérabilité importante dans le composant Internet Explorer, dénommée CVE-2023-29324, avec un score de base CVSS de 6,5.
En raison de cette vulnérabilité, une fonction de l'API Windows, MapUrlToZone, pense à tort qu'un chemin distant est un chemin local.
La fonction MapUrlToZone est couramment utilisée comme mesure de sécurité. En particulier, elle a été utilisée pour atténuer la vulnérabilité Outlook critique CVE-2023-23397 corrigée dans le Patch Tuesday de mars.
Un attaquant non authentifié sur Internet pourrait utiliser cette vulnérabilité pour forcer un client Outlook à se connecter à un serveur contrôlé par un attaquant, entraînant alors le vol d'informations d'identification NTLM. Il s'agit d'une vulnérabilité de type Zero Click, ce qui signifie qu'elle peut être déclenchée sans aucune action de la part de l'utilisateur.
Toutes les versions de Windows sont affectées par cette vulnérabilité. Par conséquent, toutes les versions du client Outlook sous Windows sont exploitables. Cependant, selon Microsoft, les serveurs Exchange ayant fait l'objet de la mise à jour de mars ne comprennent pas la fonctionnalité vulnérable, empêchant ainsi l'exploitation des clients vulnérables.
Le problème a été révélé de manière responsable à Microsoft et corrigé dans le Patch Tuesday de mars 2023.
Introduction
Parmi les vulnérabilités corrigées dans le cadre du Patch Tuesday de mars 2023 figurait une vulnérabilité Outlook critique dénommée CVE-2023-23397.
Cette vulnérabilité permet à un attaquant de forcer un client Outlook à se connecter au serveur de l'attaquant. Ce faisant, le client envoie des informations d'identification NTLM à la machine, ce qui permet à l'attaquant de craquer le mot de passe hors ligne ou de l'utiliser dans une attaque par relais. Cette vulnérabilité peut être exploitée à distance via Internet sans aucune action de la part de l'utilisateur (attaque de type Zero Click).
Comme l'a évalué Microsoft Threat Intelligence, un acteur malveillant russe a utilisé cette vulnérabilité dans des attaques ciblées contre plusieurs organisations au sien du gouvernement européen, mais aussi dans les secteur des transports, de l'énergie et de l'armée, pendant environ un an.
Dans le cadre de notre analyse du correctif, nous avons découvert un moyen de contourner le correctif de cette vulnérabilité critique. Dans ce billet de blog, nous discuterons de la vulnérabilité d'origine, de son correctif et de la façon de contourner ce dernier.
Vulnérabilité d'origine
La vulnérabilité Outlook corrigée en mars est déclenchée lorsqu'un attaquant envoie un e-mail contenant un rappel avec un son de notification personnalisé. Ce son personnalisé est spécifié par l'attaquant comme un chemin, à l'aide de la propriété MAPI étendue PidLidReminderFileParameter. Un attaquant peut spécifier un chemin UNC qui pourrait amener le client à récupérer le fichier son à partir de n'importe quel serveur SMB. Dans le cadre de la connexion au serveur SMB distant, le hachage Net-NTLMv2 est envoyé dans un message de négociation.
Pour résoudre le problème, le code invoque la fonction MapUrlToZone pour vérifier que le chemin ne fait pas référence à une URL Internet. Si c'est le cas, le son de rappel par défaut est utilisé au lieu du son personnalisé.
Contournement des mesures d'atténuation
Examinons d'abord le flux de code approprié dans Outlook. Deux fonctions importantes sont invoquées dans le cadre du chargement du fichier son personnalisé :
MapUrlToZone : renvoie la zone de l'URL et est utilisée pour déterminer si le chemin est local, intranet ou fiable (et non Internet)
CreateFile : ouvre un handle vers le fichier son
Remarque : la fonction SearchPath est également invoquée avant la fonction CreateFile, mais elle gère le chemin de manière similaire. Par conséquent, par souci de clarté, nous allons uniquement faire référence à la fonction CreateFile ici.
Pour trouver un contournement, nous devons trouver un chemin que la fonction MapUrlToZone considère comme local, intranet ou fiable, et que la fonction CreateFile traite également comme un domaine Internet.
Pour invoquer la fonction MapUrlToZone, nous pouvons utiliser le script PowerShell suivant qui invoque la fonction via le modèle d'objet de composant (COM).
Pour vérifier que la fonction MapUrlToZone est une mesure d'atténuation appropriée, nous pouvons la tester en l'invoquant sur le même chemin qui a déclenché la vulnérabilité, un chemin UNC absolu avec un domaine Internet. La fonction MapUrlToZone renvoie 3, indiquant que le chemin se trouve dans la zone Internet, comme prévu.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
Nous pouvons créer et modifier notre chemin UNC en utilisant un chemin de terminal local :
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Comme indiqué ci-dessus, la fonction MapUrlToZone identifie toujours le chemin comme une zone Internet, il serait donc tout de même bloqué, comme prévu par le correctif.
Cependant, en ajoutant un autre caractère « \ » après « UNC\ », la fonction MapUrlToZone renvoie alors 0, ce qui signifie un chemin local :
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
Ainsi, la fonction MapUrlToZone conclut que cette URL est locale. Maintenant, la question importante est la suivante : Quel sera le verdict de la fonction CreateFile pour cette URL ? Accédera-t-elle à un fichier local ou le téléchargera-t-elle via SMB ?
Roulements de tambour, s'il vous plaît …
Figure 1 : simulation d'une invocation de la fonction CreateFile avec le chemin UNC, menant à une demande DNS
Parfait ! Une demande DNS a été envoyée pour récupérer l'adresse IP de Akamai.com (figure 1). Il semble que nous ayons trouvé un chemin que la fonction MapUrlToZone considère comme local, mais pour lequel la fonction CreateFile envoie une demande sur Internet !
Maintenant, déclenchons la vulnérabilité Outlook d'origine, en contournant cette fois-ci la mesure d'atténuation supplémentaire.
Figure 2 : déclenchement de l'événement de calendrier, entraînant l'authentification NTLM sur un serveur distant
Comme vous pouvez le voir dans la figure 2, une fois que le rappel s'affiche, Outlook se connecte au serveur distant, ce qui entraîne l'authentification NTLM.
Selon Microsoft, les serveurs Exchange sur lesquels la mise à jour logicielle de mars est installée abandonneront la propriété PidLidReminderFileParameter, éliminant ainsi la fonction de fichier son personnalisé. Ainsi, seuls les ordinateurs exécutant des clients Outlook avec un serveur Exchange non corrigé sont vulnérables à ce problème.
Cause principale
Ce problème semble dû à la gestion complexe des chemins dans Windows.
La fonction MapUrlToZone invoque la fonction CreateUri qui convertit de manière incorrecte le chemin « \\.\UNC\\Akamai.com\file.wav » en « /.//UNC//Akamai.com/file.wav ».
Pour voir quel accès est déclenché par ce dernier chemin, nous pouvons utiliser le script ConvertDosPathToNtPath du billet de blogde James Forshaw.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
Nous pouvons maintenant voir que ce chemin pointe vers un répertoire nommé « UNC » sur le lecteur C: local. Il s'agit évidemment d'un répertoire local. La fonction MapUrlToZone renvoie donc 0.
Toutefois, la fonction CreateFile convertit d'abord le chemin d'origine depuis un chemin DOS vers un chemin NT en invoquant la fonction RtlpDosPathNameToRelativeNtPathName. Encore une fois, l'utilisation du script nous permet d'observer le résultat de cette conversion.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
Notez que cette fois, le résultat ne pointe pas vers un lecteur local. Alors, pourquoi une demande SMB est-elle déclenchée ? Comme le montre l'extrait ci-dessus, le chemin final est « '\??\UNC\Akamai.com\file.wav ». L'accès à ce chemin NT forcera le gestionnaire d'objets à acheminer la demande d'E/S vers le pilote MUP (Multiple UNC Provider). (En effet, l'entrée du répertoire d'objets global pour « UNC » est un lien symbolique vers « \Device\MUP ».) Étant donné que la fonction RtlpDosPathNameToRelativeNtPathName a supprimé ou réduit le caractère « \ » supplémentaire, le chemin ne contient désormais que le nom de domaine Internet.
Nous pensons que ce type de confusion peut potentiellement causer des vulnérabilités dans d'autres programmes qui utilisent la fonction MapUrlToZone sur un chemin contrôlé par l'utilisateur et qui utilisent ensuite une opération de fichier (comme CreateFile ou une API similaire) sur le même chemin. En outre, nous ne pouvons pas exclure d'autres problèmes survenant dans les programmes qui invoquent la fonction CreateUri.
Détection et prévention
Microsoft a publié des conseils complets sur la détection et l'atténuation de la vulnérabilité Outlook d'origine. D'après nos observations, toutes les méthodes spécifiées s'appliquent à la nouvelle vulnérabilité car elles ne dépendent pas de l'URL spécifiée dans la propriété PidLidReminderFileParameter .
Résumé
Cette vulnérabilité montre une nouvelle fois que tout examen des correctifs peut conduire à de nouvelles vulnérabilités et à de nouveaux contournements. Dans le cas de cette vulnérabilité, l'ajout d'un caractère permet de contourner un correctif critique.
Nous espérons que la fonction de son de rappel personnalisé sera entièrement supprimée, car elle présente plus de risques de sécurité qu'elle n'apporte de la valeur aux utilisateurs. Il s'agit d'une surface d'attaque d'analyse des supports de type Zero Click qui pourrait potentiellement contenir des vulnérabilités critiques de corruption de mémoire. Compte tenu de l'omniprésence de Windows, l'élimination d'une surface d'attaque aussi avancée que celle-ci pourrait avoir des effets très positifs.
Dans le cadre de nos efforts continus visant à protéger nos clients et la communauté, nous continuerons d'analyser les correctifs et autres systèmes afin de détecter toutes vulnérabilités. Pour vous tenir informé des recherches les plus récentes d'Akamai en matière de sécurité, suivez-nous sur Twitter.
Nous tenons à remercier Microsoft pour sa coopération et sa réactivité face à ce problème.
