Cracking passwords Windows y Active Directory
Motivado por el video compartido por La Comunidad Dragonjar en su artículo ¿Cómo tomar control de un Dominio en Windows?, me dieron ganas de investigar un poco más a fondo la forma de almacenamiento de passwords en Windows y su Active Directory, y ver hasta dónde podía escalar dentro del dominio.
A continuación les daré una breve descripción del mecanismo para almacenar passwords y luego la parte interesante, es decir, cómo crackearlos! Por último, describiré formas de dificultar esta tarea, configurando Windows apropiadamente.


Algo de Historia

No es secreto que Windows tiene mala fama en cuanto a seguridad (y eficiencia, utilidad, etc, pero restrinjamonos a hablar de la seguridad =P). La administración de passwords no es la excepción, y viene mal implementada desde hace décadas. Y a qué se debe que conserven un sistema tan malo luego de tantos años? gracias a la señora "compatibilidad hacia atrás". Si bien a lo largo de los años desplegaron mejores formas de administrar los passwords, su lema "ser compatible con lo inseguro" acarrea que las mejoras no sirvan.

La historia del almacenamiento inseguro viene desde MS Lan Manager, un sistema operativo de red desarrollado por MS en la prehistoria (hablando en tiempos computacionales), y cuyo algoritmo para hashear los passwords (LM Hash) es tan desastroso, que un passwords se rompe en cuestión de segundos usando Rainbow Tables, o en horas (a veces minutos) usando fuerza bruta.
El algoritmo LM convierte todos los caracteres del password a mayúsculas, los parte en dos partes de 7 caracteres y luego hashea cada parte por separado, de forma que un ataque por fuerza bruta solo requiere hacer pruebas de hasta 7 caracteres en mayúsculas! En versiones modernas de Windows, los passwords mayores a 14 caracteres se almacenan directamente con hash NTLM y no se utiliza LM. En cambio en versiones antiguas, el password se recortaba a 14 caracteres si este contaba con más caracteres.
La forma de autenticar un usuario de red es utilizando estos débiles hashes, y este sistema de autenticación se reutilizó en Windows 95, 98 y Me.

Y qué tiene que ver este OS prehistórico con el almacenamiento de passwords en Windows NT modernos (2000 en adelante)? como dije al principio, la "compatibilidad hacia atrás". Dado que la gente de MS deseaba que sus sistemas modernos fueran compatibles con los antiguos, decidieron seguir almacenando los passwords utilizando el hash LM. De esta forma, si en la misma red conviven Windows 95, Lan Manager u otro de estos, con los nuevos Windows 2000, XP o 2003, todo "funciona"! Si un XP se comunica con un 98, éste le pasa el LM Hash para autenticarse y vice-versa.

Si bien el algoritmo para almacenar passwords se fue mejorando con la introducción de NTLM (NT Lan Manager) y NTLMv2, la compatibilidad hace que estos sean sólo un complemento y no una mejora. A partir de Windows 2000, en los dominios Active Directory (AD) se comenzó a utilizar Kerberos, el cual desplazó NTLM, pero tanto LM como NTLM siguen existiendo.

Por defecto Windows 2000, XP y 2003 vienen configurados para almacenar localmente tanto el hash LM como el NTLM. Las cuentas AD, como veremos más adelante, se almacenan de forma distinta. A partir de Windows Vista, se desactivó esta funcionalidad, aunque viene integrada por si algún administrador desea habilitarla.


Background técnico

Los passwords, en Windows 2000 y superiores, se almacenan en un archivo llamado SAM (Security Accounts Manager) que se encuentra en el directorio %SystemRoot%\system32\config (generalmente C:\WINDOWS\system32\config). En dicho archivo se encuentran nombre de usuario, id, password LM Hash y password NTLM Hash (si, el password está dos veces, una vez hasheado con cada algoritmo).
Para aquellos nostálgicos, en Windows 95 y 98 -Gracias Javi por la Info- los passwords se guardaban en archivos pwl, con nombre <usuario>.pwl. Aquí además se almacenaban los passwords dial-up. El almacenamiento era reversible, es decir, no se hasheaban sino que se encriptaban con un algoritmo débil.

Obtener los datos del archivo SAM no es tan simple como abrir y copiar. Cuando Windows se está ejecutando, éste obtiene un lock exclusivo sobre el SAM y no lo libera hasta que no se apaga. Esto quiere decir que, mientras Windows se ejecuta, es imposible leer el archivo. Además los hashes se encuentran encriptados usando la herramienta SYSKEY, cuya clave se encuentra en el archivo system (ubicado en el mismo directorio que SAM).

