En una red Windows , NT (Nueva Tecnología) 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 de Microsoft LAN Manager (LANMAN), un producto anterior de Microsoft. El conjunto de protocolos NTLM está implementado en un Proveedor de soporte de seguridad , que combina el protocolo de autenticación de LAN Manager , 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 que se rige por la configuración de la Política de grupo , para la cual las diferentes versiones de Windows tienen diferentes configuraciones predeterminadas.
Las contraseñas NTLM se consideran débiles porque se pueden forzar de forma bruta muy fácilmente con hardware moderno. [4]
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]
El protocolo NTLM utiliza uno o ambos de los dos valores de contraseña hash, los cuales también se almacenan en el servidor (o controlador de dominio) y que, debido a la falta de sal, son equivalentes a contraseñas , lo que significa que si toma el valor hash del servidor , puede autenticarse 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 convertida al conjunto de caracteres de PC tradicional de 8 bits para el idioma) y el hash NT ( MD4 de la contraseña Unicode UTF-16 de Little Endian). ). Ambos valores hash son de 16 bytes (128 bits) cada uno. [12]
El protocolo NTLM también utiliza una de dos funciones unidireccionales , según la versión de NTLM; NT LanMan y NTLM versión 1 usan la función unidireccional LanMan basada en DES (LMOWF), mientras que NTLMv2 usa la función unidireccional basada en NT MD4 (NTOWF). [12] [13]
[2]
El servidor autentica al cliente enviando un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación que implica el desafío y un secreto compartido entre el cliente y el servidor, específicamente 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 suelen realizarse utilizando ambos hashes y se envían ambos resultados de 24 bytes. El servidor verifica que el cliente haya calculado el resultado correcto y de esto infiere 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 están separados en tres cantidades de 7 bytes (56 bits). Cada una de estas cantidades de 56 bits se utiliza como clave para cifrar DES el desafío de 64 bits. Los tres cifrados del desafío se reúnen para formar la respuesta de 24 bytes. Tanto la respuesta que utiliza el hash LM como el hash NT se devuelven como respuesta, pero esto es configurable.
C = desafío de servidor de 8 bytes, aleatorioK1 | K2 | K3 = NTLM-Hash | 5 bytes-0respuesta = DES(K1,C) | DES(K2,C) | DES(K3,C)
NTLMv2, introducido en Windows NT 4.0 SP4 [14] (y soportado de forma nativa en Windows 2000), es un protocolo de autenticación de desafío-respuesta. Está pensado como un reemplazo criptográficamente reforzado para NTLMv1, mejorando la seguridad de NTLM al fortalecer el protocolo contra muchos ataques de suplantación de identidad y agregando la capacidad de que un servidor se autentique con el 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 aleatoriamente 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 del cliente de 8 bytes agregado a la respuesta de 16 bytes crea un paquete de 24 bytes que es consistente con el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En cierta documentación no oficial (por ejemplo, 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 de hora NT , (2) un valor aleatorio de 8 bytes (CC2 en el cuadro siguiente), (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 y, por lo tanto, tiene una longitud variable. En documentación no oficial, esta respuesta se denomina NTv2.
Tanto LMv2 como NTv2 codifican el desafío del cliente y del servidor con el hash NT de la contraseña del usuario y otra información de identificación. La fórmula exacta es comenzar con el hash NT, que se almacena en SAM o AD, y continuar ingresando, usando 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, aleatorioCC = desafío de cliente de 8 bytes, aleatorioCC* = (X, hora, 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*
El protocolo de sesión NTLM2 es similar a MS-CHAPv2. [17] Consiste en autenticación de NTLMv1 combinada con seguridad de sesión de NTLMv2.
Brevemente, 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 de al menos 8 bytes del resultado hash es la prueba utilizada en el protocolo NTLMv1. El desafío del cliente se devuelve en una ranura de 24 bytes del mensaje de respuesta, la respuesta calculada de 24 bytes se devuelve en la otra ranura.
Esta es una forma reforzada de NTLMv1 que mantiene la capacidad de utilizar la infraestructura de controlador de dominio existente y al mismo tiempo evita un ataque de diccionario por parte de un servidor no autorizado. Para un X fijo , 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 puede hacerse práctico mediante el uso de tablas de arcoíris . [18]
Sin embargo, la infraestructura NTLMv1 existente permite que el servidor no verifique el par desafío/respuesta, sino que lo envíe a un controlador de dominio para su verificación. Usando NTLM2 Session, esta infraestructura continúa funcionando si el servidor sustituye el desafío por el hash del servidor y el cliente.
NTLMv1 Cliente<-Servidor: SC Cliente->Servidor: H(P,SC) Servidor->DomCntl: H(P,SC), SC Servidor<-DomCntl: si o noSesión NTLM2 Cliente<-Servidor: SC Cliente->Servidor: H(P,H'(SC,CC)), CC Servidor->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) Servidor<-DomCntl: si o no
Desde 2010, Microsoft ya no recomienda NTLM en 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 que las aplicaciones no utilicen NTLM.
A pesar de estas recomendaciones, NTLM todavía se implementa ampliamente en los sistemas. [ cita necesaria ] Una razón importante es mantener la compatibilidad con sistemas más antiguos. Sin embargo, se puede evitar en algunas circunstancias. [ ¿cómo? ]
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 a un atacante un ticket Kerberos si se conoce el hash NTLM. [20] Microsoft adoptó Kerberos como el protocolo de autenticación preferido para Windows 2000 y dominios posteriores de Active Directory. [16] Kerberos se utiliza 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, debería utilizar el paquete de seguridad Negotiate. Negotiate permite que su aplicación aproveche 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.
El NTLM SSP se utiliza en las siguientes situaciones:
Una vez que el desarrollador de la aplicación o el SSP negociador han decidido que se utilizará el SSP NTLM para la autenticación, la Política de grupo dicta la capacidad de utilizar cada uno de los protocolos que implementa el SSP NTLM. Hay cinco niveles de autenticación. [23]
DC significaría Controlador de dominio, pero el uso de ese término resulta confuso. Cualquier computadora que actúe como servidor y autentique a un usuario cumple el rol 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 del Service Pack 4 de Windows NT 4.0, el SSP negociaría la sesión NTLMv2 siempre que tanto el cliente como el servidor la admitieran. [24] Hasta Windows XP inclusive, se utilizaba cifrado de 40 o 56 bits en computadoras fuera de los EE. UU., ya que Estados Unidos tenía severas restricciones a la exportación de tecnología de cifrado en ese momento. A partir de Windows XP SP3, se podría agregar cifrado de 128 bits instalando una actualización y en Windows 7, el cifrado de 128 bits sería el predeterminado.
En Windows Vista y versiones posteriores, LM se ha deshabilitado para la autenticación entrante. Los sistemas operativos basados en Windows NT hasta Windows Server 2003 inclusive almacenan dos hash de contraseña, el hash de LAN Manager (LM) y el hash de Windows NT. A partir de Windows Vista , la capacidad de almacenar ambos está ahí, pero uno está desactivado de forma predeterminada. Esto significa que la autenticación LM ya no funciona si la computadora que ejecuta Windows Vista actúa como servidor. Las versiones anteriores de Windows (hasta Windows NT 4.0 Service Pack 4) se podían configurar para comportarse de esta manera, pero no era la opción predeterminada. [25]
NTLM sigue siendo vulnerable al ataque de paso hash , que es una variante del ataque de reflexión que fue abordado por la actualización de seguridad de Microsoft MS08-068. Por ejemplo, Metasploit se puede utilizar en muchos casos para obtener credenciales de una máquina que se pueden utilizar para obtener el control de otra máquina. [3] [26] El kit de herramientas Squirtle se puede utilizar para aprovechar los ataques de secuencias de comandos entre sitios web en ataques a activos cercanos a través de NTLM. [27]
En febrero de 2010, Amplia Security descubrió varias fallas en la implementación de Windows del mecanismo de autenticación NTLM que rompía la seguridad del protocolo permitiendo a los atacantes obtener acceso de lectura/escritura a archivos y ejecución remota de código. Uno de los ataques presentados incluyó la capacidad de predecir números pseudoaleatorios y desafíos/respuestas generados por el protocolo. Estos fallos estuvieron presentes en todas las versiones de Windows durante 17 años. El aviso de seguridad que explica estos problemas incluía exploits de prueba de concepto completamente funcionales. Todos estos defectos fueron solucionados por MS10-012. [28] [29]
En 2012, se demostró que todas las permutaciones posibles de hash de contraseña NTLM de 8 caracteres se pueden descifrar en menos de 6 horas. [30]
En 2019, este tiempo se redujo a aproximadamente 2,5 horas mediante el uso de hardware más moderno. [4] [31] Además, las tablas Rainbow están disponibles para contraseñas NTLM de ocho y nueve caracteres. Las contraseñas más cortas se pueden recuperar mediante métodos de fuerza bruta. [32]
En 2019, EvilMog [33] [34] [35] publicó una herramienta llamada ntlmv1-multitool [36] para formatear las respuestas al desafío NTLMv1 en un formato de craqueo compatible con hashcat. Con hashcat y suficiente potencia de GPU, el hash NTLM se puede derivar utilizando un conocido ataque de texto plano descifrando las claves DES con el modo hashcat 14000, como lo demuestra atom [37] en los foros de hashcat.
Tenga en cuenta que los hashes equivalentes a contraseñas utilizados en ataques de paso de hash y descifrado de contraseñas primero deben "robarse" (por ejemplo, comprometiendo un sistema con permisos suficientes para acceder a hashes). Además, estos hashes no son los mismos que el "hash" NTLMSSP_AUTH transmitido a través de la red durante una autenticación NTLM convencional.
Las implementaciones NTLM para Linux incluyen Cntlm [38] y winbind (parte de Samba ) [39] que permiten que las aplicaciones Linux utilicen proxies NTLM.
FreeBSD también admite el almacenamiento de contraseñas a través de Crypt (C) en el formato inseguro NT-Hash. [40]