Home Hacking y Seguridad Windows Autenticación LM, NTLM y Kerberos

Ultimos Mensajes del Foro

Manual Aleatorio

Problemas de seguridad y privacidad asociados al DNI electronico (PDF)
Desde su creacion el DNI electronico ha suscitado multiples polemicas, este documento trata los problemas de seguridad que trae consigo.
Leer más...

Webs Amigas

Autenticación LM, NTLM y Kerberos Imprimir E-mail
Hacking y Seguridad - Windows
Escrito por GuillermoD   

Cuando se va a acceder a un recurso remoto el servidor que tiene el recurso debe autenticar a quien se conecta, para luego poder autorizarlo (o no) a acceder al recurso.

Dependiendo del sistema operativo del cliente, del servidor, si se está en grupo de trabajo o dominio y del tipo de dominio se utilizará el protocolo más seguro que sea admitido por las partes que interactúan.

Los sistemas operativos Windows 9x incluido ME soportan solamente LM. Los Windows NT soportan LM y NTLM. Y los Windows 2000 y XP soportan LM, NTLM y Kerberos.

LM es LanManager y NTLM significa NT LanManager

Cuando un cliente Windows 9x se conecta a un servidor Windows 2000 el método de autenticación que tienen en común es LM, que desde el punto de vista seguridad es el más flojo. También a la inversa, si un Windows 2000 se conecta a un recurso compartido en un Windows 9x utilizará LM

Se debe tener en cuenta que Kerberos se utilizará únicamente si se dan estas condiciones:

  * El cliente es Windows 2000
  * El server es Windows 2000
  * La cuenta de máquina del cliente está en dominio Windows 2000
  * La cuenta de máquina del server está en dominio Windows 2000
  * Los canales seguros de comunicación se armaron con controladores de dominio Windows 2000. En un dominio mixto pueden haber controladores de dominio NT4

En cualquier otro caso se utilizará NTLM o LM.

NTLM y LM utilizan el método conocido como Challenge-Respose (Desafío-Respuesta) variando solamente las funciones matemáticas utilizadas, longitudes de claves y algunos mecanismos internos. Por ejemplo: las contraseñas en LM no son sensibles a mayúsculas-minúsculas; mientras que en NTLM sí lo son. NTLM es mucho más seguro que LM.

Cualquiera de los casos está basado en la técnica de “Secreto-Compartido”. Si sólo dos conocemos un secreto y yo soy uno, el que me demuestre que conoce el secreto tiene que ser el otro”. Llevado a términos de inicio de sesión: Si el Controlador de Dominio conoce la contraseña del usuario “Usuario1”, quien diga ser “Usuario1” y conozca la contraseña correspondiente, debe ser el usuario “Usuario1”.

 
Conceptos de autenticación LM y NTLM

Antes de acceder a un recurso compartido se efectúan varios procesos. Por ejemplo, a partir que un usuario envía la orden para acceder a \\server\recurso se efectúan los siguientes pasos:

  * Resolución de nombre a una dirección IP
  * Resolución de la dirección MAC del próximo salto (ARP)
  * Establecimiento de sesión TCP
  * Establecimiento de sesión NetBIOS (dependiendo de los sistemas operativos que intervienen)
  * Negociación SMB (Server Message Block)
  * Autenticación Challenge-Response
  * …

Porqué estamos viendo todos estos pasos: porque el mecanismo Challenge-Response abarca dos de estos pasos, la autenticación propiamente dicha y el paso previo (Negociación SMB).

SMB (Server Message Block) es el protocolo a nivel capa Aplicación usado en las redes Microsoft. Este protocolo viene desde el principio de las redes, pero ha evolucionado a través del tiempo en varios “dialectos” que han introducido mejoras. Pero por razones de compatibilidad, los nuevos sistemas operativos siempre “comprenden” a los anteriores. Durante esta “negociación de dialecto” el cliente envía la lista de dialectos que comprende, el server selecciona uno en común (normalmente el más nuevo) y devuelve esa información al cliente. Pero, acá viene lo más importante, conjuntamente con esa información envía el Challenge.

El Challenge es una secuencia de caracteres de una longitud determinada pero no previsible en cuanto a su contenido, generado por el server y enviado al cliente

El cliente conoce la contraseña del usuario y guarda en memoria protegida el resultado de pasar esta contraseña por una función establecida de Hash.