Cuando Windows inicia, éste lee los passwords de la SAM local, los desencripta y los almacena en las claves de registro:
HKEY_LOCAL_MACHINE/SAM/SAM/Domains/Accounts/Users
HKEY_LOCAL_MACHINE/SAM/SAM/Domains/Accounts/Names
esto nos brinda un punto más de ataque como veremos a continuación.

Active Directory utiliza una forma diferente para almacenar las contraseñas de los usuarios. En un dominio el usuario no se autentica contra el Windows de la máquina local, sino contra kerberos, que se encuentra en los Domain Controlers (DC). Esto hace que las credenciales de los usuarios no se encuentren en cada máquina, sino en un repositorio central (los DC). Pero Windows nos da una mano para poder obtener estos hashes...
Cada vez que un usuario de dominio se loguea en una máquina, Windows cachea las credenciales del usuario en la máquina donde se logueó. Esto se utiliza para que, en caso de cortes en la red, o caída de los DCs, el usuario pueda autenticarse y utilizar la máquina igual. Dichas credenciales, como no podía ser de otra manera, se almacenan en el registro, en las claves:
HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$1
HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$2
...
HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$10
Estos passwords se almacenan de forma mucho más segura que los passwords locales. Al igual que en los casos anteriores tenemos nombre de usuario, y password hasheado usando LM Hash y NTLM Hash, pero todos estos datos se encuentran encriptados usando una clave llamada LSA y una combinación de los algoritmos DES, HMAC_MD5 y RC4. Además se utiliza salt para el calculo de la clave que desencripta los hashes, haciendo que los ataques con Rainbow Tables sean prácticamente imposibles. Por otra parte, las claves de registro no se pueden acceder ni siquiera siendo administrador, sólo se pueden acceder teniendo permisos SYSTEM.


Let's Crack some passwords!

Si se fumaron toda la teoría, estarán contentos de leer que a partir de aquí les diré como obtener los condenados passwords =)
Como siempre, la teoría puede parecer algo pesada, pero es indispensable para entender bien que corno estamos haciendo (por algo el lema del blog es "constante deseo por saber cómo funcionan las cosas").

Para la tarea vamos a necesitar algunas herramientas:
- bkhive (para la clave SYSKEY)
- samdump2 (para obtener los datos almacenados en SAM en formato pwdump)
- john the ripper (para crackear los passwords usando diccionarios o fuerza bruta)
- ophcrack (para crackear los passwords usando rainbow tables)
- pwdump (otra forma de obtener los datos almacenados en SAM)
Parecen muchas herramientas, pero dependiendo lo que queramos hacer, sólo necesitaremos algunas. A excepción de pwdump que es para Windows, todas las demás se encuentran en las distribuciones de Linux.

Hay dos formas de obtener cuentas locales en una máquina Windows. Una es desde el mismo Windows, para lo cual necesitaremos privilegios de Administrador, y la otra es iniciar desde otro sistema. Desde Windows necesitamos privilegios de administrador porque otro usuario no puede acceder a los campos de la registry donde se almacenan las credenciales, y claro, no podemos acceder al archivo SAM porque está lockeado por el mismo Windows.

En mi propuesta, asumo que arrancamos con base 0, osea, sólo tenemos acceso físico a la computadora, pero no tenemos ninguna cuenta de usuario, o bien una cuenta sin privilegios. En esta situación, utilizaré una distro Linux, la cual puede ser backtrack que ya trae las herramientas que necesito.

Partiendo de aquí, lógicamente, iniciamos el sistema con el live-cd, montamos Windows en /mnt/crack/ y procedemos a obtener los hashes de la SAM. El primer paso será obtener la clave de encripción de los hashes para lo cual utilizamos bkhive:
bkhive /mnt/crack/WINDOWS/system32/config/system syskey.txt
Con esto obtenemos el syskey en syskey.txt. A continuación utilizamos samdump2 para por fin sacar las credenciales de la SAM:
samdump2 /mnt/crack/WINDOWS/system32/config/SAM syskey.txt > hashes.txt
El comando anterior toma el archivo SAM y el syskey para devolver los hashes. La salida la redirijo al archivo hashes.txt que luego utilizaré en el cracker.

Con lo descripto ya deberíamos tener las credenciales con los passwords hasheados en formato pwdump.
Cuál es el formato pwdump? el siguente:
<usuario>:<id>:<LM Hash>:<NTLM Hash>:comentarios:directorio-home:
La salida debe estar en un formato entendible por los crackers, y el formato pwdump es casi como un estándar, entendible por los crackers más conocidos.

Como se darán cuenta, a partir de la descripción del algoritmo LM, crackear passwords por fuerza bruta lleva poco tiempo. Siempre es más rápido realizar ataques de diccionario, pero como lo vamos a sacar igual, usemos fuerza bruta =P
john -i:all hashes.txt
con -i:all le indicamos a john the ripper que utilice fuerza bruta.

