Buscar
 
 

Resultados por:
 


Rechercher Búsqueda avanzada

Últimos temas
» En casa de Belén, de vacaciones
Dom Abr 03, 2011 2:48 am por Invitado

» CONTINUIDAD
Lun Sep 14, 2009 8:28 pm por alfonso

» Boletín diario de Seguridad de INTECO-CERT
Jue Ago 20, 2009 3:52 pm por son5minutos

» Vulnerabilidad crítica en Flash Player
Dom Jul 26, 2009 2:13 pm por son5minutos

» Adobe conocía su último "0 day" desde 2008
Dom Jul 26, 2009 2:12 pm por son5minutos

» Último Informe del CERT para PYMES y Ciudadanos de Inteco
Dom Jul 26, 2009 2:11 pm por son5minutos

» STILO
Dom Jun 28, 2009 2:45 pm por nenina

» CINE
Dom Jun 28, 2009 2:44 pm por nenina

» VIAJAR
Dom Jun 28, 2009 2:44 pm por nenina

» EMPLEO Y FORMACION
Dom Jun 28, 2009 2:43 pm por nenina

» MOVILES
Dom Jun 28, 2009 2:42 pm por nenina

» VIDEOJUEGOS
Dom Jun 28, 2009 2:41 pm por nenina

» SEGURIDAD
Dom Jun 28, 2009 2:40 pm por nenina

» EMPRENDE
Dom Jun 28, 2009 2:40 pm por nenina

» NOTICIASDOT PRO
Dom Jun 28, 2009 2:39 pm por nenina

» SOFTWARE LIBRE
Dom Jun 28, 2009 2:39 pm por nenina

» GADGETMANIA
Dom Jun 28, 2009 2:37 pm por nenina

» WEB 2.0
Dom Jun 28, 2009 2:37 pm por nenina

» MUNDO DIGITAL
Dom Jun 28, 2009 2:36 pm por nenina

» Averigua quién está conectado a tu ordenador
Dom Jun 21, 2009 12:11 pm por Gaillimh

Flujo RSS


Yahoo! 
MSN 
AOL 
Netvibes 
Bloglines 


Bookmarking social

Bookmarking social Digg  Bookmarking social Delicious  Bookmarking social Reddit  Bookmarking social Stumbleupon  Bookmarking social Slashdot  Bookmarking social Yahoo  Bookmarking social Google  Bookmarking social Blinklist  Bookmarking social Blogmarks  Bookmarking social Technorati  

Conserva y comparte la dirección de Foro en tu sitio de bookmarking social


Mitos y leyendas: Las contraseñas en Windows

Ver el tema anterior Ver el tema siguiente Ir abajo

Mitos y leyendas: Las contraseñas en Windows

Mensaje por Gaillimh el Dom Abr 27, 2008 8:45 pm

01/04/2008 Mitos y leyendas: Las contraseñas en Windows I (Tipos de ataques)

Vamos a escribir algunos textos más o menos técnicos sobre las
contraseñas en Windows. Existen diferentes mitos y leyendas que
pensamos no han sido explicados de forma directa (y sin aspavientos) en
la mayoría de la literatura que hemos leído al respecto. Publicaremos
de sencilla, una serie de artículos aclarando detalles que consideramos
interesantes sobre las contraseñas locales en Windows, sus puntos
fuertes y débiles.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.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ñasUno
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.Tipos de ataqueExisten
básicamente dos métodos con los que obtener estos hashes. Uno es
"offline" y tiene como barrera (evitable) una funcionalidad de Windows
de la que hablaremos en el futuro. Otra es "online" y muestra los
hashes tal cual.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.Esto
no impide realmente que alguien pueda hacerse con el archivo. 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. En este directorio se encontrará un archivo SAM de menor
peso que "el oficial" y con fecha de instalación del sistema. Esta 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".Una vez que se ha tenido acceso al archivo
en cuestión, sea con el método que sea, se puede "volcar" su interior
con herramientas como samdump, disponible de forma gratuita desde hace
años. En teoría, al volcar este archivo deberíamos obtener los hashes
LM y NTLM de las contraseñas. Pero esto no es así. 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.¿Por qué el Syskey no suele aportar realmente
seguridad? ¿Cómo funcionan realmente los hashes LM/NTLM? Lo
estudiaremos en profundidad en un próximo artículo.


Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3447/comentar


