¿Qué Es Zerologon?

Zerologon es una vulnerabilidad en la criptografía del proceso de Netlogon de Microsoft que permite un ataque contra los controladores de dominio de Microsoft Active Directory. Zerologon hace que sea posible para un hacker hacerse pasar por cualquier computadora, incluyendo el controlador raíz de dominio.

Zerologon

Zerologon es el nombre que se le ha dado a una vulnerabilidad identificada en CVE-2020-1472. Viene de una falla en el proceso de logon: El vector de inicialización (IV) está configurado en ceros todo el tiempo, aunque un IV siempre debe ser un número al azar.

Esta peligrosa vulnerabilidad tiene una calificación de 10 de 10 en severidad (CVSS v3.1) por el Common Vulnerability Scoring System (CVSS). Existen exploits activos conocidos de proof-of-concept (POC), y es muy probable que comencemos a ver ataques en el mundo real pronto.

La Cybersecurity and Infrastructure Security Agency (CISA) lanzó una directiva de emergencia ordenando a agencias civiles federales parchar o deshabilitar inmediatamente todos los servidores afectados de Windows, y advirtió a las organizaciones no gubernamentales a hacer lo mismo. Microsoft liberó el primero de dos parches en agosto de 2020, y es necesario que se apliquen en todos los controladores de dominio.

Esta vulnerabilidad explota una falla criptográfica en Microsoft Active Directory Netlogon Remote Protocol (MS-NRPC). Permite que los usuarios se conecten a los servidores que están usando NTLM (NT LAN Manager). 

El problema más grande con esta vulnerabilidad es que MS-NRPC también se utiliza para transmitir ciertos cambios de cuenta, como las contraseñas de las cuentas de servicios de cómputo. Pensando en su origen, es posible ver la lógica de agregar esta capacidad. Sin embargo, la falta de validación en la fuente de la solicitud para cambiar estas contraseñas se ha convertido en un tema importante de seguridad.

Se pone peor a partir de aquí. La encripción que fue agregada a MS-NRPC no se eligió con cuidado. En 1883, el criptógrafo holandés Aguste Kerckhoff publicó 2 ensayos, titulados La Cryptographie Militaire (Criptografía Militar), delineando los 6 principios clave para diseñar sistemas criptográficos. 

El mejor conocido de ellos, el Principio de Kerckhoff, declara que debemos mantener secreta nuestra clave criptográfica. Y no debemos de depender en el secreto del algoritmo para proteger nuestros datos, sino que debemos usar algoritmos conocidos, probados y comprobados.

El algoritmo originalmente usado para encriptar el proceso de log-on en Windows NT fue 2DES, el cual ahora sabemos tiene problemas. Hoy MS-NRPC usa el Advanced Encryption Standard (AES), considerado el benchmark para la encipción. 

Además de elegir un algoritmo fuerte y comprobado, se deben de seleccionar configuraciones adicionales para asegurar una fortaleza adecuada. MS-NRPC usa una configuración oculta conocida como Advanced Encryption Standard – Cipher Feed Back 8bit (AES-CFB8). AES-CFB8 es “oculta” porque no es muy conocida y no está muy probada. 

El uso de AES-CFB8 dentro de MS-NRPC tiene un problema con el IV el cual debería de ser un número al azar, pero MS-NRPC lo tiene fijo a un valor de 16 bytes de zeros. Eso no es al azar. Es predecible. La criptografía a menudo se rompe donde hay previsibilidad.

Cómo es que sabemos acerca de esta vulnerabilidad

Esta vulnerabilidad fue anunciada en septiembre de 2020 por Tom Tervoort, un investigador holandés que trabaja para Secura. Esta vulnerabilidad en realidad fue parchada en agosto, pero fue hasta que se publicó el reporte en septiembre que comenzamos a ver POCs y otro tipo de actividades. 

El reporte de Tervoort detalla su descubrimiento y el proceso que lo llevó a él. Durante su investigación, se dio cuenta de que hacía una falta importante de información acerca de MS-NRPC. Intrigado, Tervoort buscó más información. 

