Hacking Windows con Zerologon: Vulnerabilidad crítica que puede comprometer tu Domain Controller #Parchea

Zerologon es una de esas vulnerabilidades que sacuden al mundo de la ciberseguridad por varias razones. Es una de esas vulnerabilidades que aparecen cada cierto tiempo y que nos dejan un sabor agridulce. ¿Por qué? Las razones son obvias: sencillez de explotación, cualquiera puede obtener el exploit público y ejecutar con Python una línea que le dé el control total del dominio. Tan sencillo como lo pintan estas líneas. Detrás de ese exploit público y de las diferentes versiones que han salido, mucho trabajo de investigación, sin duda. Y tú debes actualizar cuanto antes.

Figura 1: Hacking Windows con Zerologon:

Vulnerabilidad crítica que puede comprometer tu Domain Controller

Otra de las razones es por lo que provoca, es una escalada de privilegios de 0 a 100, quizá en este caso de 0 a 1000, ya que provoca que un usuario cualquier, que ni siquiera está en el dominio pueda cambiar la contraseña de la máquina del DC y apoderarse de todo un dominio de una empresa, lo que hace que sea una de las técnicas que hay que tener presentes de hoy en adelante dentro de las formas en las que hacemos el Hacking de Windows. Cuando uno empieza leyendo la documentación de Zerologon de la empresa Secura se da cuenta de la gravedad y criticidad de la vulnerabilidad. 

Figura 2: Libro de Hacking Windows de 0xWord

Todo comenzó el pasado 11 de agosto cuando Microsoft habló de la vulnerabilidad del servicio Netlogon, pero, ¿qué es Netlogon Remote Protocol? Como bien han indicado los compañeros de hackplayers, Netlogon Remote Protocol es una interfaz RPC para los Controladores de Dominio (DC - Domain Controllers) - de los Directorios Activos (AD - Active Directory), el cual es utilizado para tareas, diferentes, de autenticación de usuarios y máquinas.

Figura 3: Detalles de la implementación del parche

El objetivo de este protocolo es facilitar que los usuarios inicien sesión en servidores utilizando NTLM, aunque no es solamente eso. También autenticación de respuestas NTP o permitir que un equipo actualice la contraseña en el dominio. Y una vez que se supo de la vulnerabilidad,  Microsoft publicó un parche en agosto, pero no será hasta febrero cuando la actualización se lleve por completo. 

Figura 4: Detalles de la implementación del parche (parte 2)

¿Esto quiere decir que la primera fase de la actualización no sirve? No es así. El parche funciona, pero hay que aplicar alguna configuración extra para asegurarse de que funciona. Así podíamos leer a mi compañero Sergio de los Santos hablando sobre esto.  Aparte de aplicar el parche de agosto, y esperar al de febrero, debemos verificar, para forzar, que la clave FullSecureChannelProtection tiene valor a “1”. 

Figura 5: Recomendaciones de Sergio de los Santos

Hay un debate sobre si la aplicación de la fase 1 del parche evita ya la posible explotación. Al menos verificando FullSecureChannelProtection y aplicando el parche los exploits públicos de hoy en día no funcionan. Lo que parece claro es que Microsoft no las tiene todas consigo y que matar la posibilidad de la conexión no segura es el camino que marca Microsoft para que podamos estar “más tranquilos”. Seguramente, en febrero obtendremos mayor detalle.

Cómo funciona Zerologon

Netlogon no usa un esquema de autenticación similar a otros servicios RPC. Utiliza un protocolo criptográfico personalizado. La idea es que cliente y servidor se demuestren que conocen el secreto compartido. El secreto compartido es un hash de la contraseña de la cuenta de equipo del cliente. Esto es debido a que Windows NT no podía hacer uso de esquemas estándar como NTLM o Kerberos. Si quieres conocer más sobre los mecanismos de autenticación en Windows, el libro de Máxima Seguridad en Windows Gold Edition escrito por nuestro compañeros Sergio de los Santos lo explica al detalle.

Figura 6: Máxima Seguridad en Windows Gold Edition

de Sergio de los Santos publicado en 0xWord

La implementación basada en AES-CFB8 no estaba correctamente realizada. El cliente y el servidor utilizan una función llamada ComputeNetlogonCredential, la cual no define IVs aleatorios y si los hace fijos con ceros (hasta 16 bytes). La probabilidad de “predecir” y obtener un bloque con todo ceros es baja para una clave aleatoria dada. 

