Si bien una parte clave de la ciberresiliencia es adaptarse a los cambios en la tecnología, abordar las superficies de ataque que se han mantenido constantes es igualmente crítico. Esto se debe a que la mayoría de las empresas han mantenido una cantidad significativa de infraestructura heredada además de cargas de trabajo en la nube y aplicaciones SaaS más nuevas. A veces, esto se debe al costo operativo de la migración, así como a la preocupación de que al hacerlo se puedan romper procesos críticos. En otros casos, esto se debe simplemente a que el equipo de TI ni siquiera es consciente de la existencia de los componentes heredados. Pero sea cual sea el motivo, la infraestructura heredada es un blanco perfecto para los actores de amenazas, ya que siempre es menos segura que sus alternativas modernas. 

En esta publicación exploramos un ejemplo destacado de infraestructura heredada: el protocolo de autenticación NTLMv1. Esta primera versión de NTLM incluía debilidades de seguridad críticas, lo que permitía a los atacantes ejecutar una variedad de ataques basados ​​en identidad. Y aunque ya tiene más de 30 años, todavía se puede encontrar en entornos de producción, exponiéndolos a riesgos de compromiso que son extremadamente difíciles de detectar.

Luego mostraremos cómo Silverfort permite a las empresas superar los riesgos de NTLMv1 con descubrimiento, monitoreo y control en cada autenticación e intento de acceso que todavía utiliza este protocolo arcaico. 

Autenticación NTLM: una breve historia

Según la  Wikipedia , "En un Windows red, New Technology LAN Manager (NTLM) es un conjunto de Microsoft protocolos de seguridad destinados a proporcionar autenticación, integridad y confidencialidad a los usuarios. NTLM es el sucesor del protocolo de autenticación de Microsoft Gerente de LAN. El conjunto de protocolos NTLM se implementa en un Proveedor de soporte de seguridad, que combina la Gerente de LAN protocolos de autenticación NTLMv1, NTLMv2 y NTLM2 en un solo paquete”. (NTLM2 combina NTLMv1 y NTLMv2). 

NTLMv1 se lanzó en 1993 y es un protocolo de autenticación de desafío-respuesta, lo que significa que el proceso de autenticación se lleva a cabo en tres pasos: 

1. La máquina cliente establece una conexión de red con el servidor de destino.
2. El servidor envía un desafío a la máquina cliente.
3. La máquina cliente responde al desafío y el servidor permite o niega el acceso según la respuesta.

En 1998, NTLMv2 se lanzó en Windows NT 4.0 SP 4 y desde entonces ha sido la versión actual del protocolo.

Problemas generales de seguridad de NTLM

Todas las versiones de autenticación NTLM enfrentan los siguientes problemas de seguridad:

1. La falta de salazón hace que la contraseña hash sea equivalente, lo que significa que si puede obtener el valor hash del servidor, podrá autenticarse sin conocer la contraseña real. Esto significa que un atacante que pueda recuperar un hash (y hay varias formas de volcarlo de la memoria de la máquina) puede acceder fácilmente a un servidor de destino y hacerse pasar por el usuario real.
2. Si bien el servidor valida la identidad del cliente, no existe una validación correspondiente de la identidad del servidor, lo que abre la posibilidad de un ataque Man-In-The-Middle (MITM).
3. NTLMv1 carece de desafío de cliente: en caso de un ataque a NTLMv1, el atacante puede obligar al cliente a calcular la respuesta NTLMv1 con un desafío de servidor conocido. Luego, el atacante puede adivinar eficientemente la contraseña del usuario comparando la respuesta NTLMv1 con una mesa arcoiris.
4. La falta de MFA El soporte priva al protocolo de cualquier protección en el caso de una contraseña o hash comprometidos. 

Estas preocupaciones llevaron a Microsoft a reemplazar NTLM por el más seguro. Kerberos protocolo de autenticación como predeterminado en entornos AD, aunque manteniendo NTLM como respaldo. Pero incluso dentro de NTLM, NTLMv1 es significativamente menos seguro que su sucesor, NTLMv2.

¿Qué hace que NTLMv1 sea un riesgo para la seguridad?

El nivel de seguridad del protocolo depende del desafío: cuanto más difícil de comprometer, más segura será la autenticación. 

En el caso de NTLMv1, la diferencia radica en sus desafíos específicos:

1. NTLMv1 produce un desafío con un número de longitud fija de 16 bits, mientras que NTLMv2 produce desafíos de longitud variable.
2. NTLMv1 utiliza un algoritmo de cifrado DES débil que se descifra rápidamente, lo que lo hace vulnerable a la fuerza bruta, mientras que NTLMv2 utiliza el más lento HMAC-MD5 que puede resistir mejor estos ataques, ya que el descifrado no puede realizarse en tiempo real. 

Por lo tanto, cualquier sistema que utilice autenticación NTLMv1 está expuesto a verse comprometido, ya que los atacantes pueden idear fácilmente una manera de aceptar el desafío y así obtener acceso al sistema. 

