De una vulnerabilidad a otra: el análisis de parches de Outlook revela un defecto importante en la API de Windows
Edición y contribuciones adicionales de Tricia Howard
Resumen ejecutivo
El investigador de Akamai, Ben Barnea, ha descubierto una nueva vulnerabilidad importante en un componente de Internet Explorer denominada CVE-2023-29324 con una puntuación base de CVSS de 6,5.
La vulnerabilidad provoca que una función API de Windows (MapUrlToZone) piense incorrectamente que una ruta remota es una ruta local.
MapUrlToZone se utiliza normalmente como medida de seguridad. En particular, se utilizó para mitigar la vulnerabilidad crítica de Outlook CVE-2023-23397 que se parcheó en el Patch Tuesday de marzo.
Un atacante no autenticado en Internet podría utilizar la vulnerabilidad para obligar a un cliente de Outlook a conectarse a un servidor controlado por un atacante. Esto provoca el robo de credenciales NTLM. Se trata de una vulnerabilidad sin clics, lo que significa que se puede activar sin interacción del usuario.
Todas las versiones de Windows están afectadas por la vulnerabilidad. Como resultado, todas las versiones de cliente de Outlook en Windows son explotables. Sin embargo, según Microsoft, los servidores de Exchange con la actualización de marzo omiten la característica vulnerable, evitando así que se explote a los clientes vulnerables.
El problema se divulgó de forma responsable a Microsoft y se solucionó en el Patch Tuesday de mayo de 2023.
Introducción
Entre las vulnerabilidades corregidas como parte del Patch Tuesday de marzo de 2023 se encontraba una vulnerabilidad crítica de Outlook denominada CVE-2023-23397.
La vulnerabilidad permite a un atacante forzar a un cliente de Outlook a conectarse al servidor del atacante. Al hacerlo, el cliente envía credenciales NTLM al equipo, lo que permite al atacante descifrar la contraseña offline o utilizarla en un ataque de retransmisión. Esta vulnerabilidad se puede aprovechar de forma remota a través de Internet sin ninguna interacción del usuario (sin hacer clic).
Según la evaluación de la inteligencia ante amenazas de Microsoft, un atacante ruso ha utilizado la vulnerabilidad en ataques dirigidos contra varias organizaciones del gobierno europeo, el transporte, la energía y el sector militar durante aproximadamente un año.
Como parte de nuestro análisis del parche, hemos descubierto una forma de omitir la corrección de esta vulnerabilidad crítica. En esta entrada del blog, analizaremos la vulnerabilidad original, el parche y la omisión de dicho parche.
La vulnerabilidad original
La vulnerabilidad de Outlook que se corrigió en marzo se activa cuando un atacante envía un correo electrónico que contiene un recordatorio con un sonido de notificación personalizado. Este sonido personalizado lo especifica el atacante como una ruta, utilizando la propiedad MAPI extendida PidLidReminderFileParameter. Un atacante puede especificar una ruta UNC que haría que el cliente recuperara el archivo de sonido de cualquier servidor SMB. Como parte de la conexión al servidor SMB remoto, el hash Net-NTLMv2 se envía en un mensaje de negociación.
Para solucionar el problema, el código llama ahora a MapUrlToZone para comprobar que la ruta no hace referencia a una URL de Internet. Si es así, se utiliza el sonido de aviso predeterminado en lugar del personalizado.
Omisión de la mitigación
Veamos primero el flujo de código relevante en Outlook. Se llama a dos funciones importantes como parte de la carga del archivo de sonido personalizado:
MapUrlToZone — Devuelve la zona de la URL; se utiliza para determinar que la ruta es local, de Intranet o de confianza (y no de Internet)
CreateFile — Abre un handle (referencia abstracta) al archivo de sonido
Nota: También se llama a SearchPath antes de a CreateFile, pero maneja la ruta de forma similar, por lo que para facilitar la comprensión, aquí solo haremos referencia a CreateFile.
Para encontrar una forma de elusión, necesitamos encontrar una ruta que MapUrlToZone considerara como local, de Intranet o de confianza, y que CreateFile también tratara como un dominio de Internet.
Para llamar a MapUrlToZone, podemos utilizar el siguiente script de PowerShell que llama a la función a través del Modelo de objetos componentes (COM).
Para comprobar que MapUrlToZone es una mitigación adecuada, podemos probarla llamándola 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 está en la zona de Internet, como se esperaba.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
Podemos ponernos creativos y ajustar nuestra ruta UNC usando una ruta de dispositivo local:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Como se ha visto anteriormente, MapUrlToZone aún identifica la ruta como una zona de Internet, por lo que seguirá bloqueada, tal y como pretendía la corrección.
Sin embargo, al agregar otro "\" después de "UNC\", MapUrlToZone devuelve 0, lo que significa una ruta local:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
Por lo tanto, MapUrlToZone concluye que esta URL es local. Ahora la pregunta importante es: ¿Cuál será el veredicto de CreateFile para esta URL? ¿Accederá a un archivo local o lo descargará a través de SMB?
Redoble de tambores…
Fig. 1: Simulación de una llamada CreateFile con la ruta UNC, lo que conduce a una solicitud DNS
¡Genial! Se envió una solicitud DNS para recuperar la IP de Akamai.com (Figura 1). Parece que hemos encontrado una ruta que MapUrlToZone concluye como local, pero hace que CreateFile envíe una solicitud a Internet.
Ahora, activemos la vulnerabilidad original de Outlook, esta vez omitiendo la mitigación añadida.
Fig. 2: Activación del evento de calendario, lo que lleva a la autenticación NTLM en un servidor remoto
Como puede ver en la Figura 2, una vez que aparece el aviso, Outlook se conecta al servidor remoto que conduce a la autenticación NTLM.
Según Microsoft, los servidores de Exchange con la actualización de software de marzo instalada quitarán la propiedad PidLidReminderFileParameter, eliminando la función de archivo de sonido personalizado. Por lo tanto, solo los equipos que ejecutan clientes de Outlook con un servidor de Exchange sin parche son vulnerables a este problema.
La causa principal
Este problema parece ser el resultado de la gestión compleja de rutas en Windows.
MapUrlToZone llama a la función CreateUri que convierte incorrectamente la ruta "\\.\UNC\\Akamai.com\file.wav" en "/.//UNC//Akamai.com/file.wav".
Para ver qué acceso se activa con esta última ruta, podemos usar el script ConvertDosPathToNtPath de la entrada del 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'
Ahora podemos ver que esta ruta apunta a un directorio llamado "UNC" en la unidad C: local. Esto es obviamente un directorio local y por lo tanto MapUrlToZone devuelve 0.
Por otro lado, CreateFile primero convierte la ruta original de una ruta DOS a una ruta NT llamando a RtlpDosPathNameToRelativeNtPathName. Una vez más, el uso del script nos permite observar el resultado de esta conversión.
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'
Observe que esta vez el resultado no apunta a una unidad local. Entonces, ¿por qué se activa una solicitud SMB? Como se puede ver en el fragmento anterior, la ruta resultante es "\??\UNC\Akamai.com\file.wav". El acceso a esta ruta NT hará que el gestor de objetos enrute la solicitud IO al controlador de proveedor UNC múltiple (MUP). (Esto se debe a que la entrada del directorio de objetos global para "UNC" es un vínculo simbólico a "\Device\MUP".) Puesto que RtlpDosPathNameToRelativeNtPathName quitó o contrajo el "\" adicional, la ruta de acceso ahora solo contiene el nombre de dominio de Internet.
Creemos que este tipo de confusión puede provocar vulnerabilidades en otros programas que utilicen MapUrlToZone en una ruta controlada por el usuario que después utilicen una operación de archivo (como CreateFile o una API similar) en la misma ruta. Además, no podemos descartar otros problemas que surjan en programas que llamen a CreateUri.
Detección y mitigación
Microsoft publicó una orientación completa para la detección y mitigación de la vulnerabilidad original de Outlook. A partir de nuestra observación, todos los métodos especificados se aplican a la nueva vulnerabilidad, ya que no dependen de la URL especificada en la propiedad PidLidReminderFileParameter .
Resumen
Esta vulnerabilidad es otro ejemplo más de análisis de parches que conduce a nuevas vulnerabilidades y omisiones. En esta vulnerabilidad en particular, la adición de un carácter permite una omisión crítica de parches.
Esperamos que la función de sonido de recordatorio personalizado se haya eliminado por completo, ya que supone más riesgos de seguridad que el valor que aporta a los usuarios. Se trata de una superficie de ataque de análisis multimedia sin clics que podría contener vulnerabilidades críticas de daños en la memoria. Teniendo en cuenta lo omnipresente que es Windows, eliminar una superficie de ataque tan madura como esta podría tener algunos efectos muy positivos.
Como parte de nuestros esfuerzos continuos para proteger a nuestros clientes y a la comunidad, seguiremos analizando parches y otros sistemas en busca de vulnerabilidades. Para mantenerse al día con las últimas investigaciones de seguridad de Akamai, síganos en Twitter.
Nos gustaría agradecer a Microsoft su cooperación y su rápida respuesta en la gestión de este problema.