Figura 7: Esquema de ataque Zerologon

En ese caso, comienza el despliegue que indica Secura en su paper. Aquí tenéis el esquema del ataque con detalle, el cual se puede ver en el paper.  A continuación resumimos los pasos:

Paso 1: Spoofing sobre las credenciales del cliente

Tras el intercambio de desafíos con NetrServerReqChallenge, el cliente se autentica así mismo haciendo una llamada a NetrServerAuthenticate3. El parámetro ClientCredential de la anterior llamada se calcula aplicando ComputeNetlogonCredential al desafío que se envío anteriormente. Este desafío puede ser elegido por nosotros, por lo que no hay que impida poner este desafío a 8 ceros. Como se indica en el paper, 1 de cada 256 claves de sesión, constará de 8 ceros. 

 

No podemos saber que nuestra sesión utiliza una de estas claves, pero cada vez que intentamos autenticar, el servidor seguirá generando un desafío único de servidor. Esto significa que la clave de sesión será diferente y, uniformemente distribuida. Las cuentas de equipo no se bloquean después de varios intentos fallidos, aquí hay un punto importante, por lo que podemos hacer fuerza bruta. El promedio esperado será de 256, lo que nos llevaría unos 3 segundos. De esta forma, se podrá iniciar sesión como cualquier equipo del dominio, incluyendo controladores de dominio.

Paso 2: Deshabilitando signing y sealing

En el paso anterior se puede lograr el bypass de la llamada de autenticación. Pero en este instante no se sabe cuál es el valor de la clave de sesión. Esto es un problema ya que el mecanismo de cifrado de Netlogon, firma y sellado RPC, se encuentra en otro esquema diferente al de la función ComputeNeglogonCredential que es la vulnerable. 

 

Por suerte, el firmar y sellar es opcional y se puede deshabilitar con el simple hecho de omitir un flag en la llamada a NetrServerAuthenticate3. Los clientes más actuales se negarán por defecto a conectarse cuando este flag no esté fijado por el servidor, sería una protección para prevenir ataques de downgrade, pero los servidores no rechazarán a estos clientes que no soliciten ningún tipo de cifrado. Este es un factor con un poco de suerte. En el momento que el servidor obligue, se solventaría en parte, aunque la función pueda seguir siendo vulnerable.

Paso 3: Falsificando una llamada

Cada llamada que puede aportar algo debe contener un valor de autenticación. El valor es calculado con ComputeNeglogonCredential, es decir, con la clave de sesión aplicado a ClientStoredCredential + Timestamp. ClientStoredCredential es un valor incremental que mantiene el cliente. Cuando se realiza el handshake se inicializa al mismo valor que el ClientCredential. Esta credencial de cliente consiste únicamente en varios ceros, por lo que ClientStoredCredential será 0 para la primera llamada realizada después de la autenticación.

El sello de tiempo o timestamp debe contener la hora actual de Posix y es incluido en la llamada del cliente. El servidor no pondrá muchas restricciones sobre cuál puede ser ese valor y tiene sentido, ya que cualquier mínima desviación del reloj podría dar problemas. Se puede “fingir” que es 1 de enero de 1970 y establecer el valor en 0. Se puede autenticar la primera llamada simplemente proporcionando un autenticador con todo cero y un timestamp con todo cero.

Paso 4: Cambiando el password de un equipo del AD

Aquí se utiliza la llamada NetrServerPasswordSet2, la cual es utilizada para establecer una nueva contraseña de equipo. La contraseña está cifrada con la clave de sesión utilizando el cifrado AES-CFB8 comentado anteriormente. La contraseña de texto en Netlogon constan de 516 bytes. Los últimos 4 bytes indica la longitud de la contraseña (en bytes). Los bytes que no forman para de la función de contraseña se verán como un relleno y pueden disponer de valores arbitrarios o aleatorios. 

 

Si se utilizan 516 ceros, se descifrará a 516 ceros. En otras palabras, contraseña de longitud cero, por lo que tendríamos una contraseña vacía y en una cuenta de equipo está permitido. Por ello en los ejemplos de explotación que se ven por Internet podemos ver el hash de la contraseña vacía, cuando se recupera con, por ejemplo, secretsdump.py.