Teniendo esto en cuenta, es fácil entender por qué los equipos de seguridad y TI quieren alejarse de NTLMv1. En teoría, parece fácil: simplemente busque todos los sistemas que utilizan NTLMv1 y cambie a un protocolo más seguro. En la práctica, sin embargo, es mucho más desafiante.

Obstáculos en la detección y eliminación de NTLMv1

En un mundo ideal, habría algún filtro que, al hacer clic, revelaría todas las autenticaciones NTLMv1 que tienen lugar dentro de un entorno. Lamentablemente, la realidad no es tan sencilla.

La ruta más sencilla es habilitar la auditoría de inicio de sesión exitosa en el controlador de dominio. Según la documentación de Microsoft, cada punto final debe generar un evento con la información requerida (Evento de auditoría exitosa 4624, que contiene información sobre la versión de NTLM. Los registros de eventos recibidos contienen un campo 'Nombre de paquete (solo NTLM)' que indica el NTLM. versión). Sin embargo, la recopilación de estos registros no se puede realizar de forma centralizada en el DC y debe recuperarse de cada máquina individual. Además, en muchos casos el evento no tiene los datos de la versión NTLM o ni siquiera ha sido creado. 

Además, en la mayoría de los casos, NTLMv1 se encuentra dentro de una aplicación heredada donde la autenticación NTLMv1 se realiza en el servidor de aplicaciones. Como tal, no hay garantía de que el programador que codificó la aplicación implementara un mecanismo de auditoría sólido. Si la aplicación utiliza un servidor Windows, es posible que se audite parcialmente localmente, por ejemplo, si utiliza bibliotecas internas de Windows como la autenticación IIS (aplicación de servidor web). Sin embargo, si la aplicación está escrita completamente por terceros, no se audita ningún registro. En ese caso, no hay manera de saber si NTLMv1 está en uso sin pasos intrusivos (como descifrar los paquetes o analizar el código de la aplicación real).

Si bien las autenticaciones NTLMv1 se pueden detectar parcialmente mediante la inspección a nivel de red, dicha inspección no es posible ya que en la mayoría de los casos este tráfico está cifrado.

Entonces, el desafío radica no sólo en la inseguridad inherente del propio NTLMv1 sino también en la dificultad de determinar si se está utilizando en un entorno determinado. 

SilverfortProtección para la superficie de ataque NTLMv1

El  Silverfort Protección de identidad unificada La plataforma brinda a las organizaciones la capacidad única no solo de descubrir todas las autenticaciones NTLMv1 dentro de un entorno, sino también de bloquearlas activamente. 

Silverfort El motor de análisis detecta autenticaciones NTLMv1 y las marca como indicador de riesgo. Este indicador de riesgo se puede utilizar como filtro para descubrir máquinas que realizan dichas autenticaciones y como activador de políticas de acceso. Veamos cómo se ve dentro del Silverfort consola:

Descubrimiento de moléculas

Dentro de la pantalla Registros de autenticación, marque la casilla Autenticación NTLMv1. Una vez marcada, se muestran todas las autenticaciones coincidentes, lo que proporciona conocimiento práctico sobre qué máquinas utilizan NTLMv1 para ayudar a decidir si deshabilitarlas.

NTLMv1 habilitado en SilverfortPantalla de registros de autenticación

Protección 

De forma similar, Silverfort permite el uso de un indicador de riesgo NTLMv1 como disparador para activar una política de acceso. La acción entonces sería:

• Denegar: Elija esta opción si no desea permitir NTLMv1 en absoluto dentro del entorno como medida de precaución adicional.
  

Silverfort política para denegar el acceso a través de NTLMv1

• MFA: Elija esta opción si por algún motivo no puede eliminar el uso de NTLMv1 (por ejemplo, si hay una aplicación antigua que podría fallar y poner en peligro procesos comerciales críticos). En este caso, incluso si el flujo de autenticación se ve comprometido, el verdadero usuario debe verificar su identidad a través de MFA para poder obtener acceso, desarmando efectivamente la capacidad de los atacantes de aprovechar las debilidades del protocolo para el acceso malicioso.
  

Silverfort política para requerir un paso adelante de MFA al autenticarse a través de NTLMv1

El camino hacia la seguridad integral

En el entorno híbrido actual existen muchos tipos de sistemas que coexisten, por lo que una seguridad integral significa monitorearlos y protegerlos a todos. NTLMv1 es sólo un ejemplo de los problemas con los sistemas heredados; También es importante comprender que cuando la debilidad de la seguridad reside en la infraestructura heredada, un compromiso aquí puede permitir a los atacantes obtener acceso también a otras partes del entorno. La forma correcta de verlo no es tanto proteger los sistemas heredados sino evitar que los sistemas heredados se conviertan en la puerta de entrada a su entorno. 

Silverfort's unificado Protección de Identidad es la primera plataforma diseñada específicamente para proteger contra amenazas de identidad en toda la empresa híbrida, ya sea que el recurso objetivo sea una aplicación SaaS, una carga de trabajo en la nube o un servidor local. Silverfort extiende MFA y la seguridad de identidad moderna a todos los recursos principales que antes no podían protegerse, incluido NTLMv1.

¿NTLMv1 es un superficie de ataque quieres dirigirte? Programe una reunión con uno de nuestros expertos esta página.