Cuando recibe el Challenge, el cliente utiliza este Hash más otras funciones matemáticas para encriptar el Challenge recibido, y el resultado es enviado al server. Esto es el Response, que incluye el nombre de usuario.

El server recibe el Response, dadas que las funciones de Hash y funciones matemáticas están estandarizadas entre cliente y servidor, procesa el response, igual que el cliente pero en sentido inverso (para desencriptar) y con la versión local que tiene de la contraseña de ese usuario.

Si el resultado de desencriptar el Response, con la versión propia de la contraseña, es igual al Challenge, el resultado es que el usuario demostró conocer la contraseña correcta. Y sin enviarla.

 

Conceptos de Autenticación Kerberos

Kerberos es un personaje mitológico caracterizado por un perro de tres cabezas, y le da nombre a un método de autenticación desarrollado sobre Unix y estandarizado (RFC 1510), que se basa en tres componentes: el cliente, el servidor y el servidor de Kerberos. En este caso utilizaremos los conceptos de cliente y servidor en su versión más general. Cliente es donde está el usuario que quiere acceder al recurso remoto, y servidor será donde está el recurso remoto; no necesariamente son sistemas operativos de cliente y de servidor. El servidor de Kerberos en Windows 2000 es un Controlador de Dominio. Todos los controladores de dominio Windows 2000 proveen el servicio Kerberos a la red.

Kerberos está basado en la técnica de “Secreto-Compartido”. Si tanto cliente, como usuario y como server, tienen cuenta en el dominio hay un secreto-compartido entre cada uno de ellos y el Controlador de Dominio.

¿Se dan cuenta cuál es? es algo que es función de la contraseña de cuenta que cada uno tiene en el dominio. El problema es que cuando el usuario, desde un cliente, necesita contactar al server, debe tener un secreto-compartido con el server. Es decir debe generarse un secreto-compartido entre el usuario y el server (que técnicamente se llama Session Key).

Cuando el Usuario1, desde el Cliente1, tiene que conectarse al Server1, le pide al servidor de Kerberos que genere un secreto-compartido para Usuario1-Server1. El servidor de Kerberos, lo genera en forma aleatoria, pero tiene un problema, debe hacérselo llegar tanto al cliente como al server, y además no lo puede enviar desencriptado porque en ese caso ya no sería “secreto”.

Voy a hacer una primera aproximación posible, que aunque no es la usada ayuda a comprender. Kerberos genera el secreto y envía la información al Usuario1 por un lado y a Server1 por otro. Esta técnica aunque es fácil de comprender tiene sus inconvenientes. Por esos temas de tráfico de las redes podría pasar que el secreto llega al usuario, él trata de conectarse al server usando este secreto recibido, pero el server todavía no lo recibió desde Kerberos. Además el server debería guardar en memoria el secreto correspondiente a cada usuario que se conecta, lo cual sería muy caro desde el punto de vista consumo de recursos, ya que habría que destinar importante cantidad de memoria protegida no paginable para almacenar los secretos de muchos usuarios, que podrían no necesitarse ya que los usuarios no siempre se conectan. Por lo que la solución implementada es diferente. La verdadera es que se envía el secreto dos veces al cliente, una en un formato que lo puede comprender él, la otra en un formato que sólo puede comprender Server1. Vamos a usar un poco de expresiones:

KU-K = Secreto compartido entre Usuario1 y Kerberos
KS-K = Secreto compartido entre Server1 y Kerberos
KU-S = Secreto compartido entre Usuario1 y Server1

Primero Usuario1 le pide al servidor de Kerberos autenticación para acceder a Server1, enviándole:

Usuario1; KU-K{ Usuario1; “quiero acceder a Server1”} (*)

(*) K{datos} significa, datos encriptados con clave K

Con su conocimiento de KU-K Kerberos desencripta la información, y al ver que coinciden las versiones de Usuario1 que vienen desencriptada y encriptada, le permite reconocer que Usuario1 conoce la contraseña correcta, lo autentica. Genera el secreto compartido entre Usuario1 y Server1 (KU-S) en forma aleatoria, y se lo envía al cliente de la siguiente forma:

KU-K { KU-S “para Server1”}; Ticket= KS-K{ KU-S “para Cliente1”}

