Home Hacking y Seguridad Windows Las contraseñas en Windows IV (Redes)

Ultimos Mensajes del Foro

Manual Aleatorio

La informatica y la guerra (PDF)
Documento que muestra diferentes mquinas de encriptacion y la explotacin de la informtica como arma de guerra
Leer más...

Webs Amigas

Las contraseñas en Windows IV (Redes) Imprimir E-mail
Hacking y Seguridad - Windows
Escrito por ssantos   
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.