LDAPNightmare: Análisis del primer exploit de prueba de concepto para CVE-2024-49113 desarrollado por SafeBreach
Los Controladores de Dominio (DCs) de Active Directory son considerados una de las piezas más críticas dentro de las redes corporativas. } Las vulnerabilidades encontradas en los DCs suelen ser mucho más graves que aquellas en terminales de trabajo convencionales. La posibilidad de ejecutar código en un DC o bloquear servidores Windows afecta significativamente la postura de seguridad de una red. El 10 de diciembre de 2024, Yuki Chen (@guhe120) descubrió dos vulnerabilidades en el protocolo LDAP de Windows: una ejecución remota de código (RCE) y una denegación de servicio/fuga de información que afectan a cualquier DC. Ambas vulnerabilidades fueron publicadas en el sitio del Microsoft Security Response Center (MSRC) como parte del parche de seguridad de diciembre (Patch Tuesday). – CVE-2024-49112: Vulnerabilidad de ejecución remota de código con una puntuación de severidad CVSS de 9.8 sobre 10. – CVE-2024-49113: Vulnerabilidad de denegación de servicio (DoS). RESUMEN GENERAL SafeBreach Labs desarrolló un exploit de prueba de concepto (PoC) para CVE-2024-49113 que puede bloquear cualquier servidor Windows sin parches (no solo DCs) con el único requisito previo, que el servidor DNS del DC víctima tenga conectividad a Internet. Flujo de ataque 1. El atacante envía una solicitud DCE/RPC a la máquina víctima. 2. La máquina víctima envía una consulta DNS SRV sobre SafeBreachLabs.pro. 3. El servidor DNS del atacante responde con el nombre de su propia máquina y el puerto LDAP. 4. La máquina víctima envía una solicitud NBNS de difusión para obtener la dirección IP del nombre de host recibido. 5. El atacante responde con su propia dirección IP. 6. La máquina víctima se convierte en un cliente LDAP y envía una solicitud CLDAP al atacante. 7. El atacante responde con un paquete de referencia CLDAP malicioso, lo que hace que LSASS se bloquee y el servidor víctima se reinicie. Se cree que esta misma cadena de ataque podría modificarse para lograr ejecución remota de código (RCE) cambiando el último paquete CLDAP enviado. Estos hallazgos son significativos por varias razones: – Demuestra la criticidad de la vulnerabilidad, probando que puede bloquear múltiples servidores Windows sin parches. – Microsoft clasificó esta vulnerabilidad como potencialmente explotable para RCE. – Se Verifica que el parche de Microsoft corrige la vulnerabilidad, impidiendo que el exploit bloquee servidores parcheados. DETALLES TÉCNICOS A continuación, explicamos en detalle cómo el equipo de SafeBreach Labs identificó la ruta de explotación que desencadena la vulnerabilidad y bloquea un DC (o cualquier servidor Windows). CVE-2024-49113 Esta vulnerabilidad fue titulada como «Vulnerabilidad de denegación de servicio en el Protocolo Ligero de Acceso a Directorios (LDAP) de Windows». LDAP es el protocolo que las estaciones de trabajo y servidores en Active Directory utilizan para acceder y mantener la información de directorios. Microsoft proporcionó pocos detalles en su publicación en el MSRC, pero sobre la vulnerabilidad RCE (CVE-2024-49112), mencionó lo siguiente: «Un atacante remoto no autenticado que explote esta vulnerabilidad podría ejecutar código arbitrario en el contexto del servicio LDAP. Sin embargo, la explotación depende del componente objetivo.» Basándonos en esta información, hicimos las siguientes suposiciones: – El atacante no necesita autenticación. – La vulnerabilidad está relacionada con desbordamiento de enteros y se encuentra en un ejecutable o biblioteca (DLL) que implementa lógica de cliente LDAP. – Se pueden usar llamadas RPC para obligar a un DC a realizar una consulta LDAP a un servidor controlado por el atacante. – Probablemente la vulnerabilidad esté en exe o en alguna DLL cargada por él. Un investigador, Artur Marzano (@MacmodSec), sugirió que el parche de Microsoft se hizo en wldap32.dll, lo que concuerda con esta investigación. Ejecutando una solicitud LDAP remota: El primer paso para explotar esta vulnerabilidad en un Controlador de Dominio (DC) es hacer que éste consulte un servidor LDAP controlado por el atacante. Para lograrlo, se buscó una llamada RPC dentro del proceso lsass.exe (o alguna de sus bibliotecas) que utiliza funciones de wldap32.dll. Identificación de llamadas RPC en lsass.exe: Usando RpcView, se analizaron las interfaces RPC disponibles en lsass.exe, filtrando aquellas que dependieran de wldap32.dll y no requieren autenticación. Se encontraron dos interfaces en lsasrv.dll y netlogon.dll que contenían llamadas RPC aparentemente relacionadas con consultas LDAP. Ubicando la función vulnerable: Luego, se investigaron las funciones RPC importadas desde wldap32.dll, encontrando DsrGetDcNameEx2. Según la documentación de Microsoft, esta función devuelve información sobre un Controlador de Dominio (DC) en un dominio específico y puede verificar si una cuenta existe. Esta función es ideal, ya que permite especificar tanto el nombre del dominio como el nombre de la cuenta, lo que indica que si se utiliza LDAP, podría ser explotable. Parámetros clave de DsrGetDcNameEx2 Para hacer que un DC víctima consulte un servidor LDAP atacante, se configuraron los parámetros de la función de la siguiente manera: ComputerName: Nombre del host del DC víctima (pero no es relevante para la ejecución). AccountName: Cualquier nombre de cuenta ficticio. AllowableAccountControlBits: Se puso en 0, ya que no interesa el resultado de la consulta. DomainName: Se estableció al dominio del atacante. SiteName: Se dejó en NULL. Flags: Se puso en 0 para usar el comportamiento predeterminado. DomainControllerInfo: Parámetro de salida donde se almacena la respuesta. Para probar la explotación, se crearon dos Controladores de Dominio en la misma subred con nombres de dominio distintos: – SBRESEARCH.LAB (controlado por el atacante). – TESTDOMAIN.LAB (víctima). Desde el DC atacante, se ejecutó DsrGetDcNameEx2 apuntando al DC víctima, pero no se observó tráfico LDAP esperado en Wireshark. Descubrimiento del uso de DNS en la consulta LDAP Aunque no hubo tráfico LDAP, Wireshark mostró que el DC víctima realizó una consulta DNS SRV en busca de un servidor LDAP en el dominio atacante. Sin embargo, la consulta falló porque el servidor DNS del DC víctima no conocía SBRESEARCH.LAB. Ejemplo de consultas SRV generadas: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.SBRESEARCH.LAB _ldap._tcp.dc._msdcs.SBRESEARCH.LAB Para que el ataque funcione, el DC víctima debe recibir una respuesta válida a su consulta DNS. Como solución a este inconveniente se decidió registrar un dominio real en Internet Dado que el servidor DNS de la víctima no tenía información sobre SBRESEARCH.LAB, pero sí sobre dominios legítimos como google.com, se decidió registrar un dominio público: safebreachlabs.pro Se crearon dos registros SRV en este dominio: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.safebreachlabs.pro _ldap._tcp.dc._msdcs.safebreachlabs.pro Estos registros apuntaban al hostname del DC atacante y al puerto 389 (LDAP). Ejecución exitosa del ataque Se repitió la llamada a DsrGetDcNameEx2 en el DC víctima, pero esta vez usando safebreachlabs.pro en el parámetro DomainName. Como resultado, el DC víctima realizó una consulta LDAP al servidor del atacante. Wireshark confirmó que la consulta se ejecutó usando CLDAP (Connectionless LDAP) sobre UDP, y con WinDbg se verificó que la petición fue procesada por wldap32.dll. Conclusión Este ataque explota una llamada RPC en lsass.exe para forzar a un Controlador de Dominio a consultar un servidor LDAP controlado por un atacante. La clave del éxito fue manipular la resolución DNS mediante registros SRV en un dominio legítimo, lo que permitió eludir restricciones y obtener tráfico LDAP desde la víctima. ENVIANDO UNA RESPUESTA LDAP MALICIOSA Después de lograr que el Controlador de Dominio (DC) de la víctima consultara el servidor LDAP malicioso, el siguiente paso es entender cómo debe ser la respuesta para explotar la vulnerabilidad descubierta: LdapChaseReferral. ¿Qué es un Referral en LDAP? En Active Directory, un árbol puede estar distribuido entre múltiples servidores LDAP. Si uno de estos servidores no tiene la respuesta a una consulta, puede responder con un referral, que redirige al cliente a otro servidor que podría tener la información. No todos los clientes siguen estos referrals, pero en nuestro caso, el DC de la víctima sí lo hace. Para indicar un referral, el servidor LDAP debe responder con un código específico e incluir URLs LDAP válidas (con ldap:// o ldaps://). Construyendo una respuesta Maliciosa Para explotar esta vulnerabilidad, creamos un servidor LDAP personalizado sobre UDP que pudiera enviar respuestas con referrals maliciosos. Al analizar el parche de Microsoft, se puede notar que se agregó una verificación para comparar dos valores en la función vulnerable: – “lm_referral” – “referral table size” El código compara estos valores para asegurarse de que lm_referral esté dentro de los límites de la tabla de referrals. Sin embargo, en la versión vulnerable, este valor se usa directamente para acceder a un offset dentro de la tabla de referrals, sin una validación adecuada. Cómo manipular el lm_referral Con Windbg, se observa que: – lm_referral es 0 por defecto. – El puntero a la tabla de referrals también es 0. Sin embargo, la validación solo comprueba si lm_referral ≠ 0, lo que significa que si logramos controlar este valor y hacerlo distinto de 0, podremos modificar un puntero en la memoria. Buscamos en wldap32.dll dónde se asigna lm_referral y encontramos dos funciones clave: – LdapInitialDecodeMessage – LdapChaseReferral En LdapInitialDecodeMessage, se ve que lm_referral y msgid provienen del mismo lugar en el paquete de respuesta LDAP. Además, el lm_referral se construye a partir de un valor de 4 bytes, pero debido a un desplazamiento de bits, solo se necesita modificar el byte más significativo para controlar su valor. Cómo explotar la vulnerabilidad Para establecer un lm_referral distinto de 0, hicimos lo siguiente en el servidor LDAP malicioso: 1. Aumentar la longitud del campo “value_from_response_packet” de 1 byte a 4 bytes. 2. Ahora se puede modificar el byte más significativo del valor, asegurándose de que sea divisible por 2 para evitar alterar el “Im_msgid” Con esto, se logra que el código acceda fuera de los límites de la tabla de referrals, lo que provoca un acceso inválido a memoria y un fallo en LSASS, causando un crash del sistema operativo. CONCLUSIÓN FINAL Esta investigación demostró que CVE-2024-49113 puede explotarse no solo contra Controladores de Dominio, sino contra cualquier servidor Windows sin parchear. También se cree que CVE-2024-49112 podría explotarse en el futuro, por lo que recomendamos aplicar ambos parches lo antes posible y mantener los servidores actualizados a la última versión Fuente: SafeBreach Labs. (2024). LDAP Nightmare: SafeBreach Labs publica la primera prueba de concepto de exploit para CVE-2024-49113. Recuperado de https://www.safebreach.com/blog/ldapnightmare-safebreach-labs-publishes-first-proof-of-concept-exploit-for-cve-2024-49113/ LDAPNightmare: Análisis del primer exploit de prueba de concepto para CVE – 2024-49113 desarrollado por SafeBreach
NET_API_STATUS DsrGetDcNameEx2(
[in, unique, string] LOGONSRV_HANDLE ComputerName,
[in, unique, string] wchar_t* AccountName,
[in] ULONG AllowableAccountControlBits,
[in, unique, string] wchar_t* DomainName,
[in, unique] GUID* DomainGuid,
[in, unique, string] wchar_t* SiteName,
[in] ULONG Flags,
[out] PDOMAIN_CONTROLLER_INFOW* DomainControllerInfo
);