Sergio de los Santos
ssantos@hispasec.com


Última edición por Gaillimh el Dom Abr 27, 2008 8:50 pm, editado 1 vez

Gaillimh
Admin
Admin

Masculino
Cantidad de envíos : 4013
Edad : 52
Localización : Barcelona
Fecha de inscripción : 31/10/2007

Ver perfil de usuario http://www.pruebavihbarcelona.org

Volver arriba Ir abajo

Mitos y leyendas: Las contraseñas en Windows II (Syskey)

Mensaje por Gaillimh el Dom Abr 27, 2008 8:45 pm

09/04/2008 Mitos y leyendas: Las contraseñas en Windows II (Syskey)



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.Esto
es, como suele ser habitual, una buena idea mal utilizada. En la
práctica resulta un sistema de seguridad con ciertas
contraindicaciones. Tras aplicar ingeniería inversa, se descubrió e
hizo público el sistema de cifrado de Microsoft para Syskey y existen
programas de 'crackeo' que permiten saltarse este método de seguridad
sin mayor problema. Sin embargo, si Syskey se utiliza correctamente,
puede prácticamente eliminar la posibilidad de un ataque "offline" en
caso de que se robe el disco duro, se tenga acceso a él arrancando con
otro sistema operativo, etc.Posibilidades que ofrece SyskeySe
puede teclear 'syskey' (como administrador) en la línea de comandos
para comprobar que se tiene activo por defecto, normalmente sin ser
consciente (no hay forma de deshabilitarlo). Si se decide sacar
provecho real de Syskey, se debe saber que permite tres tipos de
almacenamiento diferentes para la contraseña maestra (con la que cifra
la SAM), pero muy pocos lo usan.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. ¿Solución ideal?Desventajas de SyskeyUn
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.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. Además los
disquetes son sistemas de almacenamiento obsoletos, tendentes a
desaparecer y propensos a fallos. Sin embargo, Syskey bien usado no
deja de ser una opción interesante a considerar en algunos escenarios,
pues de esta forma se elevaría el nivel de autenticación a dos
factores: sería necesario algo que se sabe (la contraseña normal de
Windows) y algo que se tiene (el disquete físico), reduciendo así
considerablemente la posibilidad de éxito en ataques "offline" y acceso
al sistema.Por defecto Syskey viene activado con la primera
opción. Una contraseña elegida por el sistema y almacenada en el
registro. Esto no es seguro desde el momento en que es pública la forma
de almacenarla y es posible, a través de un programa, conocerla.La llave bajo el felpudoCuando
la contraseña es almacenada en el registro (primera opción), lo hace
"repartida" en diferentes puntos del registro. Windows realiza unas
permutaciones de estos datos para ofuscarla. Existe una herramienta
llamada bkhive que permite la recuperación de la contraseña Syskey. Si
se obtiene este dato y el archivo SAM, se podrá eliminar la capa de
seguridad introducida por Syskey sin problemas y obtener los hashes
LM/NTLM de las contraseñas. Y a efectos prácticos, quien tiene acceso a
la SAM tiene acceso a esa zona del registro que almacena la clave
maestra Syskey. Es como instalar una cancela de seguridad adicional
ante la puerta de casa, pero esconder su llave bajo el felpudo.Por
tanto, aunque el Syskey se mantenga activo en un Windows, un atacante
podría acceder a través de cualquier sistema al disco duro (de nuevo
una distribución "Live" de Linux, o usar el disco duro en otra
máquina...), tener acceso al fichero SAM, usar bkhive para obtener el
Syskey, combinar ambos datos con samdump, obtener los hashes LM/NTLM y
emplear por fin la fuerza bruta contra ellos. Aunque parezca complejo,
es un proceso de un par de pasos automáticos con los programas
adecuados.Pero, una vez más ¿Por qué estos hashes LM/NTLM que en
última instancia usa Windows para almacenar sus contraseñas resultan
tan sencillos de romper con fuerza bruta? Lo veremos en una próxima
entrega.


Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3455/comentar