Mientras Tervoort estaba buscando un ataque tipo person-in-the-middle, descubrió otra vulnerabilidad en CVE-2020-1424. Continuando su investigación, identificó lo que ahora es conocido como Zerologon. 

La parte crítica de este descubrimiento es que Microsoft implementó una variación única de la criptografía que es diferente de todos los demás protocolos RPC. En la época de Windows NT, las cuentas asignadas a una computadora no se identificaban como un principal de primera clase. Eso significaba que Microsoft no podía usar el Kerberos estandarizado o NTLM para autentificar las cuentas de las computadoras o de las máquinas. 

Como resultado, los desarrolladores crearon una alternativa. Es increíblemente difícil crear código y protocolos de encripción “a prueba de hackers”. De hecho, puede pasar mucho tiempo antes de que se descubran las fallas, como es el caso aquí.

Cómo funciona el ataque

Esta vulnerabilidad permite que un hacker tome el control de un controlador de dominio (DC), incluyendo el DC raíz. Esto se logra por medio del cambio o la eliminación de la contraseña para una cuenta de servicio en el controlador. El hacker puede entonces simplemente causar una denegación de servicio o tomar el control de toda la red.

Para que los atacantes exploten esta vulnerabilidad, deben poder establecer una sesión TCP (Transmission Control Protocol) con un DC. Si están físicamente dentro de la red, podrían estar en el escritorio de un usuario o en un puerto abierto en una ubicación como una sala de conferencias. 

Estos exploits califican como ataques internos: los más caros para un negocio actualmente. Pueden establecerse desde fuera de la red siempre y cuando puedan encontrar un punto de apoyo para establecer la sesión TCP para el controlador.

Usando AES-CFB8 con un IV fijo de 16 bytes de ceros, Tervoort descubrió que existe la posibilidad de que una de cada 256 claves utilizadas creará texto cifrado que tiene un valor de solamente ceros. Este es un número extremadamente pequeño de claves para que el atacante intente crear un texto cifrado de solamente ceros. Tomaría, a lo mucho, 2 o 3 segundos para que la computadora de un hacker pueda lograrlo.

Diagrama encripción AES-CFB8 (all-zero IV y plaintext)

¿Por qué es importante?

Si una máquina comunicándose a un DC pertenece a un usuario que está haciendo su día de forma normal, no hay mayor problema. Este texto encriptado mal construido ocurre, pero el proceso de autenticación de red funcionará. El problema surge cuando un hacker intenta aprovechar el sistema.

En el ataque comprobado por Tervoort, el hacker debería primero falsificar la credencial o contraseña de un cliente en la red. Debido a la mala implementación del IV dentro de MS-NRPC, solamente se necesitarían 256 intentos para obtener la opción correcta. 

Normalmente la cuenta de un usuario se bloquearía después de tres intentos para adivinar una contraseña, pero esto no sucede con una computadora o una cuenta de una máquina. Cuando una computadora se intenta conectar no hay límite de intentos de contraseñas erróneas, lo cual permite que los hackers hagan un gran número de intentos y reduzcan el tiempo en el que pueden entrar a un sistema. Tienen que encontrar una de las claves que produzca un texto cifrado que esté completamente en ceros.

¿Qué pueden hacer los hackers una vez que han asumido la identidad de una computadora en la red? Con el primer paso de asumir la identidad siendo un éxito, el atacante no tendría conocimiento de la clave de encripción real para la sesión. Los atacantes sólo habrían podido asumir una identidad al identificar una de las 256 claves que producen un texto cifrado en ceros. El siguiente paso es deshabilitar “signing and sealing.”

RPC signing and sealing es el mecanismo usado para la encripción en tránsito en MS-NRPC. Este parece ser un proceso lógico, ya que debemos encriptar más datos en tránsito. Dentro de MS-NRPC, sin embargo, esta es una característica opcional que puede deshabilitarse simplemente por no poner una marca en el encabezado de un mensaje. 