Algo muchísimo más efectivo que fuerza bruta, y que sirve también para passwords hasheados solamente con NTLM es usar rainbow tables. ophcrack es la herramienta más conocida para realizar este trabajo. Simplemente:
- descarguen ophcrack
- descarguen alguna tabla rainbow
- carguen la/s tabla/s descargada/s en ophcrack
- carguen el archivo hashes.txt en ophcrack
- denle al botón crack
- vean la magia

Si crackear un password de 7 caracteres con john me tomó una 1:15 hs, con ophcrack hice el mismo trabajo en menos de 10 mins.


Para qué sirve PWDump?

Tal vez se estén haciendo esa pregunta...
PWDump permite hacer un volcado de las credenciales locales que se encuentran cargadas en la registry de Windows, mientras Windows se está ejecutando. El problema es que, para poder utilizar esta herramienta necesitamos ser administradores.
Como expliqué anteriormente, mi idea es explicar como obtener passwords asumiendo que no tenemos más que el acceso físico a la máquina, algo que ya hicimos en el párrafo anterior. Osea, obtener passwords de administrador, siendo ya administrador no tiene tanto sentido.
Pero pensándolo desde un punto de vista de auditoría, quizás a alguno le sirva saber que existe esta posibilidad, así que les tiro el tip.
PWDump hace lo mismo que samdump, con la diferencia que toma las credenciales desde la registry en lugar de leer el archivo SAM. La forma de utilizarlo es:
pwdump.exe <nombre-de-la-máquina>
Si la máquina se llama pepito, el comando sería:
pwdump.exe pepito > hashes.txt
Al igual que hice con samdump, redirijo la salida a un archivo de texto para luego poder usar algún cracker.


Cracking Dominios!

Bien, para esta altura ya deberíamos tener las cuentas locales de una máquina, incluida la de algún administrador local. Ahora sí podemos loguearnos en Windows, aunque todavía no en el dominio.
Según lo descripto anteriormente, las cuentas de dominio se almacenan en la registry y están bastante protegidas. Lo bueno es que seguramente el administrador de dominio so logueó en la máquina analizada, por lo que hay grandes chances de conseguir el password del admin de dominio... osea, el admin de tooooda la red (si, Dios de la red >=) ).
Un problema que puede surgir es que la política de passwords nos juegue en contra. Si la política requiere que un usuario cambie su password cada X cantidad de días, y si la cuenta del usuario de dominio que obtenemos no se logueó durante X días en nuestra máquina, el password que obtendremos será inútil. Lo mismo si el usuario cambió su password por gusto y no se logueó luego en nuestra máquina.

Pero bueno, supongamos que estamos con suerte y las cuentas del dominio en nuestra máquina todavía sirven. Pasemos entonces a la forma de obtenerlas.

