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 de Microsoft LAN Manager (LANMAN), un producto anterior de Microsoft. El conjunto de protocolos NTLM se implementa en un proveedor de soporte de seguridad , que combina el protocolo de autenticación de LAN Manager , los protocolos NTLMv1, NTLMv2 y NTLM2 Session 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 directiva de grupo , para la cual las diferentes versiones de Windows tienen diferentes configuraciones predeterminadas.
Las contraseñas NTLM se consideran débiles porque pueden ser violadas con mucha facilidad 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 conexión (el entorno 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 dos valores de contraseña en hash, los cuales también se almacenan en el servidor (o controlador de dominio), y que a través de la falta de salazón son equivalentes a la contraseña , lo que significa que si obtiene el valor de hash del servidor, puede autenticarse sin saber la contraseña real. Los dos son el hash LM (una función basada en DES aplicada a los primeros 14 caracteres de la contraseña convertida al juego de caracteres PC de 8 bits tradicional para el lenguaje), y el hash NT ( MD4 de la contraseña Unicode UTF-16 little endian ). Ambos valores de 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]
El servidor autentica al cliente enviando un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación que involucra 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 se realizan generalmente 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 lo 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 DES en 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 = hash NTLM | 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 y agregando la capacidad para que un servidor se autentique ante 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 de servidor, un desafío de cliente generado de forma totalmente/parcialmente 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 de 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 de cliente. Para esta respuesta más corta, el desafío de cliente de 8 bytes adjunto a la respuesta de 16 bytes forma 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 Over 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) algunos datos de formato estándar. La respuesta debe incluir una copia de este desafío de cliente y, por lo tanto, tiene una longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.
Tanto LMv2 como NTv2 combinan 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 el SAM o AD, y continuar combinando, mediante 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 la autenticación de NTLMv1 combinada con la 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 codifica mediante MD5. La mitad de 8 bytes del resultado del hash es el desafío utilizado en el protocolo NTLMv1. El desafío de 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 usar la infraestructura de controlador de dominio existente pero 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 el 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 hacer práctico mediante el uso de 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 se envíe a un controlador de dominio para su verificación. Al utilizar la sesión NTLM2, esta infraestructura continúa funcionando si el servidor sustituye el desafío por el hash de los desafíos del servidor y del cliente.
Versión 1 de NTM Cliente<-Servidor: SC Cliente->Servidor: H(P,SC) Servidor->DomCntl: H(P,SC), SC Servidor<-DomCntl: sí 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: sí o no
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 realiza tal y como 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 requerida ] 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 añadido 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 dominios de Active Directory posteriores. [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, debe 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 de negociación han decidido que se utilizará el SSP NTLM para la autenticación, la directiva 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 es confuso. Cualquier computadora que actúe como servidor y autentique a un usuario cumple la función de controlador de dominio en este contexto, por ejemplo, una computadora 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 lo admitieran. [24] Hasta Windows XP inclusive, este sistema utilizaba cifrado de 40 o 56 bits en equipos no estadounidenses, 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 podía agregar el 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 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 , la capacidad de almacenar ambos está presente, pero uno está desactivado de forma predeterminada. 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 la opción predeterminada. [25]
NTLM sigue siendo vulnerable al ataque Pass the Hash , que es una variante del ataque Reflection que fue abordado por la actualización de seguridad MS08-068 de Microsoft. Por ejemplo, Metasploit puede utilizarse en muchos casos para obtener credenciales de una máquina que pueden utilizarse para obtener el control de otra máquina. [3] [26] El kit de herramientas Squirtle puede utilizarse para aprovechar los ataques de secuencias de comandos entre sitios web y lanzar 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ían la seguridad del protocolo, lo que permitía a los atacantes obtener acceso de lectura y escritura a archivos y ejecución remota de código. Uno de los ataques presentados incluía la capacidad de predecir números pseudoaleatorios y desafíos/respuestas generados por el protocolo. Estas fallas habían estado presentes en todas las versiones de Windows durante 17 años. El aviso de seguridad que explicaba estos problemas incluía exploits de prueba de concepto completamente funcionales. Todas estas fallas fueron corregidas por MS10-012. [28] [29]
En 2012, se demostró que cada permutación posible de hash de contraseña NTLM de 8 caracteres se puede descifrar en menos de 6 horas. [30]
En 2019, este tiempo se redujo a aproximadamente 2,5 horas gracias al 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] publicó una herramienta llamada ntlmv1-multitool [35] para formatear las respuestas de desafío NTLMv1 en un formato de descifrado compatible con hashcat. Con hashcat y suficiente potencia de GPU, el hash NTLM se puede derivar utilizando un ataque de texto simple conocido descifrando las claves DES con el modo hashcat 14000, como lo demuestra atom [36] en los foros de hashcat.
Tenga en cuenta que los hashes equivalentes a contraseñas que se utilizan en ataques de pass-the-hash y de descifrado de contraseñas primero deben ser "robados" (por ejemplo, comprometiendo un sistema con permisos suficientes para acceder a los 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 de NTLM para Linux incluyen Cntlm [37] y winbind (parte de Samba ) [38], lo que permite que las aplicaciones de Linux utilicen servidores proxy NTLM.
FreeBSD también admite el almacenamiento de contraseñas a través de Crypt (C) en el formato inseguro NT-Hash. [39]