Publicación del blog 15 de noviembre de 2019, por Tom Tervoort, especialista sénior en seguridad de Bureau Veritas Cybersecurity
Toma del control de sistemas Windows con un ataque Netlogon Man-in-the-Middle (CVE-2019-1424)
Antecedentes
El Procotol Remoto Netlogon es un protocolo de Llamada a Procedimiento Remoto (RPC) que realiza varias funciones en redes Windows relacionadas con la autenticación de Active Directory. Puede utilizarse, por ejemplo, para restablecer las contraseñas de las máquinas o para realizar copias de seguridad de la base de datos de usuarios del controlador de dominio. La aplicación más común, sin embargo, es facilitar el inicio de sesión remoto a través del protocolo NTLM.
El propósito del protocolo NTLM es permitir a los usuarios del dominio iniciar sesión en sistemas remotos dentro de la red, como servidores que proporcionan archivos compartidos o sitios web de la intranet. Aunque este protocolo ha sido sustituido por Kerberos desde la introducción de Windows 2000, sigue siendo ampliamente utilizado y soportado. Casi todos los servicios de Windows que admiten la autenticación Kerberos también permitirán por defecto que los clientes inicien sesión utilizando NTLM.
Cuando alguien se autentica correctamente en un dominio de Windows, se calcula un hash MD4 (también llamado "hash NTLM") de su contraseña.1 El controlador de dominio también almacena hashes MD4 de las contraseñas de todos los usuarios. Cuando el cliente quiera autenticarse entonces en un servicio que utilice NTLM, dicho servicio le transmitirá un reto aleatorio. Para probar la identidad del usuario, el cliente responderá con un MAC criptográfico (Código de Autenticación de Mensaje), computado sobre el desafío utilizando el hash de la contraseña del usuario como clave secreta.
Cuando el servicio en cuestión no se ejecuta en el propio controlador de dominio, en realidad no tiene acceso al hash de la contraseña y, por lo tanto, no puede validar si el MAC es correcto. En ese caso, el sistema que ejecuta el servicio establecerá una conexión con el controlador de dominio y le enviará el reto junto con la respuesta recibida del cliente. El controlador de dominio verificará la MAC e informará al servicio de si es válida o no. Si no lo es, puede significar que el usuario ha introducido una contraseña incorrecta. Sin embargo, si la autenticación tiene éxito, el controlador de dominio también informará al servicio de a qué grupos pertenece el usuario y le proporcionará una clave de sesión secreta.2 Este intercambio de información entre la máquina que ejecuta el servicio y el controlador de dominio hace uso del protocolo remoto Netlogon.
Ilustración 1: Funcionamiento normal del protocolo de autenticación NTLM (flujo feliz). La conexión entre el servidor y el DC utiliza el protocolo Netlogon.
El protocolo
El protocolo remoto Netlogon está construido sobre MSRPC (Microsoft Remote Procedure Call), y su especificación está disponible públicamente. Cuando un cliente desea establecer una conexión Netlogon con el controlador de dominio, primero se conecta al servicio EPM (Endpoint Mapper) en el puerto TCP 135. A continuación, el controlador de dominio informará al cliente en qué puerto TCP está disponible un servicio Netlogon. Si el cliente no puede alcanzar el servicio EPM o el puerto indicado (posiblemente porque un cortafuegos lo bloquee), en su lugar realizará un túnel de conexión Netlogon a través del protocolo SMB en el puerto 445. Esto significa que las llamadas Netlogon se transmiten utilizando MSRPC-sobre-TCP o MSRPC-sobre-SMB-sobre-TCP.
Dado que la integridad y confidencialidad de la información intercambiada a través del protocolo es crítica, se utilizan controles criptográficos para proteger las llamadas a procedimientos remotos y sus respuestas. Curiosamente, Netlogon no utiliza el cifrado MSRPC estándar, sino un protocolo alternativo. Al inicio de una conexión, el cliente y el servidor intercambian valores aleatorios y, a continuación, obtienen una clave de sesión a partir de una combinación de la contraseña de la máquina del cliente y estos dos valores. A continuación, el cliente se autentica demostrando la posesión de esta clave de sesión. Todos los paquetes posteriores se cifran y autentican utilizando la clave de sesión. Este Proceso es idéntico independientemente de si se utiliza el túnel SMB.
La vulnerabilidad
Dado que el protocolo criptográfico utilizado para Netlogon es bastante poco ortodoxo y no ha sido sometido a mucho escrutinio que yo sepa, decidí investigar posibles vulnerabilidades en el protocolo o en su implementación. Mientras probaba una configuración de laboratorio en la que sería capaz de realizar ataques man-in-the-middle contra el protocolo, de repente noté algo extraño en mi captura de red: Llamadas Netlogon que no estaban siendo encriptadas.
Después de experimentar un poco, descubrí que esto se debía a que yo había bloqueado accidentalmente el tráfico tanto a EPM como al puerto dinámico de Netlogon, provocando un retroceso a SMB. Normalmente, esto no sería un problema: si EPM no está disponible, el cliente realizaría el handshake de autenticación de forma normal y empezaría a cifrar los mensajes después. En este caso, sin embargo, bloqueé el tráfico a estos puertos después de que ya se hubiera establecido una sesión cifrada.
Por alguna razón, cuando se produce un retroceso a SMB mientras ya se ha establecido una sesión, los paquetes Netlogon posteriores no se cifran y su integridad no queda protegida. Sin embargo, los mensajes del servidor y del cliente seguirían conteniendo "autenticadores", que son campos obligatorios del mensaje que se generan con la clave de sesión. Sin embargo, estos valores no dependen del contenido del resto del mensaje, por lo que un atacante podría realizar cualquier cambio arbitrario en los mensajes, siempre y cuando se limitara a dejar el autentificador original en su lugar.
Por lo tanto, un atacante con una posición de hombre en el medio entre la máquina y el controlador de dominio podría forzar la desactivación del cifrado activando el fallback SMB justo después de que la máquina realizara el handshake de autenticación. Esto podría lograrse inyectando paquetes TCP RST cuando el cliente intentara conectarse al puerto 135 o al puerto dinámico Netlogon.
Un atacante capaz de falsificar las respuestas Netlogon del controlador de dominio a una máquina podría entonces utilizar este ataque para sustituir una respuesta de "inicio de sesión fallido" por un mensaje de "inicio de sesión correcto". Este mensaje sería aceptado por la máquina, pensando que el CD había autenticado con éxito al usuario. También serían capaces de determinar a qué grupos pertenecería el usuario que intentara iniciar sesión.
Ilustración 2: Ataque Man-in-the-middle: el atacante deshace el cifrado y falsifica una respuesta Netlogon para darse a sí mismo acceso de administrador al objetivo.
Impacto
No sería necesario esperar a que algún otro usuario intentara iniciar sesión. En su lugar, el atacante puede iniciar sesión él mismo, fingiendo que sólo admite NTLM y proporcionando alguna contraseña no válida. El servicio en el que se están logueando reenviará el handshake NTLM al controlador de dominio y éste respondería con un mensaje negativo. A continuación, este mensaje podría ser sustituido por una respuesta falsificada (que también contendría una clave de sesión recalculada) indicando que la contraseña era correcta y que, por cierto, el usuario que intenta iniciar sesión resulta ser miembro del grupo de administradores del dominio (lo que significa que también tiene privilegios administrativos en la máquina de destino).
Cuando se obtiene una posición de hombre en el medio entre algún sistema X y el controlador de dominio, un atacante podrá utilizar este ataque para iniciar sesión como administrador en cualquier servicio de X que admita la autenticación NTLM. A través de varios tipos de servicios, como SMB, WMI o DCOM, la capacidad de iniciar sesión como administrador puede conducir a la ejecución remota de código con ese rol, lo que significa que el sistema objetivo puede verse comprometido por completo.
Los objetivos contra los que es probable que este ataque tenga éxito son las estaciones de trabajo de las Personas, que a menudo permiten conexiones SMB entrantes. Además, hay muchas técnicas que un atacante puede utilizar para llevar a cabo ataques man-in-the-middle contra esos sistemas: como la suplantación de ARP/NDP, la suplantación de la respuesta DHCP, la configuración de un punto de acceso Wi-Fi malicioso o la conexión de un dispositivo de interceptación en una toma de red.
Esta vulnerabilidad puede ser especialmente peligrosa cuando un atacante tiene un punto de apoyo en una red interna porque permite tanto la elevación de privilegios (a administrador local) como el movimiento lateral (obtener RCE en otras máquinas de la red).
Después de revelar esta vulnerabilidad y una cadena de exploit Proof-of-Concept funcional a Microsoft, respondieron rápidamente y se publicó una corrección el 12 de noviembre de 2019. Se recomienda encarecidamente que se aplique este parche (al menos a los controladores de dominio) lo antes posible, ya que así se mitigará por completo esta vulnerabilidad.
__________________________________
Al realizar la autenticación sin contraseña con tarjetas inteligentes o Windows Hello, el controlador de dominio proporcionará en su lugar al cliente un hash MD4 de una contraseña larga generada aleatoriamente. Esto mitiga un fallo importante del protocolo NTLM, del que a los pentesters y atacantes les encanta aprovecharse: su vulnerabilidad a los ataques de adivinación de contraseñas sin conexión.
Esta clave se deriva de la contraseña y puede ser calculada de forma independiente por el cliente. Varios protocolos, incluido SMBv3, hacen uso de este secreto compartido para autenticar y cifrar el tráfico entre el cliente y el servidor.