Para este trabajo necesitamos las siguientes herramientas:
- CacheDump (para obtener las credenciales Active Directory almacenadas en la registry)
- john the ripper parchado para mscache
Utilizando CacheDump podremos obtener las credenciales almacenadas en el registro, pero no como texto plano. Debido a que los datos están encriptados utilizando varios niveles de encripción, CacheDump nos sirve para obtener el llamado MSCASH=( MD4( MD4(password ) || lowercase(username) ), el cual luego debemos desencriptar utilizando john the ripper.
El trabajo de CacheDump es crear un servicio que corra como SYSTEM para así obtener la clave LSA que se encuentra en la memoria del proceso LSASS (Local Security Authority System Service). Una vez obtenida la clave, descifra las entradas en el registro para obtener el MSCASH, es decir, hace lo siguiente:
0. LSA keyB = DES( NL$KM, static in-memory LSA keyA )
1. RC4 keyC = HMAC_MD5( LSA keyB, CH )
2. DATA = RC4( EDATA, RC4 keyC );
donde DATA contiene el MSCASH que buscamos.

La ejecución de este programa es muy sencilla. Simplemente tipeen:
cachedump.exe > mscash.txt
donde redirijimos la salida a un archivo que luego utilizamos en el john.
A veces la ejecución puede dar errores, o bien no mostrar nada. Para que la salida les muestre un poco más de información, pueden utilizar la opción -v. Eso sí, no redirijan esa salida a un archivo porque luego no les servirá para el cracker.

Ahora que tenemos el MSCASH, necesitamos crackearlo para obtener las cuentas. Los mismos desarrolladores de CacheDump desarrollaron un parche para john the ripper que sirve para crackear formatos MSCASH. Si bien en muchos sites antiguos explican como aplicar el parche, la realidad es que en las versiones actuales de john el formato ya viene incorporado.
Para realizar el cracking tendremos que pasarle el parámetro format. El comando quedaría de la siguiente forma:
john --format=mscash mscash.txt
en este caso nos vendrían bien algunos diccionarios, porque crackear estos passwords por fuerza bruta no es tan simple como el caso de los hash LM y puede llevar mucho tiempo. También es útil utilizar sesiones para que, en caso de detener el cracking, lo podamos reiniciar más adelante. La forma de utilizar sesiones es muy simple, pasamos el parametro session seguido del nombre de la sesión. Si luego queremos reiniciar una sesión detenida por alguna razónz, lo hacemos con el parámetro restore y el nombre de la sesión. El ejemplo para nuestro caso sería:
john --format=mscash --session=MSCASH_crack mscash.txt
donde MSCASH_crack es el nombre de la sesión. Si la ejecución se detiene y queremos reiniciarla luego, simplemente ejecutamos:
john --restore=MSCASH_crack


Resúmen

Si todo fue bien, logramos pasar de siquiera tener usuario en una máquina a ser administradores de dominio... no es cool?


Contramedidas

Hay una serie de medidas que podemos tomar para hacer mucho más difícil la tarea del atacante. Por un lado tenemos el problema de los hashes LM. Desde Windows 2000 esta función se puede desactivar, y forzar que Windows sólo almacene hashes NTLM. En la página de MS pueden encontrar como realizar esta tarea, la cual requiere aplicar la directiva NoLMHash, que se puede aplicar como política de grupo o agregando la clave NoLMHash en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
De esta forma Windows no almacenará el hash LM de los nuevos passwords, sólo el NTLM. Presten atención, porque la directiva se aplica a los nuevos passwords, los que no se cambien luego de agregar el valor NoLMHash, quedarán como estaban en la SAM.

Otra medida es tener una buena política de passwords. Passwords cortos son más fáciles de obtener que passwords largos. Igualmente no podemos hacer mucho contra ataques por Rainbow Tables, el cual permite hallar claves de hasta 14 caracteres. Si podemos lograr que los usuarios utilicen contraseñas con más de 14 caracteres, estaríamos bastante a salvo =)

Por último, para evitar el cracking de cuentas de dominio, lo que podemos hacer es:
- Quitarle el permiso de administrador local a todos los usuarios.
- Reducir el número de passwords cacheados. Esto se puede hacer poniendo en 1 (o preferentemente 0 si no necesitamos cachear) la clave HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON\CACHEDLOGONSCOUNT


Referencias

- Theory and practice of password auditing and recovery in Windows NT/2000/XP/2003
- Crackear las contraseñas de los usuarios en XP, Windows 2000 y NT
- Cracking Windows Passwords with Ophcrack and Rainbow Tables
- Cracking Cached Domain/Active Directory Passwords on Windows XP/2000/2003
- Security Accounts Manager (wiki)
- CacheDump - Recovering Windows Password Cache Entries
- How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases
- Reverse Engineering/Cracking Windows XP Passwords
- Cracking Syskey and the SAM on Windows XP, 2000 and NT 4 using Open Source Tools
- Windows NT Password Dump Utility

7 comentarios:

JaviZ dijo...

Muy buena data!

salu2,
javi

MagnoBalt dijo...

Buen articulo como siempre, con el toque profesional.
Saludos

Nirvana FC dijo...

Muy buen articulo!!
me encanto!!

Anónimo dijo...

me salvaste de un 0.0 en el tema de Recuperacion de contraseñas de gestion de redes.. buena tu info

|_ocutus dijo...

esta bueno el articulo, cuando tenga algo de tiempo lo pruebo. x si a alguien le interesa dejo link con otro metodo para obtener los mismos resultados pero sobre win con pwdumpx y cain:

http://locvtvs.blogspot.com/2008/10/como-apoderarse-de-1-dominio-o-active.html

Anónimo dijo...

mira la verdad que complicas medio al cuete las cosas.como consejo hagan lo siguiente:
1-bajajen el hirens boot cd(es un live cd con una pila de aplicaciones)
2-inicien desde el modo mini windows
3-usen el explorador de archivos y copien el archivo sam de la maquina en un pen driver y ya esta este archivo lo agarran en su maquina con el oph crack y listo lo desencriptan.
4-si quieren otra solucion usan el hirens bot y ahi mismo hay una aplicacion para crearse la cuenta con privilegios de administrador con un click.saludos by stargatespawn

d3m4s1@d0v1v0 dijo...

Utilizar un live-cd Linux para obtener los hashes no es más complicado. Si miras la receta resumida, son sólo 3 pasos. La forma que explicas es una manera diferente de hacer lo mismo, sólo que con otra herramienta.
Igualmente te agradezco por compartirla, no conocía hirens, lo voy a tener en cuenta.

Publicar un comentario