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

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

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


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

28/04/2007: Tres vulnerabilidades en Routers Nortel VPN
http://www.hispasec.com/unaaldia/3108

28/04/2006: Vulnerabilidad en diálogos de seguridad ActiveX de Internet Explorer
http://www.hispasec.com/unaaldia/2743

28/04/2005: Vulnerabilidad en Adobe Acrobat Reader 6.0
http://www.hispasec.com/unaaldia/2378

28/04/2004: Información y software de criptografía de libre distribución
http://www.hispasec.com/unaaldia/2012

28/04/2003: Virus, antivirus, y sensacionalismo mediático
http://www.hispasec.com/unaaldia/1646

28/04/2002: Problemas de seguridad en el servidor web Tomcat
http://www.hispasec.com/unaaldia/1281

28/04/2001: Actualización recomendada de Kernel Linux a 2.2.19
http://www.hispasec.com/unaaldia/916

28/04/2000: El contraespionaje británico se prepara para monitorizar Internet
http://www.hispasec.com/unaaldia/549

28/04/1999: RSA patenta un sistema para inteactuar entre criptosistemas de curvas elípticas
http://www.hispasec.com/unaaldia/183


-------------------------------------------------------------------
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)