NTLM

En una red Windows, NT (New Technology) LAN Manager (NTLM) es un conjunto de protocolos de seguridad de Microsoft destinados a proporcionar autenticación, integridad y confidencialidad a los usuarios.[1]​[2]​[3]​ NTLM es el sucesor del protocolo de autenticación en Microsoft LAN Manager (LANMAN), un producto anterior de Microsoft. El conjunto de protocolos NTLM se implementa en un Security Support Provider, que combina el protocolo de autenticación de LAN Manager y los protocolos de sesión NTLMv1, NTLMv2 y NTLM2 en un solo paquete. Si estos protocolos se usan o se pueden usar en un sistema se rige por la configuración de directivas de grupo, para lo cual las diferentes versiones de Windows tienen diferentes configuraciones predeterminadas.

Las contraseñas NTLM se consideran débiles porque pueden forzarse muy fácilmente con hardware moderno.[4]​

Protocolo

NTLM es un protocolo de autenticación de desafío-respuesta que utiliza tres mensajes para autenticar a un cliente en un entorno orientado a la conexión (sin conexión es similar) y un cuarto mensaje adicional si se desea integridad.[5]​[6]​[7]​[8]​

  1. Primero, el cliente establece una ruta de red al servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades.[9]​
  2. A continuación, el servidor responde con CHALLENGE_MESSAGE que se utiliza para establecer la identidad del cliente.[10]​
  3. Finalmente, el cliente responde al desafío con un AUTHENTICATE_MESSAGE.[11]​

El protocolo NTLM usa uno o los dos valores de contraseña hash, ambos almacenados también en el servidor (o controlador de dominio), y que por falta de salado son equivalentes a contraseñas, lo que significa que si coges el valor hash del servidor, puedes autenticarte sin conocer la contraseña real. Los dos son el hash LM (una función basada en DES que se aplica a los primeros 14 caracteres de la contraseña convertidos al juego de caracteres tradicional de PC de 8 bits para el idioma) y el hash NT (MD4 de la contraseña Little Endian UTF-16 Unicode). Ambos valores hash son de 16 bytes (128 bits) cada uno.[12]​

El protocolo NTLM también utiliza una de dos funciones unidireccionales, dependiendo de la versión de NTLM; NT LanMan y NTLM versión 1 utilizan la función unidireccional LanMan basada en DES (LMOWF), mientras que NTLMv2 utiliza la función unidireccional basada en NT MD4 (NTOWF).[12]​[13]​[2]​

NTLMv1

El servidor autentica al cliente enviándole un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación en la que intervienen el desafío y un secreto compartido entre el cliente y el servidor, concretamente uno de los dos hashes de contraseña descritos anteriormente. El cliente devuelve el resultado de 24 bytes del cálculo. De hecho, en NTLMv1 los cálculos se realizan normalmente utilizando ambos hashes y se envían ambos resultados de 24 bytes. El servidor verifica que el cliente haya calculado el resultado correcto y, a partir de esto, deduce la posesión del secreto y, por tanto, la autenticidad del cliente.

Ambos hashes producen cantidades de 16 bytes. Se añaden cinco bytes de ceros para obtener 21 bytes. Los 21 bytes se separan en tres cantidades de 7 bytes (56 bits). Cada una de estas cantidades de 56 bits se utiliza como clave para cifrar con DES el desafío de 64 bits. Los tres encriptaciones del desafío se reúnen para formar la respuesta de 24 bytes. Tanto la respuesta que usa el hash LM como el hash NT se devuelven como respuesta, pero esto es configurable.

C = Desafío de servidor de 8 bytes, aleatorio
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
Respuesta = DES(K1,C) | DES(K2,C) | DES(K3,C)

NTLMv2

NTLMv2, introducido en Windows NT 4.0 SP4[14]​ (y soportado de forma nativa en Windows 2000), es un protocolo de autenticación desafío-respuesta. Está pensado como un sustituto reforzado criptográficamente de NTLMv1, que mejora la seguridad de NTLM endureciendo el protocolo contra muchos ataques de suplantación de identidad y añadiendo la posibilidad de que un servidor autentique al cliente.[1]​[15]​[16]​

