18

Click here to load reader

Contraseñas en Windows

Embed Size (px)

DESCRIPTION

2012USUARIOS Y CONTRASEÑAS EN WINDOWSJavier García Cambronel SEGUNDO DE ASIR 22/01/2012[USUARIOS Y CONTRASEÑAS EN WINDOWS] 22 de enero de 2012RESUMENLAS CONTRASEÑAS EN WINDOWS I (ATAQUES) LAS CONTRASEÑAS EN WINDOWS II (SYSKEY) LAS CONTRASEÑAS EN WINDOWS III (TIPOS DE CIFRADO) LAS CONTRASEÑAS EN WINDOWS IV (REDES)DESCIFRANDO CONTRASEÑASCONTRASEÑA javiCONTRASEÑA javiergarcia CONTRASEÑA JavierGarcia CONTRASEÑA Javi.SeguridadSEGUNDO DE ASIRPágina 1[USUARIOS Y CONTRASEÑAS EN WIND

Citation preview

Page 1: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN

WINDOWS

2012

Javier García Cambronel SEGUNDO DE ASIR

22/01/2012

Page 2: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 1

RESUMEN

LAS CONTRASEÑAS EN WINDOWS I (ATAQUES)

LAS CONTRASEÑAS EN WINDOWS II (SYSKEY)

LAS CONTRASEÑAS EN WINDOWS III (TIPOS DE CIFRADO)

LAS CONTRASEÑAS EN WINDOWS IV (REDES)

DESCIFRANDO CONTRASEÑAS

CONTRASEÑA javi

CONTRASEÑA javiergarcia

CONTRASEÑA JavierGarcia

CONTRASEÑA Javi.Seguridad

Page 3: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 2

LAS CONTRASEÑAS EN WINDOWS I (ATAQUES) Cuando nos presentamos en una máquina Windows, la contraseña que proporcionamos

debe estar almacenada en algún lugar para que el sistema operativo la reconozca y bien nos

deje pasar, bien rechace el acceso. Almacenar la contraseña y compararla sin más con la que

proporciona el usuario, sería una muy mala política de seguridad. Cualquiera con acceso al

disco duro podría robar la contraseña en texto plano. Lo que se almacena en realidad es el

resultado de aplicar un algoritmo a la clave introducida. Esto da como resultado una "firma"

(o tradicionalmente llamado "hash"), un valor que en teoría sólo es producido por una

contraseña en concreto. Son firmas lo que siempre se comparará entre sí, nunca

contraseñas. En Windows, ese hash se encuentra físicamente en el archivo de nombre SAM

(Security Account Manager) para contraseñas locales y en el archivo ntds.dit del controlador

de dominio para los usuarios que se validan contra controladores de dominio. Nos

centraremos en las contraseñas locales.

ALGORITMOS

Para calcular los hashes que se almacenan en la SAM, Windows XP y anteriores utilizan por defecto dos

algoritmos para cifrar cada clave: LM (por compatibilidad hacia atrás) y NTLM, más avanzado y estándar.

Vista usa (por fin) sólo NTLM y no calcula ni almacena el inseguro LM por defecto. Un atacante necesitaría

tener acceso a estos hashes (uno, otro, o los dos) para intentar calcular a partir de ellos las contraseñas en

texto claro (aplicándoles fuerza bruta, o métodos más sofisticados como las tablas rainbow).

WINDOWS NO AÑADE 'SAL' A LAS CONTRASEÑAS

Uno de los problemas históricos del almacenamiento de claves en Windows es que no 'saltea'

las contraseñas. No añade, como UNIX por ejemplo, un trozo aleatorio de caracteres a la hora

de calcular el hash. Con esto se evitaría que una misma contraseña de dos usuarios distintos,

produjese una misma firma. Esto supone un problema de seguridad, porque si un atacante de

Windows tiene acceso a estos hashes y dos son iguales, puede tener la certeza de que esos dos

usuarios tienen la misma contraseña, incluso si no sabe cuál.

Page 4: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 3

TIPOS DE ATAQUE

VOLCADO DE LOS HASHES "ONLINE"

Una forma de obtener los hashes de las

contraseñas es conectarse al proceso

LSASS (Local Security Authority

Subsystem) como administrador (o

alguien con permisos equivalentes) y

volcarlos. LSASS es el proceso que

autoriza y maneja todo el tinglado de las

contraseñas introducidas en Windows.

Mantiene una copia en memoria de

estas firmas contra las que compara y

valida para ofrecer el token de

credenciales correspondiente.

Conectarse a este proceso y volcar los

hashes "en vivo" en memoria no es

complicado gracias a programas como

pwdump, que en sus distintas versiones,

permite engancharse al proceso y

mostrar los hashes de todos los usuarios

locales del sistema.

Este método mostrará en claro el hash

LM y NTLM con el que Microsoft

compara todas las contraseñas que le

introducimos y ahora sí se podrá realizar

un sencillo ataque de fuerza bruta contra

ellos.

VOLCADO DE LOS HASHES "OFFLINE"

Si no se tiene acceso al proceso en memoria, bien porque el sistema

esté apagado, bien porque no se disfruten de los permisos necesarios,

existen otros métodos. Como hemos dicho al principio, un lugar

especialmente delicado en Windows (equivalente al etc/passwd de los

sistemas basados en UNIX) se ubica en

%systemroot%\system32\config\sam. En todo momento el archivo

está manejado y bloqueado por el proceso de sistema por lo que no

puede ser movido, copiado o accedido mientras el ordenador esté en

marcha, ni siquiera por el administrador.

Existen muchas maneras de llegar a ese fichero sin pasar por Windows.

Arrancar en un sistema Linux alojado en otra partición, o cualquier

otra forma de montar particiones NTFS... (Live Cds, por ejemplo). Otros

métodos consisten en buscar otros archivos SAM diseminados por el

disco duro. Microsoft guarda una copia de seguridad del archivo en

varios directorios, como por ejemplo en %systemroot%\repair cuando

el sistema es instalado. Este SAM "de repuesto" no se modificará y

contendrá la primera contraseña que se le indicó a Windows, aunque

el usuario haya modificado la clave de administrador posteriormente.

Este archivo no está tomado por ningún proceso, se puede leer por

cualquiera, por tanto es necesario vigilar especialmente los permisos

NTFS para controlar su acceso.

También puede existir una copia de la SAM en

%systemroot%\winnt\system32\config\sam.bak, que tampoco se

encuentra bloqueada por ningún proceso. Por último, si el

administrador ha realizado copias de seguridad, es posible encontrar

comprimido un %systemroot%\windows\repair\sam._ que se puede

expandir con el comando de Microsoft "expand".

A partir de Windows 2000, Microsoft utiliza por defecto el sistema

adicional de cifrado Syskey. Samdump volcará una versión a su vez

cifrada de los verdaderos algoritmos de cifrado de Microsoft LM y

NTLM. Con Syskey como medida adicional de seguridad sobre el

sistema que almacena las contraseñas, Microsoft introdujo una capa

más de seguridad, un cifrado de la SAM que dificulta (no demasiado si

no se utiliza bien) los ataques "offline" de fuerza bruta o diccionario

sobre este archivo.

Syskey estaba destinado a evitar estos ataques (pues cifra sobre

cifrado) pero en la práctica, ni Syskey ni los cifrados LM/NTLM han

aportado realmente seguridad adicional. Se sigue dependiendo de la

fortaleza de la contraseña que elija el usuario.

Page 5: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 4

LAS CONTRASEÑAS EN WINDOWS II (SYSKEY)

¿QUE ES SYSTEM KEY?

Ante el problema que supuso el pobre sistema de cifrado local de las contraseñas (LM y

NTLM), Microsoft introdujo una mejora en forma de parche para Windows NT y de serie para

Windows 2000 y posteriores. El sistema se llamó "Syskey" (System key) y añade una nueva

capa de seguridad. Aunque todos los Windows actuales lo utilizan y mantienen activo,

Syskey es una de las funcionalidades menos conocidas. Básicamente, se cifra de nuevo con

una contraseña maestra (System key) las firmas o hashes LM y NTLM almacenados en la

SAM para intentar protegerlos.

POSIBILIDADES QUE OFRECE SYSKEY

Opción 1: La contraseña Syskey para cifrar la SAM puede ser almacenada en el registro a

través de una algoritmo de ocultación ideado por Microsoft. La contraseña es elegida por el

propio sistema y el usuario no tiene por qué conocerla. El algoritmo de ocultación de la

contraseña maestra no es en absoluto complejo y ha sido descifrado y hecho público. Esta es

la opción que usan todos los Windows por defecto.

Opción 2: Se le puede indicar al sistema que nos pida la contraseña maestra al arrancar

Windows. De esta forma el administrador elije la "System key" y se tendrá que utilizar tanto

esta clave maestra como la contraseña habitual de usuario para poder presentarse. Doble

autenticación.

Opción 3: Por último, se puede almacenar la clave maestra en un disquete. No la pedirá al

iniciar Windows, la tomará directamente del disquete introducido y el sistema no arrancará

si no está presente.

Estas dos últimas opciones son las más seguras, pues al no permanecer la "System key" en

ningún archivo, un atacante con acceso al disco duro (o a la SAM) tendría también que

conseguir de alguna forma esa contraseña maestra, ya sea su valor o el disquete que la

aloja.

Page 6: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 5

DESVENTAJAS DE SYSKEY

En caso de almacenar la contraseña maestra en disquete sería posible dejarlo en la

disquetera y el sistema lo leería automáticamente, pero aunque más cómodo, también

implica que si se deja introducido sin vigilancia, no se consigue ninguna mejora de seguridad

real.

Un importante impedimento es que si se activa alguna de estas

dos últimas opciones, al arrancar, el sistema no "funcionará" en

red hasta que no se le indique esa contraseña maestra. Arranca

lo mínimo pero sin 'conectividad'. Una vez introducida la Syskey,

levanta la red y pide la contraseña 'normal'. Es un problema para

un servidor que se reiniciase a distancia, no podríamos

conectarnos a él hasta que alguien físicamente introdujese la

contraseña maestra, pues no arrancaría por ejemplo el Terminal

Server ni cualquier otro servicio definido.

Page 7: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 6

LAS CONTRASEÑAS EN WINDOWS III

Microsoft ha mejorado gradualmente la seguridad de su fichero SAM, pero también ha

mantenido la compatibilidad hacia atrás con sistemas inherentemente inseguros como

Windows 9x. Con la cada vez mayor sofisticación de herramientas capaces de atacar por

fuerza bruta los hashes LM y NTLM, el cifrado (sobre todo el LM) se ha vuelto virtualmente

inútil si la contraseña no es realmente entrópica y compleja. En Vista y en Windows 7, por

fin, se ha eliminado al menos el eslabón más débil, el hash LM.

Si se estudia el resultado de un volcado online u offline (tras 'saltarse' el syskey) de la SAM,

veremos algo así:

Administrador:500:42f29043y123fa9c74f23606c6g522b0:71759a1bb2web4da43e676d6b719

0711:::

que oculta en realidad el hash LM de la contraseña (42f29043y123fa9c74f23606c6g522b0) y

el hash NTLM (71759a1bb2web4da43e676d6b7190711)

Page 8: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 7

TIPOS DE CIFRADO

EL CIFRADO LM (LAN MANAGER)

EL CIFRADO NTLM (NTLAN MANAGER)

NTLM supone el segundo "intento" de Microsoft por mejorar el protocolo de las

contraseñas. Por fin diferencia entre mayúsculas y minúsculas e internamente es más

simple y robusto: calcula el hash cifrando con el estándar MD4 tras una pequeña

modificación del valor hexadecimal de la contraseña.

Pero por muchas mejoras que introduzca, NTLM queda anulado. Porque por defecto las

contraseñas son almacenadas y utilizadas en los dos formatos, el arcaico LM y NTLM, juntas

en el mismo SAM. Un ejemplo claro de cómo la seguridad es tan fuerte como el más débil

de sus eslabones

Como dijimos, la SAM almacena dos cifrados por contraseña, LM y NTLM. LM es débil e inseguro por

diseño, y además, teniendo en cuenta la potencia de los ordenadores actuales capaces de probar

cientos de miles de contraseñas por segundo, su 'cifrado' es virtualmente inútil. LM no aprovecha

bien los caracteres de las contraseñas y además comete otra serie de fallos importantes.

El algoritmo comete una serie de errores imperdonables, incluso para la época en la que fue

diseñado. Convertir todo a mayúsculas permite a los programas de fuerza bruta atacar directamente

utilizando mayúsculas y reduciendo así el tiempo de cálculo, disminuye considerablemente las

combinaciones. Pero lo más grave es que el hecho de partir la contraseña en dos, permite a los

programas de fuerza bruta, dividir el trabajo y actuar en paralelo sobre ambos trozos. Así es que por

ejemplo, en una contraseña de 10 caracteres, un programa de fuerza bruta tendrá que atacar en

realidad dos partes diferentes: una contraseña de siete caracteres y otra de tres, casi trivial de

adivinar. Un usuario con una contraseña de 14 caracteres estaría casi igual de expuesto que uno que

utilizase una de 7 caracteres de longitud, pues en vez de elevar exponencialmente el tiempo de

ataque, sólo se tardaría el doble (dos trozos de siete en vez de uno) o el mismo tiempo si se trabaja

en paralelo. Obviar la diferenciación entre mayúsculas y minúsculas tampoco resulta, en absoluto,

una buena idea

Page 9: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 8

LAS CONTRASEÑAS EN WINDOWS IV (REDES) Las contraseñas en Windows no sólo se utilizan para presentarse ante un sistema en local.

Deben viajar por la red para mostrar las credenciales a sistemas remotos en los que se confía

o al servidor de dominio que realmente gestiona y contiene los datos del usuario. Este

escenario es muy común en redes internas. El usuario debe validarse contra el controlador

de dominio, y también quizás contra su servidor de correo o su servidor proxy o una unidad

compartida en otro Windows. Obviamente las contraseñas no viajan en texto claro por la

red, aunque sea interna. ¿Cómo les demostramos que somos quienes decimos ser?

EL PROTOCOLO NTLM EN REDES

Sin ánimo de añadir confusión, al protocolo de intercambio desafío-respuesta utilizado

también se le llama NTLM. Los paquetes del protocolo NTLM enviados por las máquinas de

Microsoft pueden ser fácilmente identificados porque todos comienzan con la cabecera

"NTLMSSP". Por ejemplo, así es como los programas que esnifan credenciales en red saben

que se está negociando una autenticación "a su alrededor".

Durante el protocolo de autenticación, se intercambian tres (tipos de) mensajes desafío-

respuesta. En lo que sin duda resultará un ejercicio de simplificación, sentaremos las bases

del protocolo:

* Mensaje 1: Con este mensaje empieza la conversación, y lo envía el cliente. Entre otras

cosas, en él viajan una serie de flags en los que el cliente le cuenta al servidor los distintos

tipos de características de cifrado y otros parámetros, para que los dos sepan qué es lo que

pueden soportar y esperar uno del otro. A continuación, le indica el nombre de máquina, de

dominio, de grupo de trabajo...

* Mensaje 2: Este es el que devuelve el servidor al cliente que se quiere autenticar. En él

viaja el desafío, que no es más que un trozo de datos aleatorios con el que el servidor desafía

al cliente: "Si sabes manipular este trozo de datos correctamente con tu contraseña,

entonces sé que eres quien dices ser".

* Mensaje 3: En él se encuentran las respuestas que ha calculado el cliente, esto es, el

cálculo de la combinación contraseña-desafío con el que el cliente pretende autenticarse.

Aquí entran en juego varias posibilidades. O bien se usa LM/NTLM o bien Lmv2/NTLMv2

para calcular estas respuestas.

AUTENTICACIÓN DESAFÍO-

Page 10: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 9

RESPUESTA

RESPUESTA LM/NTLM

La respuesta LM de un cliente ante un desafío es calculada de forma parecida a la firma o

hash LM usado para las contraseñas locales, pero un poco más enrevesada. La respuesta al

desafío está basada en el propio hash LM que almacena la SAM, por tanto, hay que partir de

esa firma para calcular la respuesta LM. Lo que el cliente hace en realidad es cifrarla y

mezclarla cifrada con el desafío enviado por el servidor. Así el servidor que envía el desafío

sabe que sólo un cliente que conozca la clave del usuario podría haber obtenido el mismo

resultado a partir del desafío que él ha enviado.

El proceso de la respuesta NTLM es muy parecido al de LM, más sencillo pero no por ello

menos eficaz. El proceso de respuesta NTLM también comienza con el hash NTLM de la

contraseña, este hash se rellena hasta los 21 bytes y es partido en tres trozos de 7 bytes.

Cada uno, después de sufrir un proceso de agrupación de binarios y bits de paridad da un

resultado con el se descifra el desafío utilizando cada trozo como clave DES.

RESPUESTA LMV2/NTLMV2

Esta respuesta se envía cuando tanto servidor como cliente están preparados para

soportarla (se lo confirman el uno al otro en el primer mensaje). Cuando este tipo de

respuesta está habilitado, la respuesta NTLM es sustituida por la NTLMv2 y la LM por la

respuesta LMv2. Lo que realmente representa una mejora con respecto a su anterior

versión, es que se utiliza una firma de tiempo y un desafío que también propone el cliente. A

modo de resumen, se puede destacar que se parte igualmente del hash NTLM de la firma de

la contraseña y se calcula el hash HMAC-MD5 del valor en unicode del nombre de usuario y

dominio en mayúsculas. Como clave se utiliza el hash NTLM. El resultado es el hash NTLMv2.

A estos datos, todos concatenados, se le añade el desafío y se vuelve a calcular HMAC-MD5

utilizando el hash NTLMv2 (calculado previamente) como clave.

LMv2 puede ser visto como un NTLMv2 en miniatura, pero sin firma de tiempo. Se calcula el

HMAC-MD5 utilizando el hash NTLMv2 como firma de los dos desafíos, el del servidor y uno

que genera el cliente para la ocasión.

AUTENTICACIÓN KERBEROS

Con Windows 2000 Microsoft introdujo además para su Directorio Activo un sistema

estándar de autenticación, Kerberos, mucho más avanzado que lo anteriormente descrito,

pero que no los sustituye. Para funcionar con autenticación Kerberos en una red, es

necesario un servidor de Kerberos (que coincide con el controlador de dominio). En entornos

de grupo de trabajo, por ejemplo, y en ciertas circunstancias bajo un dominio, se sigue

usando LM/NTLM o LMv2/NTLMv2. Además de Kerberos, para cuando no es posible usarlo,

se pueden configurar los servidores para obligarles que solo negocien la versión 2 del

protocolo de Microsoft y evitar así que las contraseñas viajen por la red y sean fácilmente

descifrables.

Page 11: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 10

DESCIFRANDO CONTRASEÑAS

CONTRASEÑA javi

SAMINSIDE

Con este programa logramos desencriptar la contraseña en un segundo más o menos, es

decir instantáneamente.

Con este programa también se produce el resultado casi instantáneamente.

Page 12: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 11

Con ophcrack hemos tardado 51,30 segundos en desencriptar la contraseña, aunque al final

nos la ha sacado como podemos ver en lo que más ha tardado ha sido en cargar las tablas,

quizás por ser la primera vez que ejecutamos el programa.

GPU-BRUTEFORCE

Con este programa que utiliza la potencia de nuestra tarjeta gráfica para desencriptar la

contraseña vemos que en un segundo ha sido capaz de sacárnosla

Page 13: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 12

CONTRASEÑA javiergarcia

SAMINSIDE

Aunque no podemos ver el tiempo en el que nos ha sacado la contraseña, ha tardado como

un minuto y medio.

Vemos como esta aplicación online no ha sido capaz de desencriptar la contraseña. Lo que

da a pensar que no esta hecha para contraseñas de tal longitud.

Page 14: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 13

Vemos que aquí ophcrack, se muestra imponente desencriptando la contraseña en

solamente doce segundos

GPU-BRUTEFORCE

Podemos observar que seguramente la mejor aplicación que existe para desencriptar

contraseñas por la fuerza bruta no ha podido con esta contraseña, seguramente al ser la

versión DEMO y estar muy limitada.

Page 15: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 14

CONTRASEÑA JavierGarcia

SAMINSIDE

Vemos que SAMInside se ha comportado perfectamente devolviéndonos la contraseña en

mas o menos dos minutos.

Como era de esperar no nos devuelve ningún resultado

Page 16: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 15

Este programa nos vuelve a sorprender con su rapidez descifrando la contraseña en tan solo

trece segundos y medio.

GPU-BRUTEFORCE

Y por último esta aplicación nos vuelve a decepcionar y no nos arroja ningún resultado

válido.

Page 17: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 16

CONTRASEÑA Javi.Seguridad

SAMINSIDE

Vemos como no es capaz de descifrar la contraseña y solo puede con parte de ella GURIDAD

lo cual ya es algo, pues si fuera algo con sentido con un poco de ingeniería social la

podríamos terminar de adivinar, en este caso al ser de clase, lo suyo seria probar con

seguridad ¿verdad? Y el nombre del usuario delante…… no es tan difícil ¿no?

Como era de esperar esta aplicación no nos da ningún resultado

Page 18: Contraseñas en Windows

USUARIOS Y CONTRASEÑAS EN WINDOWS[ ] 22 de enero de 2012

SEGUNDO DE ASIR Página 17

Y como en las demás ocasiones ophcrack, se muestra muy similar a SamInside, al que solo

gana en tiempo de ejecución cosa que por otra parte también es importante en este tipo de

programas.

GPU-BRUTEFORCE

Por último esta aplicación nos devuelve lo que viene siendo “NADA” ya que solo ha

funcionado en la primera prueba.