Sergio de los Santos
ssantos@hispasec.com


Última edición por Gaillimh el Dom Abr 27, 2008 8:49 pm, editado 1 vez

Gaillimh
Admin
Admin

Masculino
Cantidad de envíos : 4013
Edad : 52
Localización : Barcelona
Fecha de inscripción : 31/10/2007

Ver perfil de usuario http://www.pruebavihbarcelona.org

Volver arriba Ir abajo

Mitos y leyendas: Las contraseñas en Windows III (LM y NTLM)

Mensaje por Gaillimh el Dom Abr 27, 2008 8:47 pm

18/04/2008 Mitos y leyendas: Las contraseñas en Windows III (LM y NTLM)

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, 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:71759a1bb2web4da43e676d6b7190711:::

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

El cifrado LM (Lan Manager) 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. Uno de los pasos para calcular el hash LM
consiste en rellenar de '0' la contraseña hasta llegar a los 14
caracteres (en caso de que sea más corta) y partir el resultado en dos
trozos de 7 bytes cada uno (el segundo relleno de esos '0' si es
necesario). También convierte a mayúsculas todos los caracteres. Sobre
estos dos trozos aplica un algoritmo estándar (DES) para cifrar una
cadena arbitraria, conocida y fija (4b47532140232425) y los concatena.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.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.CuriosidadesDurante mucho
tiempo se dio por cierto que la contraseña óptima en Windows debía ser
de 14 caracteres. Primero porque antes de Windows 2000 (que permite
contraseñas de 127 caracteres) los cuadros de diálogo de NT que pedían
la contraseña, no dejaban escribir más de 14 letras.Y segundo
por la naturaleza propia de LM, que no soporta más de 14 caracteres.
Pero... si en Windows 2000 se aceptan más de 14 caracteres para la
contraseña, y el cifrado LM se ha mantenido hasta Vista por razones de
compatibilidad. ¿Qué pasaba entonces con el cifrado LM cuando la
contraseña estaba compuesta por más de 14 caracteres? ¿Cómo lo divide
internamente Windows para calcular el hash LM si éste necesita partirla
en dos trozos de 7 bytes cada uno? El protocolo LM rellena la
contraseña de ceros cuando es menor de 14 letras para poder partirla en
dos... ¿cómo dividir entonces en dos trozos de 7 caracteres una
contraseña de 15? Interesante pregunta para la que no existe respuesta.De
este tipo de contraseñas, simplemente, no se calcula el hash LM. En
estos casos el sistema operativo no almacena el hash LM, el algoritmo
no lo soporta. Además de mejorar la seguridad por el hecho en sí de
usar una contraseña de mayor longitud, dando una asombrosa vuelta de
tuerca, esto protege contra ataques de fuerza bruta.Windows,
cuando la contraseña tiene más de 15 caracteres, almacena la constante
aad3b435b51404eeaad3b435b51404ee como hash LM (resultado de aplicar el
cifrado LM a dos cadenas nulas de siete caracteres cada una y
concatenarlas), que también es equivalente a una contraseña nula. Como
la contraseña obviamente no es nula, los intentos de ataques contra el
hash fallarán sistemáticamente. Esto no significa que una contraseña de
más de 14 caracteres sea 'equivalente' a una contraseña nula. Aunque LM
indique que la contraseña es nula, si no lo es, lógicamente ahí está (a
su lado, literalmente) el hash NTLM para confirmar que no es así. Los
programas de fuerza bruta que busquen la contraseña en el hash LM no
funcionarán correctamente.En cualquier caso, siempre ha existido
la posibilidad de indicarle a Windows que no almacene el hash LM de la
contraseña (aunque sea de menos de 14 caracteres) en el sistema. Vista,
por defecto, no lo almacena.


Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3464/comentar