NTLMv2 envía dos respuestas a un desafío de servidor de 8 bytes. Cada respuesta contiene un hash HMAC - MD5 de 16 bytes del desafío del servidor, un desafío del cliente generado total o parcialmente de forma aleatoria y un hash HMAC-MD5 de la contraseña del usuario y otra información de identificación. Las dos respuestas difieren en el formato del desafío del cliente. La respuesta más corta utiliza un valor aleatorio de 8 bytes para este desafío. Para verificar la respuesta, el servidor debe recibir como parte de la respuesta el desafío del cliente. Para esta respuesta más corta, el desafío de cliente de 8 bytes añadido a la respuesta de 16 bytes forma un paquete de 24 bytes que es coherente con el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En cierta documentación no oficial (p. ej. DCE/RPC sobre SMB, Leighton) esta respuesta se denomina LMv2.

La segunda respuesta enviada por NTLMv2 utiliza un desafío de cliente de longitud variable que incluye (1) la hora actual en formato NT Time, (2) un valor aleatorio de 8 bytes (CC2 en el cuadro de abajo), (3) el nombre de dominio y (4) algunas cosas de formato estándar. La respuesta debe incluir una copia de este desafío del cliente, por lo que es de longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.

Tanto LMv2 como NTv2 hacen un hash del desafío del cliente y el servidor con el hash NT de la contraseña del usuario y otra información de identificación. La fórmula consiste en comenzar con el hash NT, que se almacena en el SAM o AD, y continuar con el hash, utilizando HMAC - MD5, el nombre de usuario y el nombre de dominio. En el cuadro siguiente, X representa el contenido fijo de un campo de formato.

SC = desafío de servidor de 8 bytes, aleatorio
CC = desafío de servidor de 8 bytes, aleatorio
CC* = (X, tiempo, CC2, nombre de dominio)
v2-Hash = HMAC-MD5(NT-Hash, nombre de usuario, nombre de dominio)
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)
respuesta = LMv2 | CC | NTv2 | CC*

Sesión NTLM2

El protocolo de sesión NTLM2 es similar a MS-CHAPv2.[17]​ Consiste en la autenticación de NTLMv1 combinada con la seguridad de sesión de NTLMv2.

En resumen, se aplica el algoritmo NTLMv1, excepto que se agrega un desafío de cliente de 8 bytes al desafío de servidor de 8 bytes y se aplica un hash MD5. La mitad menos significativa de los 16 bytes del resultado del hash es el desafío utilizado en el protocolo NTLMv1. El desafío de cliente se devuelve en una espacio de 24 bytes en el mensaje de respuesta, mientras que la respuesta calculada de 24 bytes se devuelve en el otro espacio.

Se trata de una forma reforzada de NTLMv1 que mantiene la capacidad de utilizar la infraestructura del controlador de dominio existente, pero evita un ataque de diccionario por parte de un servidor fraudulento. Para una X fija, el servidor calcula una tabla donde la ubicación Y tiene un valor K tal que Y=DES_K(X) . Sin que el cliente participe en la elección del desafío, el servidor puede enviar X, buscar la respuesta Y en la tabla y obtener K. Este ataque se puede hacerse práctico utilizando tablas arco iris.[18]​

Sin embargo, la infraestructura NTLMv1 existente permite que el par desafío/respuesta no sea verificado por el servidor, sino que lo envíe a un controlador de dominio para su verificación. Utilizando la sesión NTLM2, esta infraestructura sigue funcionando si el servidor sustituye el desafío por el hash de los desafíos del servidor y del cliente.

NTLMv1
 Cliente<-Servidor: SC
 Cliente->Servidor: H(P,SC)
 Servidor->DomCntl: H(P,SC), SC
 Servidor<-DomCntl: sí o no

