Parmi les vulnérabilités corrigées dans le cadre du Patch Tuesday de mars 2023 figure une vulnérabilité critique d’Outlook, désignée CVE-2023-23397.
Cette vulnérabilité permet de forcer un client Outlook à se connecter au serveur de l’attaquant.
De cette façon, 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 sur internet sans aucune interaction de l’utilisateur (zero-click).
Selon l’évaluation de Microsoft Threat Intelligence, un acteur russe a utilisé cette vulnérabilité dans des attaques ciblées contre plusieurs organisations des secteurs gouvernementaux, des transports, de l’énergie et de l’armée en Europe, depuis environ un an.
Dans le cadre de l’analyse du correctif (patch), Akamaï a découvert un moyen de contourner la correction de cette vulnérabilité critique.
Dans ce blog, nous aborderons de la vulnérabilité originale, du correctif et du contournement de ce correctif.
La vulnérabilité initiale
La vulnérabilité d’Outlook qui a été corrigée en mars est déclenchée lorsqu’un attaquant envoie un courriel contenant un rappel avec un son de notification personnalisé.
Ce son personnalisé est spécifié par l’attaquant sous la forme d’un chemin, en utilisant la propriété MAPI étendue PidLidReminderFileParameter.
Un cybercriminel peut spécifier un chemin d’accès UNC qui permettrait au client de 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 ce problème, le code appelle désormais MapUrlToZone pour vérifier que le chemin d’accès ne renvoie pas à une URL Internet.
Si c’est le cas, le son de rappel par défaut est utilisé à la place du son personnalisé.
Contourner les mesures d’atténuation
Examinons d’abord le flux de code correspondant dans Outlook.
Deux fonctions importantes sont appelées dans le cadre du chargement du fichier son personnalisé :
1.MapUrlToZone – Renvoie la zone de l’URL ; permet de déterminer si le chemin est local, intranet ou de confiance (et non Internet).
2.CreateFile – Ouvre une chemin vers le fichier son
Remarque : SearchPath est également appelé avant CreateFile, mais il gère le chemin d’accès de la même manière ; par conséquent, pour faciliter la compréhension, nous ne ferons référence ici qu’à CreateFile.
Pour trouver un contournement, nous devons trouver un chemin que MapUrlToZone considérerait comme local, intranet ou une zone de confiance et que CreateFile considérerait également comme un domaine internet.
Pour appeler MapUrlToZone, nous pouvons utiliser le script PowerShell suivant qui invoque la fonction par l’intermédiaire du Component Object Model (COM).
Pour vérifier que MapUrlToZone est une mesure d’atténuation appropriée, nous pouvons la tester en l’appelant sur le même chemin que celui qui a déclenché la vulnérabilité, un chemin UNC absolu avec un domaine internet.
MapUrlToZone renvoie 3, indiquant que le chemin est dans la zone internet, comme prévu.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
En étant astucieux nous pouvons modifier notre chemin d’accès UNC en utilisant un chemin d’accès au périphérique local :
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Comme nous l’avons vu ci-dessus, MapUrlToZone identifie toujours le chemin d’accès comme une zone internet, de sorte qu’il sera toujours bloqué, comme le prévoit le correctif.
Cependant, en ajoutant un autre “\” après le “UNC\”, MapUrlToZone renvoie maintenant 0, ce qui signifie un chemin local :
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
MapUrlToZone conclut donc que cette URL est locale.
La question importante est maintenant de savoir quel sera le verdict de CreateFile pour cette URL.
Accédera-t-il à un fichier local ou le téléchargera-t-il via SMB ?
Fig. 1 : Simulation d’un appel à CreateFile avec le chemin UNC, conduisant à une requête DNS
Une requête DNS a été envoyée pour récupérer l’IP d’Akamai.com (Figure 1).
Il semble que nous ayons trouvé un chemin que MapUrlToZone considère comme local, alors que CreateFile envoie une requête vers Internet !
Maintenant, déclenchons la vulnérabilité originale d’Outlook, cette fois en contournant les mesures d’atténuation ajoutées.
Fig. 2 Déclenchement de l’événement du calendrier, conduisant à l’authentification NTLM contre un serveur distant
Comme vous pouvez le voir dans la figure 2, une fois que le rappel apparaît, Outlook se connecte au serveur distant, ce qui entraîne une authentification NTLM.
Selon Microsoft, les serveurs Exchange sur lesquels la mise à jour logicielle de mars est installée supprimeront la propriété PidLidReminderFileParameter, ce qui éliminera la fonction de fichier sonore personnalisé.
Par conséquent, seules les machines utilisant les clients Outlook avec un serveur Exchange non corrigé sont vulnérables à ce problème.
La cause principale
Ce problème semble résulter de la gestion complexe des chemins d’accès dans Windows.
MapUrlToZone appelle la fonction CreateUri qui convertit incorrectement le chemin ‘\N- \N- \N- \N- \NAkamai.com\Nfichier.wav’ en ‘/.//UNC//Akamai.com/fichier.wav’.
Pour voir quel accès est déclenché par ce dernier chemin, nous pouvons utiliser le script ConvertDosPathToNtPath de l’article de blog de 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 local C :. Il s’agit manifestement d’un répertoire local, et MapUrlToZone renvoie donc 0.
D’autre part, CreateFile convertit d’abord le chemin d’origine d’un chemin DOS à un chemin NT en appelant RtlpDosPathNameToRelativeNtPathName.
Une fois de plus, 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'
Remarquez que, cette fois, le résultat ne pointe pas vers un lecteur local. Alors, pourquoi une requête SMB est-elle déclenchée ?
Comme on peut le voir dans l’extrait ci-dessus, le chemin d’accès résultant est ‘\NUNC\NAkamai.com\Nfichier.wav’. L’accès à ce chemin NT amènera le gestionnaire d’objets à acheminer la requête IO vers le pilote MUP (Multiple UNC Provider). (Ceci est dû au fait que l’entrée du répertoire global des objets pour “UNC” est un lien symbolique vers “\Device\Mup”).
Comme RtlpDosPathNameToRelativeNtPathName a supprimé ou réduit le “\” supplémentaire, le chemin d’accès ne contient plus que le nom de domaine Internet.
Selon Guardicore ce type de confusion peut potentiellement entraîner des vulnérabilités dans d’autres programmes qui utilisent MapUrlToZone sur un chemin contrôlé par l’utilisateur et qui utilisent ensuite une opération de fichier (telle que CreateFile ou une API similaire) sur le même chemin.
Nous ne pouvons pas non plus exclure que d’autres problèmes surviennent dans les programmes qui appellent CreateUri.
Détection et atténuation
Microsoft a publié des conseils complets pour la détection et l’atténuation de la vulnérabilité originale d’Outlook.
D’après les observations, toutes les méthodes spécifiées sont applicables à 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é est un nouvel exemple de l’examen minutieux des correctifs qui conduit à de nouvelles vulnérabilités et à des contournements.
Dans le cas précis de cette vulnérabilité, l’ajout d’un caractère permet un contournement critique du correctif.
Nous espérons que la fonction de son de rappel personnalisé sera entièrement supprimée, car elle pose plus de risques de sécurité qu’elle n’apporte de valeur aux utilisateurs.
Il s’agit d’une surface d’attaque d’analyse multimédia sans clic 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 des efforts continus pour protéger ses clients et la communauté, Guardicore d’Akamaï continuera à analyser les correctifs et autres systèmes à la recherche de vulnérabilités.
Nous tenons à remercier Microsoft pour sa coopération et sa réponse rapide dans la gestion de ce problème
Source : Akamai Guardicore
Pour plus d’informations concernant les solutions GuardiCore