El Ticket no es comprensible para el cliente o Usuario1, ya que está encriptado con KS-K que es el secreto compartido entre Server1 y Kerberos.

Cuando el Usuario1 va a acceder al Server1, envía la siguiente información a Server1:

Usuario1; KU-S{ Usuario1}; Ticket= KS-K{ KU-S “para Cliente1”}

Server1 conoce KS-K por lo tanto puede desencriptar el Ticket, de donde obtiene KU-S que le permite acceder a la primera parte y verificar que la versión encriptada y desencriptada de Usuario1 son iguales, por lo tanto Usuario1 fue autenticado por el mismo Kerberos en el cual el confía, y por lo tanto va a acceder ahora al proceso de autorización de Usuario1.

Es importante notar que con Kerberos, Server1 pudo autenticar a Usuario1, sin necesidad de contactar él al controlador de dominio.

Este Ticket entregado al Usuario1 para acceder a Server1, por Kerberos, tiene un determinado tiempo de utilización. Si el Usuario1 se tiene que reconectarse a Server1, dentro del período de validez del mismo, no necesita sacar otro, sino que reenvía el mismo que usó con anterioridad. Estos Tickets tienen periodo de validez y período de renovación: por cuánto tiempo se pueden usar, y por cuánto tiempo se pueden renovar, sin necesidad de obtener uno totalmente nuevo (por omisión 10 Hs y 7 Días)

De todas formas, la realidad es un poco más compleja, vamos a mostrar algunas cosas más que hace Kerberos por la seguridad.

En el esquema que vimos recién hay un posible problema de seguridad, ya que cada vez que necesitamos un ticket estamos exponiendo en la red, algo que es función de la contraseña de usuario (KU-K) lo cual no es bueno. Para solucionar esto Kerberos utiliza un doble nivel de seguridad. La primera vez obtenemos un Ticket para acceder al Servicio de Distribución de Tickets (KDC=Kerberos Distribution Center) que sí expone KU-K Pero el resto de los tickets, para acceder a los recursos, los obtenemos usando este último, que no contiene nada en relación a la contraseña del usuario. Notemos que si dejamos los valores por omisión de renovación de tickets de Kerberos, necesitamos obtener sólo un ticket por semana en el que expondremos en la red algo función de la contraseña, ya que éste se renueva cada 10 Hs (nadie trabaja más de 10 Hs al día ) y se obtiene uno nuevo cada 7 días.

Y lo último pero importante, Kerberos puede implementar, y la implementación Microsoft lo hace, autenticación mutua. No sólo Usuario1 es autenticado por Server1, sino que además Usuario1 autentica a Server1. Esto es sumamente importante porque Usuario1 podría almacenar datos confidenciales en un supuesto “Server1” que realmente no lo es.

Cuando Usuario1 envía los pedidos de autenticación, tanto a Kerberos, como a Server1, incluye un campo que es un “timestamp”; un número representativo de día y hora (incluye hasta milésimas de segundo) en que se efectúa el pedido. Veámoslo para el caso de pedido de Usuario1 a Server1:

Usuario1; KU-S{ Usuario1; TimeStamp}; Ticket= KS-K{ KU-S “para Cliente1”}

Para que Server1 pueda probar su identidad le tiene que demostrar a Usuario1 que pudo desencriptar la información recibida. Por lo cual, cuando desencripta la primera parte, para autenticar a Usuario1, obtiene también el TimeStamp, el cual es reenviado desde Server1 a Usuario1:

Server1; KU-S{Server1; TimeStamp}

Cabe aclarar que este TimeStamp, es el que envió Usuario1, no del Server1. Cuando Usuario1 usando KU-S desencripta la información, controla que el TimeStamp sea el mismo que él envió.

Este último conocimiento nos permite conocer porqué Kerberos es sensible a la sincronización de los relojes de los equipos. En la implementación de Kerberos que hace Microsoft, los servers guardan los tickets por 5 minutos (valor por omisión), por lo que le permite comprobar que no se reciban 2 tickets del mismo usuario con el mismo TimeStamp. Si esto pasara estamos ante la presencia de alguien que capturó el tráfico de red y lo está reenviando, intentando hacerse pasar por quien no es. Si el TimeStamp enviado por el usuario difiere en más de 5 minutos de la hora del server, el mismo envía mensaje de acceso denegado, no autentica al usuario.