¿Qué es Zerologon?

Zerologon es:

Una vulnerabilidad en la criptografía del proceso Netlogon de Microsoft que permite un ataque frente a los controladores del dominio Active Directory de Microsoft, haciendo posible que un hacker suplante cualquier ordenador, incluido el controlador del dominio raíz.

Zerologon

Zerologon es el nombre dado a la vulnerabilidad identificada en CVE-2020-1472. Se le ha llamado Zerologon debido al error en el proceso de inicio de sesión donde se establece el vector de inicialización (VI) en cero todo el tiempo cuando, en realidad, un vector de inicialización siempre debería ser un número aleatorio.

Esta peligrosa vulnerabilidad tiene un 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 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, pero la falta de validación en la fuente de la solicitud para modificar estas contraseñas se ha convertido un problema de seguridad importante.

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, pero que no debemos confiar en el secretismo del algoritmo para proteger nuestros datos. Otra forma de decir que hoy deberíamos 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 fuerte y demostrado, se deben seleccionar configuraciones adicionales para garantizar la fortaleza correspondiente. MS-NRPC utiliza una configuración poco clara conocida como AES-CFB8 (Estándar de cifrado avanzado - Cipher Feed Back de 8 bits). 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 vector de inicialización (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

La 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. Una vez que 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 y, por lo tanto, 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 de 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 en 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 y 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, y 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 finalmente instalar el parche una vez que se ha publicado. Esto se conoce como el Tiempo medio en aplicar el parche (MTTP). 

Además, desafortunadamente, el parche lanzado recientemente solo soluciona la mitad del problema. Microsoft lanzará una segunda fase del parche, que incluirá la fase refuerzo, el 9 de febrero de 2021. Para entonces, todos los dispositivos tendrán que utilizar el modo de canal seguro y, 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

Dado que el parche que se ha publicado solo contiene la mitad de la solución, se deben llevar a cabo medidas adicionales provisionales para proteger su red, dispositivos y datos. Una de esas medidas de protección es para confirmar que existe la vulnerabilidad. Hay numerosas herramientas, una proporcionada por Secura y Tervoort, ya disponible para detectar las vulnerabilidades de Zerologon en servidores de AD.

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 y detección de intrusiones y software anti-malware para la red y los dispositivos del host (todos los endpoints) para detectar ransomware, virus y otras amenazas. Una SIEM (Administración de eventos e información de seguridad) 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.

También está la nueva idea de la aplicación virtual de parches, una medida de seguridad frente a amenazas que aprovechan vulnerabilidades conocidas y desconocidas. El programa Zero Day Initiative (ZDI) de Trend Micro garantiza la protección de los clientes 81 días antes de que se lance un parche gracias a la implementación de reglas y capas de políticas de seguridad que evitan e interceptan vulnerabilidades como Zerologon. 

Temas de Zerologon