NTLM2 Session
 Cliente<-Servidor: SC
 Cliente->Servidor: H(P,H'(SC,CC)), CC
 Servidor->DomCntl: H(P,H'(SC,CC)), H'(SC,CC)
 Servidor<-DomCntl: sí o no

Disponibilidad y uso de NTLM

Desde 2010, Microsoft ya no recomienda NTLM en las aplicaciones:[19]​

Los implementadores deben tener en cuenta que NTLM no admite ningún método criptográfico reciente, como AES o SHA-256. Utiliza comprobaciones de redundancia cíclica (CRC) o MD5 para la integridad y RC4 para el cifrado. La obtención de una clave a partir de una contraseña se especifica en RFC1320 y FIPS46-2. Por lo tanto, generalmente se recomienda a las aplicaciones que no utilicen NTLM.

A pesar de estas recomendaciones, NTLM todavía se implementa ampliamente en los sistemas.[cita requerida] Una de las principales razones es mantener la compatibilidad con los sistemas más antiguos. Sin embargo, se puede evitar en algunas circunstancias. Microsoft ha agregado el hash NTLM a su implementación del protocolo Kerberos para mejorar la interoperabilidad (en particular, el tipo de cifrado RC4-HMAC). Según un investigador independiente, esta decisión de diseño permite engañar a los controladores de dominio para que emitan un ticket Kerberos a un atacante si se conoce el hash NTLM.[20]​ Microsoft adoptó Kerberos como el protocolo de autenticación preferido para Windows 2000 y los subsiguientes dominios de Active Directory.[16]​ Kerberos se usa normalmente cuando un servidor pertenece a un dominio de Windows Server . Microsoft recomienda a los desarrolladores que no utilicen Kerberos ni el proveedor de soporte de seguridad (SSP) NTLM directamente.[21]​

Su aplicación no debe acceder directamente al paquete de seguridad NTLM; en su lugar, debe usar el paquete de seguridad Negociar. Negotiate permite que su aplicación aproveche los protocolos de seguridad más avanzados si son compatibles con los sistemas involucrados en la autenticación. Actualmente, el paquete de seguridad Negotiate selecciona entre Kerberos y NTLM. Negotiate selecciona Kerberos a menos que no pueda ser utilizado por uno de los sistemas involucrados en la autenticación.

Uso del proveedor de soporte de seguridad NTLM

El NTLM SSP se utiliza en las siguientes situaciones:

  • El cliente se está autenticando en un servidor que no pertenece a un dominio o no existe ningún dominio de Active Directory (comúnmente conocido como "grupo de trabajo" o "punto a punto")
    • El servidor debe tener habilitada la función de "uso compartido protegido por contraseña", que no está habilitada de forma predeterminada y que es mutuamente excluyente con HomeGroup en algunas versiones de Windows.
    • Cuando el servidor y el cliente pertenecen al mismo grupo doméstico (HomeGroup), se utilizará un protocolo similar a Kerberos, llamado Autenticación Usuario a Usuario basada en Criptografía de Clave Pública, en lugar de NTLM.[22]​ HomeGroup es probablemente la forma más fácil de compartir recursos en una red pequeña y requiere una configuración mínima, incluso en comparación con la configuración de algunos usuarios adicionales para poder usar el uso compartido protegido por contraseña, lo que puede significar que se usa mucho más que el uso compartido protegido por contraseña en Redes pequeñas y redes domésticas.
  • Si el servidor es un dispositivo compatible con SMB, como dispositivos NAS e impresoras de red, el SSP de NTLM puede ofrecer el único método de autenticación compatible. Algunas implementaciones de SMB o distribuciones anteriores de, por ejemplo Samba puede hacer que Windows negocie NTLMv1 o incluso LM para la autenticación de salida con el servidor SMB, lo que permite que el dispositivo funcione aunque puede estar cargado con software obsoleto e inseguro, independientemente de si se trata de un dispositivo nuevo.
  • Si el servidor es miembro de un dominio pero no se puede utilizar Kerberos .
    • El cliente se está autenticando en un servidor usando una dirección IP (y no hay disponible una resolución de nombre inversa)
    • El cliente se está autenticando en un servidor que pertenece a un bosque de Active Directory diferente que tiene una confianza NTLM heredada en lugar de una confianza transitiva entre bosques.
    • Donde un firewall restringiría los puertos requeridos por Kerberos (típicamente TCP 88)

Uso de versiones de protocolo

Después de que el desarrollador de la aplicación o el SSP de negociación hayan decidido que se use el SSP de NTLM para la autenticación, la directiva de grupo determina la capacidad de usar cada uno de los protocolos que implementa el SSP de NTLM. Hay cinco niveles de autenticación.[23]​

  • Enviar respuestas LM y NTLM : los clientes usan la autenticación LM y NTLM, y nunca usan la seguridad de sesión NTLMv2; Los DC aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar LM y NTLM: use la seguridad de sesión NTLMv2 si se negocia : los clientes usan la autenticación LM y NTLM, y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLM : los clientes solo usan autenticación NTLM y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLMv2 : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
  • Enviar solo respuesta NTLMv2\rechazar LM : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM (aceptan solo autenticación NTLM y NTLMv2).
  • Enviar solo respuesta NTLMv2\rechazar LM y NTLM : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM y NTLM (aceptan solo la autenticación NTLMv2).

DC significaría controlador de dominio, pero el uso de ese término es confuso. Cualquier computadora que actúe como servidor y autentique a un usuario cumple la función de DC en este contexto, por ejemplo, una computadora con Windows con una cuenta local como Administrador cuando esa cuenta se usa durante un inicio de sesión en la red.

Antes de Windows NT 4.0 Service Pack 4, el SSP negociaba NTLMv1 y recurría a LM si la otra máquina no lo admitía.

A partir de Windows NT 4.0 Service Pack 4, el SSP negociaría la sesión NTLMv2 siempre que tanto el cliente como el servidor la soportaran.[24]​ Hasta Windows XP inclusido, se utilizaba un cifrado de 40 o 56 bits en ordenadores no estadounidenses, ya que Estados Unidos tenía entonces severas restricciones a la exportación de tecnología de cifrado. A partir de Windows XP SP3, el cifrado de 128 bits podía añadirse instalando una actualización y, en Windows 7, el cifrado de 128 bits sería el predeterminado.

En Windows Vista y posteriores, LM se ha desactivado para la autenticación entrante. Los sistemas operativos basados en Windows NT hasta Windows Server 2003 inclusive almacenan dos hashes de contraseña, el hash de LAN Manager (LM) y el hash de Windows NT. A partir de Windows Vista, existe la posibilidad de almacenar ambos, pero uno está desactivado por defecto. Esto significa que la autenticación LM ya no funciona si el equipo que ejecuta Windows Vista actúa como servidor. Las versiones anteriores de Windows (hasta Windows NT 4.0 Service Pack 4) podían configurarse para comportarse de esta manera, pero no era el valor predeterminado.[25]​

Véase también

Referencias

  1. ↑ a b «Introduction», NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), consultado el 15 de agosto de 2010 .
  2. ↑ a b «Session Security Details», NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), consultado el 15 de agosto de 2010 .
  3. ↑ Takahashi, T (17 de diciembre de 2009), «Reflecting on NTLM Reflection», FrequencyX Blog (IBM Internet System Security (ISS)), archivado desde el original el 31 de diciembre de 2009, consultado el 14 de agosto de 2010 .
  4. ↑ Claburn, Thomas (14 de febrero de 2019). «Use an 8-char Windows NTLM password? Don't. Every single one can be cracked in under 2.5hrs». www.theregister.co.uk (en inglés). Consultado el 26 de noviembre de 2020. 
  5. ↑ «Microsoft NTLM», MSDN (Microsoft), consultado el 15 de agosto de 2010 .
  6. ↑ «Message Syntax | section 2.2», NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), consultado el 15 de agosto de 2010 .
  7. ↑ «Connection-Oriented», NT LAN Manager (NTLM) Authentication Protocol Specification (3.1.5.1 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  8. ↑ «Connectionless», NT LAN Manager (NTLM) Authentication Protocol Specification (3.1.5.2 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  9. ↑ «NEGOTIATE_MESSAGE», NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.1 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  10. ↑ «CHALLENGE_MESSAGE», NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.2 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  11. ↑ «AUTHENTICATE_MESSAGE», NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.3 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  12. ↑ a b «NTLM v1 Authentication», NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  13. ↑ «NTLM v2 Authentication», NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 edición) (Microsoft), consultado el 15 de agosto de 2010 .
  14. ↑ What's New in Windows NT 4.0 Service Pack 4?
  15. ↑ How to enable NTLM 2 authentication, Support, Microsoft, 25 de enero de 2007, consultado el 14 de agosto de 2010 .
  16. ↑ a b «Security Configuration», Microsoft Windows 2000 Security Hardening Guide, TechNet (Microsoft), consultado el 14 de agosto de 2010 .
  17. ↑ Glass, Eric, «NTLM», Davenport, Source forge .
  18. ↑ Varughese, Sam (February 2006). «Rainbow Cracking and Password Security». Palisade. Archivado desde el original el 1 de junio de 2010. Consultado el 14 de agosto de 2010. 
  19. ↑ «Security Considerations for Implementers», NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), consultado el 16 de agosto de 2010 .
  20. ↑ «Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim's password without being logged - Aorato». Archivado desde el original el 6 de octubre de 2014. Consultado el 5 de octubre de 2014. 
  21. ↑ «Microsoft NTLM». TechNet Library. Microsoft. Consultado el 2 de noviembre de 2015. 
  22. ↑ «Public Key Cryptography based User to User Authentication Overview». TechNet Library. Microsoft. Consultado el 2 de noviembre de 2015. 
  23. ↑ «LAN Manager authentication level». MSDN Library. Microsoft. Consultado el 2 de noviembre de 2015. 
  24. ↑ «Windows Authentication». TechNet Library. Microsoft. 29 de junio de 2011. Consultado el 2 de noviembre de 2015. 
  25. ↑ Jesper Johansson. «The Most Misunderstood Windows Security Setting of All Time». TechNet Magazine. Microsoft. Consultado el 2 de noviembre de 2015.