Una vez que la firma y el sello se deshabilitan, los mensajes de mandan sin contratiempos. Los hackers podrían tomar las acciones que quisieran, incluyendo eliminar una contraseña o cambiarla a otro valor. Estará disponible un parche de Microsoft en febrero de 2021 para proteger signing and sealing.

El tercer paso es cambiar la contraseña de la cuenta que se ha imitado. El dispositivo más efectivo para ser imitado sería un servidor AD, preferiblemente incluso el servidor AD raíz. Para cambiar la contraseña, los atacantes usan el mensaje NetServerPasswordSet2 en MS-NRPC. 

Es posible cambiar una contraseña simplemente al mandar el marco con la nueva contraseña. El enfoque más sencillo es eliminar la contraseña y configurarla como un valor en blanco – el hacker ahora puede conectarse a través de un proceso normal. 

NetrServer


Si el ataque tiene como blanco una computadora al azar dentro de la red, esa computadora no podría conectarse. Entonces, la primera consecuencia de este ataque es simplemente un ataque de denegación de servicio contra esa computadora.

Impacto global

Ahora existen varios exploits PoC disponibles para el público. Si los servidores AD no son parchados, los negocios podrían sufrir daños severos ya que el ataque podría utilizarse para insertar ransomware en una red. 

Existen herramientas para revisar si sus servidores son susceptibles. Tervoort y Secura liberaron una herramienta en GitHub para verificar que sus controladores de dominio están parchados o descubrir si son vulnerables.

El parche para CVE-2020-1472

En agosto de 2020, Microsoft liberó un parche para CVE-2020-1472 (Zerologon). Todos los servidores AD (2008 R2 y superiores) deberían parcharse lo más pronto posible. Pero el tiempo promedio entre la liberación del parche y su implementación aún es muy largo. 

Los investigadores dicen que, en una organización promedio, toma entre 60 y 150 días (alrededor de 5 meses) después de que un parche es liberado hasta que finalmente es instalado. Esto es conocido como el tiempo promedio para parchar, o Mean Time to Patch (MTTP). 

Desafortunadamente este parche recién liberado no es el arreglo definitivo para el problema. Microsoft está planeando lanzar una segunda fase del parche, la cual incluirá las capacidades de refuerzo, a principios de febrero de 2021.

Para ese momento, todos los dispositivos deberán usar el modo de canal seguro. De no hacerlo, se les negará el acceso. Si existen dispositivos más antiguos sin cumplimiento, tendrán que agregarse manualmente a una política grupal que explícitamente les permita el acceso.

Parcheo Virtual

Las medidas tradicionales de seguridad siempre deberían aplicarse para vigilar que no existan cuentas y dispositivos comprometidos, buscar tráfico malicioso y otros indicadores de compromiso. Son críticos los sistemas de prevención (IPS) de intrusiones y software antimalware para la red y los dispositivos del host (todos los endpoints) son críticos para monitorear y detectar ransomware, virus y otras amenazas. 

Los logs deben de recolectarse, centralizarse y analizarse por un SIEM. Una vez que los logs se analizan, debe de haber gente y procesos listos para responder frente a indicadores de compromiso (IoC). Entonces, un equipo de respuesta a incidentes con procesos y conocimientos sólidos debe tomar el control para decidir la extensión del compromiso y trabajar para lograr una resolución.

Aún con la disponibilidad de un parche del vendor, muchos clientes aún necesitan tiempo para desplegar los parches e implementar medidas adicionales de seguridad para proteger sus ambientes. El concepto del parcheo virtual a través de herramientas como IPS le da una herramienta adicional al arsenal de los administradores y profesionales de seguridad. 

Ayuda a ganar tiempo valioso para proteger las redes. El parcheo de vendors es aún la mitigación recomendada. Las soluciones de parcheo virtual ayudan a proteger las máquinas no parchadas. En muchas circunstancias, también dan insights valiosos a intentos de explotación después de la colocación del parche en una red a través de características como la inspección de logs.

Los clientes de Trend Micro pueden conocer más acerca de las mejores prácticas para abordar la vulnerabilidad y 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