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.
ssantos@hispasec.com
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
Excelente. Muy interesante para quienes no somos conocedores de estos asuntos.