Aquí ya se tiene gran parte del proceso hecho. Ahora se puede crear una nueva conexión de Netlogon en nombre de dicho equipo. Una vez hecho esto, se podrá cambiar a la contraseña que se quiera y restaurar, que es algo que también se ha estado viendo en Internet y que en los repositorios de Github dónde se puede encontrar las PoC se hace hincapié.

Paso 5: Administrador de dominio

En el documento de Zerologon se muestra cómo, a uno de los equipos que se puede cambiar la contraseña, es al propio Controlador de Dominio. En el momento que se hace, se consigue la escalada de privilegios total en el dominio. Pero antes de acabar hay que tener en cuenta que la contraseña del DC que se almacena en el AD o Active Directory es diferente de la contraseña almacenada en su registro local, cuya ruta es HKLM\SECURITY\Policy\Secrets\$machine.ACC.

Como esto puede generar comportamientos impredecibles, se utiliza secretsdump.py de Impacket con la nueva contraseña del equipo del DC. Este script puede volcar toda la información referente a los hashes.

Mimikatz actualizado con Zerologon

Una de las herramientas más utilizadas en los proyectos de Ethical Hacking y con más funcionalidades para el pentesgting de los sistemas Windows y de la que hablamos largo y tendido en nuestro libro de Hacking Windows, Mimikatz, ya ha lanzado una actualización para poder hacer la explotación de Zerologon.

Figura 8: GIF de ejemplo de Mimikatz explotando Zerologon

En la Figura 8 os dejamos el GIF que ha publicado GentilKiwi en su Github sobre la implementación de Mimikatz con Zerologon.

Test & PoC’s & Detección de Zerologon

La gente de Secura publicó una herramienta a modo de test para que los administradores comprobasen si su DC es vulnerable a esta técnica. La herramienta indica claramente que no realiza ninguna modificación, simplemente chequea que la vulnerabilidad está ahí y hay que parchear. Para poder ejecutarla hay que instalar las dependencias de Python.

Figura 9: instalando las dependencias con Python

Posteriormente, se indica el nombre de la máquina y la dirección IP y ahí lo tenemos. En este ejemplo se ve como mi DC sería vulnerable. 

Figura 10: Comprobando si el DC es vulnerable o no

    
Ahora, si probamos sobre mi dominio la herramienta secretsdump.py introduciendo la contraseña de dominio veremos que la máquina HC-SERVER$ tiene un hash, que no corresponde con el hash nulo.

Figura 11: Explotando la vulnerabilidad Zerlogon

Si lanzáramos alguna de las versiones de exploits públicos que hay por Internet veríamos como el hash de la cuenta de equipo HC-SERVER$ cambia a su representación del hash nulo. Por lo que podríamos autenticar con ese hash una cuenta de equipo y poder acceder a la información.

Figura 12: Ejemplo de cómo se puede volcar el domino completo

En Twitter son muchos los mensajes de ejemplo que muestran que diferentes exploits públicos funcionan, lo que muestra la necesidad de parchear ya. En la Figura 12, se puede ver cómo tras lanzar el exploit y utilizar secretsdump.py se puede hacer un volcado completo del dominio. Si mirásemos la cuenta de la máquina del DC, veríamos que está con el valor del hash nulo. Y en la siguiente imagen os dejo un hilo de Carlos García hablado de la detección de Zerologon con ejemplo sobre los eventos a los que poner el foco. Recomendado.

Also, look for 2 password changes (event 4742) of the DC computer account in a short period of time. This password is only changed automatically every 30 days by default, so 2 changes in a short period of time is suspicious.
Anyway, patch now :) [3/3] pic.twitter.com/WnQjkMoosr

— Carlos García ciyi (@ciyinet) September 16, 2020

Sin duda es momento de verificar que las actualizaciones de agosto están aplicadas, de verificar que el parámetro FullSecureChannelProtection está a 1 y utilizar la herramienta de Secura para verificar que nuestros DCs no son vulnerables. Pronto vendrá el módulo de Metasploit, seguramente, y todo será, si cabe, más sencillo. Por último, hay repositorios de Github de BlackArrow, NCC o Dirk-janm los cuales han implementado diferentes versiones de este exploit. Hay que #ParchearYa.

Patch, Patch & Patch!!!

 Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

Figura 14: Contactar con Pablo González