Más Información:

una-al-dia (01/04/2008) Mitos y leyendas: Las contraseñas en Windows I (Tipos de ataques)
http://www.hispasec.com/unaaldia/3447/mitos-leyendas-las-contrasenas-windows-tipos-ataq

una-al-dia (09/04/2008) Mitos y leyendas: Las contraseñas en Windows II (Syskey)
http://www.hispasec.com/unaaldia/3455/mitos-leyendas-las-contrasenas-windows-syskey


Sergio de los Santos
ssantos@hispasec.com

Gaillimh
Admin
Admin

Masculino
Cantidad de envíos : 4013
Edad : 52
Localización : Barcelona
Fecha de inscripción : 31/10/2007

Ver perfil de usuario http://www.pruebavihbarcelona.org

Volver arriba Ir abajo

Mitos y leyendas: Las contraseñas en Windows IV (Redes)

Mensaje por Gaillimh el Miér Abr 30, 2008 2:51 pm

Mitos y leyendas: 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?

Para presentarse en red también es necesario que el propio servidor se
autentique. Así el cliente que quiere acceder a los recursos sabe que no
le está enviando los hashes de las credenciales a cualquiera. Ambos
tienen que estar seguros de que el cliente y el servidor son quienes
dicen ser, así que el protocolo se complica. Para "solucionarlo" se
sigue un esquema de desafío respuesta. Más o menos, el cliente y el
servidor mantienen una conversación en el que uno manda un desafío, el
otro le da un tratamiento y lo devuelve. Si ambos obtienen el mismo
resultado, la autenticación es válida y así las contraseñas no han
pasado en claro por la red.

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.

Un atacante necesita el desafío que envió el servidor, y esta respuesta
(obtenidas quizás al esnifar el tráfico de red) para intentar aplicar la
fuerza bruta y sacar las credenciales en texto claro.

Autenticación desafío-respuesta

¿Cómo calcula el cliente esa combinación contraseña-desafío? Puede
utilizarse la combinación LM/NTLM para redes, o su versión avanzada
LMv2/NTLMv2 para redes. Al igual que el sistema almacena la contraseña
cifrada con dos algoritmos, Microsoft ha mantenido ambas posibilidades y
parejas de protocolos, unos más débiles que otros.

* 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.

Con esta última opción las contraseñas viajan de una forma mucho más
segura por las redes. Como de costumbre, sólo estuvo disponible a partir
de Windows 2000 (como servidor y cliente) y desactivado por defecto en
posteriores.

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.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3474/comentar

Más información:

una-al-dia (01/04/2008) Mitos y leyendas: Las contraseñas en Windows I (Tipos de ataques)
http://www.hispasec.com/unaaldia/3447/mitos-leyendas-las-contrasenas-windows-tipos-ataq

una-al-dia (09/04/2008) Mitos y leyendas: Las contraseñas en Windows II (Syskey)
http://www.hispasec.com/unaaldia/3455/mitos-leyendas-las-contrasenas-windows-syskey

una-al-dia (18/04/2008) Mitos y leyendas: Las contraseñas en Windows III (LM y NTLM)
http://www.hispasec.com/unaaldia/3464


Sergio de los Santos
ssantos@hispasec.com

Gaillimh
Admin
Admin

Masculino
Cantidad de envíos : 4013
Edad : 52
Localización : Barcelona
Fecha de inscripción : 31/10/2007

Ver perfil de usuario http://www.pruebavihbarcelona.org

Volver arriba Ir abajo

Re: Mitos y leyendas: Las contraseñas en Windows

Mensaje por Contenido patrocinado


Contenido patrocinado


Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.