-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-------------------------------------------------------------------
Hispasec - una-al-día 18/04/2008
Todos los días una noticia de seguridad www.hispasec.com
-------------------------------------------------------------------

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.

Curiosidades

Durante 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/3463/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


Tal día como hoy:
-----------------

18/04/2007: Grupo de parches de abril para diversos productos Oracle
http://www.hispasec.com/unaaldia/3098

18/04/2006: Múltiples vulnerabilidades críticas en Mozilla (Firefox/Thunderbird)
http://www.hispasec.com/unaaldia/2733

18/04/2005: Cross-Site Scripting en RSA Authentication Agent for Web para IIS 5.2
http://www.hispasec.com/unaaldia/2368

18/04/2004: Un promedio de 28 programas espías en cada ordenador que accede a Internet
http://www.hispasec.com/unaaldia/2002

18/04/2003: Nueva vulnerabilidad en Snort
http://www.hispasec.com/unaaldia/1636

18/04/2002: Parche para aplicaciones Microsoft sobre Macintosh
http://www.hispasec.com/unaaldia/1271

18/04/2001: El servidor web iPlanet puede revelar información confidencial
http://www.hispasec.com/unaaldia/906

18/04/2000: El cifrado de Citrix ICA es inseguro
http://www.hispasec.com/unaaldia/539

18/04/1999: Parches para Red Hat
http://www.hispasec.com/unaaldia/173


-------------------------------------------------------------------
Claves PGP en http://www.hispasec.com/directorio/hispasec
-------------------------------------------------------------------
Bajas: mailto:unaaldia-request@hispasec.com?subject=unsubscribe
Altas: mailto:unaaldia-request@hispasec.com?subject=subscribe
-------------------------------------------------------------------
(c) 2008 Hispasec http://www.hispasec.com/copyright
-------------------------------------------------------------------

--- SoupGate-DOS v1.05
* Origin: Pasarela FTN-INet telnet://pucelabbs.dyndns.org:4000 (2:341/201.99)