Como bajar las contraseñas de Windows 7, Congelador Deep Frezee y Linux Ubuntu evidencia067
Contraseñas en Windows
Click here to load reader
-
Upload
javierasir2012 -
Category
Documents
-
view
70 -
download
1
description
Transcript of Contraseñas en Windows
USUARIOS Y CONTRASEÑAS EN
WINDOWS
2012
Javier García Cambronel SEGUNDO DE ASIR
22/01/2012
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
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.
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.
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.
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.
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)
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
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-
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.
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.
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
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.
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.
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
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.
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
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.