¿Qué es Zerologon?
Zerologon es una vulnerabilidad en la criptografía del proceso de Netlogon de Microsoft que permite un ataque frente a los controladores de dominio de Active Directory de Microsoft. Zerologon hace que un hacker pueda suplantar cualquier ordenador, incluido el controlador del dominio raíz.
Zerologon
Zerologon es el nombre dado a la vulnerabilidad identificada en CVE-2020-1472. Procede de una imperfección en el proceso de inicio de sesión: El vector de inicialización (VI) se establece como cero en todo momento, cuando un VI debería ser siempre un número aleatorio.
Esta peligrosa vulnerabilidad tiene una gravedad de 10 en una escala de 10 (CVSS v3.1) medida según el Common Vulnerability Scoring System (CVSS). Hay exploits de prueba de concepto (POC) activos conocidos y es muy probable que próximamente veamos ataques en el mundo real.
La Agencia de seguridad cibernética e infraestructura (CISA) emitió una directriz de emergencia solicitando a las agencias federales civiles que apliquen inmediatamente un parche o deshabiliten los servidores de Windows afectados y aconsejó a las organizaciones no gubernamentales a hacer lo mismo. Microsoft publicó el primero de dos parches en agosto de 2020, y tienen que aplicarse a todos los controladores de dominio.
Esta vulnerabilidad realiza un exploit de un error de criptografía en el Netlogon Remote Protocol de Active Directory de Microsoft (MS-NRPC), el cual permite a los usuarios iniciar sesión en los servidores que utilizan NTLM (NT LAN Manager).
El principal problema con esta vulnerabilidad es que el MS-NRPC también se utiliza para transmitir determinados cambios de cuenta, como contraseñas de cuentas de servicio del equipo. Volviendo a su origen, es posible ver la razón de añadir esta función. Sin embargo, la falta de validación en la fuente de la solicitud para modificar estas contraseñas se ha convertido en un importante problema de seguridad.
Todo empeora a partir de aquí. El cifrado que se añadió a MS-NRPC no se seleccionó sabiamente. En 1883, el criptógrafo holandés Aguste Kerckhoff publicó dos ensayos, titulados La Cryptographie Militaire (La criptografía militar), destacando los seis principios clave para el diseño de sistemas criptográficos.
El más famoso de todos ellos, el Principio de Kerckhoff, manifiesta que debemos mantener nuestra clave criptográfica en secreto, y que no debemos confiar en el secretismo del algoritmo para proteger nuestros datos. Por el contrario, debemos utilizar algoritmos muy bien conocidos, probados y demostrados.
El algoritmo que se utilizó originalmente para cifrar el proceso de inicio de sesión en Windows NT fue 2DES, el cual hoy sabemos que tiene problemas. En la actualidad, MS-NRPC utiliza el estándar de cifrado avanzado (AES), considerado la referencia del cifrado.
Además de elegir un algoritmo sólido y demostrado, se deben seleccionar configuraciones adicionales para garantizar la fortaleza correspondiente. MS-NRPC utiliza una configuración poco clara conocida como Estándar de cifrado avanzado - Cipher Feed Back de 8 bits (AES-CFB8). AES-CFB8 es poco claro porque no es suficientemente conocido ni está suficientemente probado.
El uso de AES-CFB8 en MS-NRPC tiene un problema con el VI el cual debería ser un número aleatorio, pero MS-NRPC lo tiene fijo en un valor de 16 bytes de ceros. Es de todo, menos aleatorio. Es previsible. A menudo, es posible superar la criptografía cuando hay previsibilidad.
Cómo conocemos esta vulnerabilidad
Esta vulnerabilidad fue anunciada en Septiembre de 2020 por Tom Tervoort, un investigador holandés que trabaja para Secura. Concretamente, se aplicó un parche en la vulnerabilidad en agosto, pero no fue hasta que el investigador publicó su informe en septiembre que comenzamos a ver POC y otras actividades.
Tervoort detalla su descubrimiento y el proceso que lo llevó a ello. Durante su investigación, descubrió una gran falta de información sobre MS-NRPC. Interesado en ello, Tervoort buscó más información.
Si bien Tervoort estaba buscando primeramente un ataque de «person-in-the-middle», descubrió otra vulnerabilidad detallada en CVE-2020-1424. Continuó con su investigación e identificó lo que actualmente se conoce como Zerologon.
La parte fundamental de su descubrimiento es que Microsoft implementó una variación única de criptografía que es distinta al resto de los protocolos de RPC. En los tiempos de Windows NT, las cuentas asignadas a un equipo no se identificaban como una principal de primera clase. Por lo que Microsoft no podría utilizar el Kerberos estandarizado o NTLM para autenticar cuentas de equipos u ordenadores.
Como resultado, los desarrolladores elaboraron una alternativa. Es sumamente difícil crear código y protocolos para cifrado que no sean potencialmente crackeables. De hecho, puede tomar realmente mucho tiempo antes de que los errores se descubran, como este caso.
Cómo funciona el ataque
La vulnerabilidad permite a un hacker hacerse con el control de un controlador de dominio (CD), incluido el CD raíz. Esto se realiza modificando o eliminando la contraseña para una cuenta de servicio en el controlador. A continuación, el hacker puede provocar la denegación del servicio o tomar el control y apropiarse de toda la red.
Para que los atacantes realicen un exploit de esta vulnerabilidad, deben poder establecer una sesión de TCP con un CD. Si están dentro de la red físicamente, podrían estar en el escritorio del usuario o en un puerto abierto en una localización como una sala de conferencias.
Estos exploits se consideran como «insider attacks» (ataques internos), los ataques más costosos para las empresas en la actualidad. Se pueden establecer desde fuera la red durante tanto tiempo como puedan hacerse con un punto de apoyo en algún lugar para establecer la sesión de TCP con el controlador.
Mediante el uso de AES-CFB8 con un vector de inicialización fijo de 16 bytes de ceros, Tervoort descubrió que existe una probabilidad de una entre cada 256 claves utilizadas en las que el texto cifrado tenga un valor compuesto de solo ceros. Este es un número extremadamente pequeño de claves para que un ataque intente crear texto cifrado compuesto de solo ceros. Al ordenador del hacker solo le haría falta, como mucho, unos 2-3 segundos llevar esto a cabo.
Por lo que, ¿por qué es esto importante?
Si el equipo que comunica a un CD pertenece a un usuario que simplemente está realizando su uso diario habitual, no hay un problema real. Se lleva a cabo este texto cifrado mal construido, pero el proceso de autenticación de la red funcionará. El problema solo se muestra cuando un hacker intenta realizar un exploit en el sistema.
En el ataque demostrado por Tervoort, el hacker primero tendría que falsificar la credencial o contraseña de un cliente en la red. Debido a la mala implementación del vector de inicialización en MS-NRPC, solo lleva unos 256 intentos obtener la correcta.
Normalmente, una cuenta de usuario se bloquearía transcurridos tres intentos de adivinación de contraseña, pero no se sigue el mismo patrón para una cuenta de equipo u ordenador. Cuando un ordenador está iniciando sesión no hay límite establecido en los intentos fallidos de contraseña, lo que permite que los hackers ingresen en un corto periodo de tiempo gracias a una continua ráfaga de intentos. Solo tienen que dar con una de las claves que produce un texto cifrado compuesto de solo ceros.
¿Qué pueden hacer los hackers una vez que han falsificado la identidad de un equipo en una red? Tras lograr el primer paso de falsificación de la identidad, el atacante no conoce la clave de cifrado real de la sesión. Los atacantes solo han podido falsificar la identidad con una de las 256 claves que producen un texto cifrado compuesto solo de ceros. El siguiente paso es deshabilitar la «firma y sellado».
La firma y sellado de RPC es el mecanismo utilizado para el cifrado de transporte en MS-NRPC. Este parece el proceso lógico dado que deberíamos cifrar más nuestros datos en tránsito, pero en MS-NRPC esto es una opción adicional que está desactivada al no establecer una marca en el encabezado de un mensaje.
Una vez que la firma y sellado están desactivados, los mensajes se envían de forma transparente. A continuación, los hackers ahora podrán llevar a cabo las acciones que deseen, incluida la eliminación de una contraseña o su establecimiento en otro valor. Habrá un parche de Microsoft en febrero de 2021 para obligar la firma y sellado.
El tercer paso es cambiar la contraseña para la cuenta que ha sido falsificada. El dispositivo más eficaz para falsificar es un servidor de AD, preferiblemente el servidor de AD raíz. Para cambiar la contraseña, los atacantes utilizan el mensaje NetServerPasswordSet2 en MS-NRPC.
Es posible modificar una contraseña enviando simplemente el marco con la nueva contraseña preferida. El enfoque más sencillo es eliminar la contraseña o establecerla como un valor vacío, el hacker ahora puede iniciar sesión mediante un proceso normal.
Si el ataque se dirige a un equipo aleatorio en la red, entonces ese equipo no podrá iniciar sesión. Por lo que la primera consecuencia de este ataque es simplemente un ataque de denegación de servicio frente al equipo.
Impacto global
En la actualidad existen varios exploits de POC públicos. Si los servidores de AD no están parcheados, es posible realizar un mayor daño a las empresas, porque el ataque se podría utilizar para inyectar ransomware en una red.
Hay herramientas para verificar si sus servidores son susceptibles. Tervoort y Secura lanzaron una herramienta en GitHub para verificar que sus controladores de dominio están parcheados o descubrir si son vulnerables.
El parche para CVE-2020-1472
En agosto de 2020, Microsoft lanzó un parche para CVE-2020-1472 (Zerologon). Todos los servidores de AD (2008 R2 y posteriores) se deberían parchear lo antes posible. Sin embargo, el tiempo medio desde el lanzamiento del parche hasta la implementación sigue siendo muy largo.
Los investigadores declaran que las organizaciones tardan una media de entre 60 y 150 días (aproximadamente 5 meses) en instalar finalmente el parche una vez que se ha publicado. Esto se conoce como el Tiempo medio en aplicar el parche (MTTP).
Desafortunadamente, el parche lanzado recientemente no es la solución universal para el problema. Microsoft está planeando lanzar una segunda fase del parche, que incluirá capacidades de refuerzo a principios de febrero de 2021.
Para entonces, todos los dispositivos tendrán que utilizar el modo de canal seguro. Si no lo hacen, se les negará el acceso. Si hay dispositivos más antiguos que no cumplan los requisitos, tendrán que ser añadidos manualmente a una política de grupo que expresamente permita el acceso a dispositivos que no cumplen los requisitos.
Aplicación virtual de parches
Siempre se deberían adoptar las medidas de seguridad tradicionales para vigilar las redes y cuentas comprometidas, el tráfico malicioso y otros indicadores de compromiso (IOC). Son fundamentales los sistemas de prevención de intrusiones (IPS) y software anti-malware para la red y dispositivos del host (todos los endpoints) para detectar ransomware, virus y otras amenazas.
Una SIEM debe recopilar, centralizar y analizar registros. Una vez analizados los registros, debería contarse con personas y procesos para responder a los indicadores de compromiso (IOC). A continuación, un equipo de respuesta ante incidentes con sólidos conocimientos y procedimientos debería encargarse de decidir la amplitud del compromiso y trabajar en una resolución.
Incluso con la disponibilidad de un parche del proveedor, muchos clientes aún siguen necesitando tiempo para implementarlos y para adoptar medidas adicionales de seguridad para proteger su entorno. El concepto de aplicación virtual de parches a través de herramientas como IPS proporciona a los administradores y profesionales de seguridad una herramienta adicional en su arsenal.
Les ayuda a ganar tiempo fundamental para proteger sus redes. La aplicación de parches del proveedor sigue siendo la mitigación recomendada. Las soluciones de aplicación virtual de parches ayudan a proteger equipos sin parches. En numerosas circunstancias, también otorgan un valioso conocimiento en los intentos de exploit posteriores al parche en una red mediante funciones como la inspección de registros.
Los clientes de Trend Micro pueden obtener más información sobre las prácticas recomendadas para abordar la vulnerabilidad y sobre cómo podemos ayudar visitando este artículo de la base de conocimientos: https://success.trendmicro.com/solution/000270328
Temas de Zerologon
Recursos relacionados
Investigaciones relacionadas